Mode validation & pixel clock
benh at kernel.crashing.org
Tue Dec 20 12:57:41 PST 2005
On Tue, 2005-12-20 at 08:52 -0800, stuart kreitman wrote:
> Benjamin Herrenschmidt wrote:
> > I suppose the problem is that if we do that and end up with a broken
> > DDC, we might refuse valid modes ... The problem i see here is that the
> define "broken DDC". Does xf86mode.c flag this?
No, I meant, some monitors, especially old ones, can contain an EDID
block with totally wrong timings. We need to keep a way to override the
auto-detection with the config file. Just adding the return statement I
mentioned would enforce the DDC max pixel clock without a way to
override it afaik. (Unless I missed something).
> makes good sense to me. Are there any other warning messages as
> candidates for this kind of audit?
I haven't looked, I was specifically hitting a problem with that one,
but I can dig a bit more later today or tomorrow.
> I need to look at the age of the code. Could it be that there's simply
> lots of arcane, unconsidered fluff lying around?
> It is time to start up a hardware compatibility list, and get people to
> volunteer testing on these con fig issues.
I think if we start going that way, we should create a monitor database
with at least a blacklist of known broken EDIDs, an at best, the ability
replace selected fields of the EDID and provide additional infos per
monitor (like subpixel ordering for flat panel, as a lot of them still
don't implement the relevant EDID extensions).
In fact, we discussed that a while ago on IRC, and though it may be
useful if not to re-use whatever format windows use for monitor
descriptions, then to have a way to convert them to our format, since
monitors are often bundled with a windows CD containing a description
> Lets start the discussion of the long range plan.
> Can you make a starting outline of what we'd need?
I can try, I don't pretend to know everything that is to know about
these things though but I can try to summarize. Leave me a couple of
More information about the xorg