[lkml]   [2007]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] enhancing the kernel's graphics subsystem
    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


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-22 17:49    [W:0.024 / U:33.728 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site