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

ykzhao yakui.zhao at intel.com
Wed Nov 11 10:30:33 CET 2009


On Mon, 2009-11-09 at 23:08 +0800, Adam Jackson wrote:
> 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.

It seems that this is a longer history.

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. 

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




More information about the Intel-gfx mailing list