Mode validation & pixel clock

[stuart kreitman]

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?
> max_clock isn't part of the monitor infos, unlike max V&H refresh, and
> thus cannot be overriden by the config file.
>
> So I suppose we should add the max pixel clock to the Monitor section,
> have it default to the max in DDC or some arbitrary value (0 == not
> specified maybe) when no DDC is available, and make the above test
> actually do more than just print a warning. Is that ok ?
>   
makes good sense to me. Are there any other warning messages as 
candidates for this kind of audit?

> Also, I still have a problem with analog panels. We do tend to ignore
> the modes in the EDID block completely, we only use the range infos
> there, which means that we tend to pick a mode that is higher than the
> panel native one. While this might be ok with CRTs, that doesn't do any
> good on LCDs.
>
> Is there any reason why we don't follow the supported mode list in
> there ? It does, from experience, contains some crazy modes, but the
> highest ones tend to be ok, or at least the second or third from the
> top. Crazy heuristic but might work well enough. Users with crazy
> displays can always override the mode (maybe we could make a
> "IgnoreEDID" option generic in the Monitor section for that).
>   
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.
> What do you guys think ? That is probably not enough in the long run, we
> need to deal with calculating modes via CVT for flat panels etc... but
> that need bigger API changes, since there are lots of cases where
>   
Lets start the discussion of the long range plan.
Can you make a starting outline of what we'd need?

skk
> drivers can "probe" the panel size from the firmware or chip state but
> not all of the detailed timings (and from experience, CVT gives you a
> generally useable mode from that).
>
> Ben.
>  
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>