On Monday, May 21, 2007, Benjamin Herrenschmidt wrote: > > 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.
The current code does its best to figure out what modes are available and tries to pick a good one for each display. It sounds like you're mainly concerned with the actual mode picking, not the mode and output detection and enumeration? If so, that's a pretty easy change to make. But if you're also worried about the kernel building mode lists, then we'll have bigger changes to make... > 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... I'm not really sure how much of a problem broken EDIDs will be. The X server only has a few quirks for broken EDIDs now, nothing major afaict, and apparently the FB layer already has some code for handling EDID quirks, so I don't think that'll be our biggest problem. So far, it looks like handling laptop panels is a bit trickier (at least for Intel chips)... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
