On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote: > At the X Developers Conference there was a discussion of the issues around > framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for > discussion. I'm going to try and list all of the issues I've heard from all > sides so some of the proposed solutions are in conflict. The goal of this list > is to provide direction for a topic discussion at the Ottawa Kernel Summit.
I see as common sense that fbdev should become the low-level and unified interface for graphics in Linux, it has too many advantages for us: - Exists now. - Multi-architecture. - Very popular in embedded solutions. - Interface to change video modes. - Supports low-end hardware. - It has an interface to control the hw from userspace. - Can be enhanced or fixed. Missing in fbdev: - Memory management. - Hardware lock to synch or flag changes in hardware. (Maybe with the DRM/FB merge we could reuse the lock.) - sysfs (being fixed by Luca). - Video-out port API. - Video capture API (gatos). I imply too that fbcon should not be considered as part of this low-level layer, but a client of it, because it implements acceleration and other stuff not related nor pertinent to a graphics layer per se. I am not saying that everything should be in the kernel, just the necesary API to properly have a Linux graphics state machine. Anything else should be in userspace, specially acceleration that could be provided by DRI, directfb, fbcon, etc. which all will be clients of the low-level fbdev layer. This path makes it feasible to implement graphics servers (like Xserver) without implementing or duplicating the graphics layer details. This would lead to a sane and (with time) a stable graphics layer for linux in the same way we have first-class networking, input and sound layers in Linux now. -otto ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
