Alan Cox writes: > 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.
Right. On the other hand on lot of systems we need to rely on some firmware to do some basic setup (ie. initialize the graphics chip for memory clock and characteristics of the video memory). I would expect that this firmware can do (or can be told to do) some basic mode set up, too. If there is no such firmware and the initialization needs to be handled e arly during pre-boot process then we are talking about a real custom case anyway. In this case an initial mode would certainly have to be set up along side the low level programming. Wouldn't it be appropriate to leave this to a 'boot loader' whatever this may be in this case - as the boot loader would like to display an initial logo or menu? The kernel could take whatever mode there is (provided it is passed all information it needs) and put its output there - much as it is proposed for the Xserver (Of course the Xserver could not provide meaningful output on a true text mode. > > > 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 If we can move mode setting to a library (or a daemon as we may need some persistant data), the Xserver as well as the kernel would be passed information about the mode and would passively make use of it. Egbert. ------------------------------------------------------- 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
