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

[Adam Jackson]

On Wed, 2009-11-11 at 17:30 +0800, ykzhao wrote:

> Some users hope that there exist the default modes as many as possible.
> And this is handled by Xserver(When there is no EDID or the default GTF
> is supported in EDID, the xserver will add the default modes for them).
> 
> But unfortunately the range limit in EDID is so strict that the default
> modes will be removed by the limit check. So we construct the range
> limit in the LVDS EDID block. 

Again, I think this is pointing to flaws in the X server's logic.
Range-based validation is, broadly speaking, bogus.  If the display
specifies range constraints, we should believe it, and then and only
then is it sensible to add default modes.  If it doesn't, we should not
infer a range from the provided modes, nor should we filter modes based
on an inferred range.

Even disregarding that, you could just construct the desired sync ranges
directly, in output->conf_monitor in the output's ->detect function.
It's a little gross since you don't want to clobber the user's
configuration if it already exists, but that's straightforward.

> In fact the issue can also be solved by generating the expected mode
> list(for example: by calling the function of xf86GetDefaultModes). In
> such case it is unnecessary to construct the bogus EDID for LVDS. But
> the same function will be called twice. 

Oh, what a tragedy, to call the same function twice, in something that's
not a performance path in any way.

- 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/20091111/bf72c224/attachment.sig>