quoted

   I think this is a bad idea. This has been tried before. In the 
opensource community there is no such a thing as a standard library. 

On the other hand, things like dbus are low-level and slowly getting
used by everyone... we also have the libc :)

Well now that we have one input api that can happen. Of course with 
graphics its much more diverse with what you can do. That is one of the 
reasons for so many graphics libraries. It would be really hard to write
a one size fits all library when it comes to graphics.

quoted

    The kernel really needs to be the only state machine for the hardware. 
Library developers will usually use the kernel standard interfaces. 

I don't fully agree. The kernel will do the actual HW banging, but
we want things like EDID overrides per monitor models, persistent
configuration saved to storage etc... all of that beeing pretty
nasty to do in the kernel.

By state machine I mean the physical hardware state. If it's hardware 
access then it should be in the kernel. Note I'm refering to mode setting 
not acceleration. Now EDID overrides per monitor model and saving the 
state to disk is different. That should be userland. 

I have mixed feeling on that. Keith Packard seem to prefer the library
approach. I don't know for sure what Linus prefers here. Currently, I
feel we are trying to do too much in the kernel, and that will become
increasingly painful to manage as we get multiple head & geometry stuff
getting in the picture.

I think we are fine for whats in the kernel. As for multiple head and 
geometry stuff its not that hard if done right. I have been using 
multi-head systems for years. I have multip desktop systems for years!!!





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click