Mode validation & pixel clock

[Benjamin Herrenschmidt]

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?

Quite possibly.

> 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
file.
 
> 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
days though.

Ben.