I for one have been waiting to see much of the graphics driver moved to the kernel as well. From a vendor perspective there is quite a lot to be gained.
1) If the mode setting can be removed from the X server then we can leverage that module for whatever graphics system is required. Some times we need an X server, some times we need something more like a framebuffer. Putting this in one place is a must. 2) Providing one place for rendering code would be nice too. We cannot assume that X is the way to go for all customers. If there were a place to put the device dependent rendering code (kernel module or low level library) then we could write X servers or custom graphics interfaces to use that library. 3) Some times you can just do the job easier or better from kernel space. Trapping interrupts instead of polling can save huge amounts of CPU cycles for some usage scenarios. Power management is easier. Sometimes the hardware needs some special memory considerations etc. No need to really harp on any of the details, it is just nice to have the full power of the OS when/if you need it. I think the best way to make everyone happy is to try to achieve two things. 1) A small, device-independent, API that can be used to set modes and do some very simple rendering. I would suggest get, set, put, copy. That would allow the kernel to render consoles or oopsen regardless of the mode (debugging the kernel on top of your X session?), and allow for any API of the month to make use of some very basic functionality. Mode setting should just be small as well, leave all the one-off features for extensions. No need to clutter an API with features that are rare. Although the fbdev is already available, I wouldn't suggest that it is a great platform to build on. The mode setting API is really not very good and it does not have modern concepts of twin, clone etc. I think a clean slate design that didn't try to accomplish everything in device independent manner could be a much more attractive target. 2) A mechanism to make all the device dependent extensions your heart desires. Then the X servers, opengl libs, etc can just have a DD component to access the hardware specific API. The more things you try to have a device independent API for, the more problems you will have trying to get agreement. Leave the API's to themselves. We should be trying to create a driver model, not a new graphics API. Ogl, X11, DirectFB, etc should be out of scope. -Matt ------------------------------------------------------- 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
