On Gwe, 2004-05-07 at 21:59, Egbert Eich wrote: > However chipset probing/display device probing and mode setting isn't > required to live in kernel space. Portability and system stability > arguments speak against it. In fact only Apple MAC users seem to > advocate this idea to be able to an initial video mode on their > systems.
Lots of minor systems from mobile phones to supercomputer systems don't have a text mode. That still only requires some predefined mode tables in the kernel in the form of register setting lists - aka the way BIOS tables generally work. > Therefore the mode setting API should provide a minimal set of standard > features a set of optional features (which may evolve over time) and > allow a chipset specific API that may - over time - move into the > optional features. The mode setting interface should probably be userspace. How the user space talks to the kernel module behind it is entirely its own business (or even if it does). The mode setting interface itself needs to have a common API above it however. This is how ALSA handles audio and aspects of video4linux2 work. I can see a user space interface which takes the existing XFree86 type mode line structure (timings, hsync +/- etc) being reasonably sane. The X server can compute modes it needs through this, the kernel can use precomputed modes for text and for SAK or can use the same interface via hotplug ------------------------------------------------------- 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
