On Tue, 2003-07-15 at 18:40, Jon Smirl wrote: > --- Michel Dnzer <[EMAIL PROTECTED]> wrote: > > I don't see much overlap except maybe some register > > definitions, and > > there are valid reasons why someone would want a > > framebuffer device but > > not a DRM and vice versa. Cooperation would be great > > where it makes > > sense (e.g. for vsync), but I'm still not convinced > > that a merger would > > be a good idea. That being said, it's always better > > to discuss actual > > proposals instead of speculations. :) > > > The main problem is having drm and fb stomp each > other's registers since locking and interrupts are not > coordinated. It has never made sense to me to have > two device drivers controlling the same piece of > hardware simultaneously. Most Xfree users don't see > this problem because they don't load the radeonfb > driver. XFree implements the mode switching, etc at > user level. > > The radeonfb drivers is only about 20K versus 110K for > the drm one. Another approach would be to leave > radeonfb alone and add mode switching to the drm > driver. > > A third scheme would be for the DRM driver to > implement fb support, and then have a load time flag > for jettisoning 3D support to recover the 90K. > Although I don't see why a RAM limited embedded system > would spend the money for a 3D capable Radeon and then > not use it.
There are also people who dislike video drivers in the kernel but want to use 3D hardware acceleration, and the BSDs which share much of the DRM code don't have anything like framebuffer devices AFAIK. For these and other reasons, even a 'merged' driver would still consist of mostly separate 2D and 3D parts (roughly speaking, the line is actually somewhere else of course) which can each be enabled or disabled. I guess I don't see how that would be any different or even better than the current situation, but it's entirely possible that I'm just blind. :) > DirectFB and the work I'm doing are creating another > type of environment, a standalone DRI where the > userlevel mode switching code doesn't exist. This > environment requires that radeonfb and drm be loaded > and thus exposes the coordination problems. Then you should fix those problems, not artificially merge two things that don't belong together. :) -- Earthling Michel D�nzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
