Re: Current discussion about the future of free software graphics

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 <benh@kernel.crashing.org> wrote:

quoted

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.