Mode validation & pixel clock

[Adam Jackson]

On Tuesday 20 December 2005 01:07, Benjamin Herrenschmidt wrote:
> 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.

It's not just tend to, it's always.

> 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).

Making this work is, in fact, my current project:

https://bugs.freedesktop.org/show_bug.cgi?id=5386

I have a patch that doesn't quite work, and gdb is actively defeating my 
attempts to debug, but I'll attach it by the end of the day in whatever state 
I get it to.

> 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
> 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).

libv did write a CVT generator (also in bugzilla), and I'd like to fold both 
that and gtf into the server proper rather than having the big long mode 
tables.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20051220/c7aa5032/attachment.pgp>