Re: [RFC] enhancing the kernel's graphics subsystem

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> In collaboration with the FB guys, we've been working on enhancing
> the 
> kernel's graphics subsystem in an attempt to bring some sanity to the 
> Linux graphics world and avoid the situation we have now where
> several 
> kernel and userspace drivers compete for control of graphics devices.

 .../...

A little note about initial mode setting at boot...

I do stongly beleive that the decision of what mode to choose should not
be made in the kernel. At boot the kernel should either leave the HW in
whatever state the FW set it (and text mode is fine) or setup some sane
default (ie 640x480 has the most chances of working) if that's not an
option, maybe some very minimum EDID parsing in case you have a fixed
frequency weirdo panel, but that's it (unless it's a mac an OF tells you
what to use :-)

The kernel would provide userland with connector infos (presence load
detect, EDID, ...) and userland gets to decide what to do.

Some reasons to keep that policy completely out of the kernel even at
boot time are:

 - User may want to configure his default gfx setup and have it up early

 - EDID do lie, monitors routinely ship with windows .inf files
containing "updated" infos apple has that too in OS X (EDID overrides
afaik) etc.... and if we're going to do such a database of known
monitors, it should definitely not be in the kernel. Besides, we want to
add more infos that EDIDs don't provide most of the time to it like
subpixel ordering etc...

 - It sounds better that way :-) (yeah, that's the best reason !)

So while I agree that the register frobbing, memory management, etc...
should be indeed moved to the kernel as you guys have been doing lately,
the policy of deciding what mode to set should totally stick to
userland.

IMHO, the best would be a lib (or daemon or both) for monitor detection
& mode setting that is separate from X :-) That could handle storing the
admin's default setup (including weird monitor info if any) and
restoring it at boot time, etc...

Cheers,
Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/