On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote: > > 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...
I'm worried that the EDID we get from the monitor is bogus and needs to be overriden. Now, if the kernel builds a mode list, that's find if we have a call to "feed" it with a replacement one later on from userland. In addition, there are all those monitors that cannot be probed (no DDC/EDID) and for which only userland can reasonably provide a mode or a mode list. So it's a bit of both :-) Building an "initial" mode list from the EDID might be fair enough if we can replace it soon enough, but we still need to be very conservative about whatever boot mode we choose. > 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)... Well, I've seen my share of broken EDID.. Last time I looked at Darwin, I think I saw Apple maintaining a fairly huge database of EDID replacements in userland... Ben. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
