[Intel-gfx] [PATCH] gfx: The DS_UNKOWN block in EDID is used as DS_RANGE

[Adam Jackson]

On Mon, 2009-11-09 at 09:01 +0800, ykzhao wrote:
> On Sat, 2009-11-07 at 00:09 +0800, Adam Jackson wrote:
> > On Fri, 2009-11-06 at 15:23 +0800, yakui.zhao at intel.com wrote:
> > > From: Zhao Yakui <yakui.zhao at intel.com>
> > > 
> > > Sometimes nothing is contained in EDID detailed timing block. In such case
> > > it is marked as DS_UNKOWN block type. And it is also used as the DS_RANGE in
> > > order to match all the default modes by using wide open refresh rate.
> > 
> > This is still insane.  Just generate the mode list you actually want,
> > don't try to feed clever stuff to the EDID parser.
>
> Of course we can add the default modes by calling the function of
> xf86GetDefaultModes in our driver. But the xserver will also call this
> function again. IMO it is unnecessary to call the same function twice at
> the different place.

I'm reasonably sure that's a bug in the X server though.  If the driver
hands us back a list of modes, we shouldn't second-guess it.

> In fact the xserver already adds the default mode for LVDS output. But
> most of the default modes are invalidated because of range limit check.

Constructing the range limit by mangling the EDID block is lame though.
Just filter them out directly in the mode_valid hook.

> So we can also use the DS_UNKOWN block type as DS_RANGE to match the
> default modes by using wide open refresh rate, which is similar to what
> we have done by using DS_VENDOR.

I didn't say it can't be done.  I'm saying it ought not be done.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20091109/f2053a78/attachment.sig>