--- Michel D�nzer <[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. 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. Wasn't GGI created just to solve this problem? ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
