If everyone will please read Benh's original post describing this... Ben and I had been emailing on this topic before he wrote this.
--- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > I agree with the idea of moving the EDID decoding & mode selection to > userland. In this regard, though, I beleive we should aim toward some > simple library that sits with the kernel, eventually distributed with > the kernel tree, to live in initramfs optionally since it may be > required to even get a console at boot (which is fine, initramfs is > available early). The video cards themselves have PCI drivers that can > "trigger" detection by the library via hotplug, the library could manage > things like persistent configuration, either separate desktops or > geometry of a complex desktop, etc... and eventually notification of > userland clients of mode changes. > > One reason for that is lots of monitors lie about their capabilities in > their EDID block, so we want "override" files. > > The kernel driver in this case doesn't need to be that much different > than the current fbdev's though, except that we want to move the HW > access for graphics commands to the kernel too, which basically turns > into merging the DRI driver and the fbdev. There is no need, I think, to > re-invent the wheel from scratch here, it would be a lot more realistic > to build on top of those existing pieces. What this is saying is that very early in the boot process the graphics driver will be initialized. At this point it will generate a hotplug event. This event will be handled by an app and lib that live in initramfs. This is not saying that mode-setting will be delayed until normal user space starts. The initial hotplug event occurs very early in the boot process, almost as early as the current device driver based code runs. This is very similar to the way udev works. Udev is a user space replacement for devfs. Instead of having a /dev with 40,000 devices in it, udev builds one on the fly at each boot with exactly your devices in it. Now that I have used udev instead of devfs I have to agree that it is a much better solution. In fact the udev app will run before the mode-setting app since it's the udev app that creates the devices in /dev now by detecting additions to sysfs. udev FAQ: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ We all know Linux is non-functional without a /dev directory, and now /dev is being build in user space. Andrew, akpm, has also explained to me that even the current fbdev is not really active at boot. Instead those initial printk's are queued until the fbdev driver initialized and prints them. So moving mode setting to user space is not the end of the world. Everything will still work. This is more like a monolithic vs microkernel type of decision. All of the existing code is going to be reused (if we can figure out the licenses). I've already built a very messy prototype by moving the existing fbdev code to user space and it works just fine. I also called another little app which executed the VBIOS and reset secondary cards at boot via hotplug. I've convinced myself of the advantages of moving mode setting to user space, but maybe I've missed something that someone else will point out. But let's look at this as an engineering problem and try to come up with a robust, efficient solution. ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 ------------------------------------------------------- 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
