[PATCH 0/10][Precise][SRU]: (upstream) bring edid resolution detection in parity with quantal

[Andy Whitcroft]

On Wed, Jan 30, 2013 at 11:13:54AM +0100, Stefan Bader wrote:
> On 30.01.2013 06:28, Dave Chiluk wrote:
> > BugLink: http://bugs.launchpad.net/bugs/1109112
> > 
> > SRU Justification:
> > 
> > Impact: Users may not be able to mirror displays between two displays
> >    that support the same possible resolutions.
> > 
> >    One such example is connecting a particular 1920x1080 display to a 1368x768
> >    laptop.  Since the external display does not show 1368x768 as a valid
> >    resolution, both displays are instead run at 1024x768 by default.  In
> >    Quantal where 1368x768 is detcted as valid both displays are mirrored at
> >    1368x768, which is preferable.
> > 
> > Fix:
> >  These commits update the range descriptor struct for edid 1.4.
> >   8353e6c632aeaea1470a286b83e68ca233073068
> >   eeefa4bea1af34207c5299f989fffe03628ea164
> > 
> >  These commits add a number of inferred modes through calculation
> >   b309bd37a1357bd4391dace247cceb9d9121d20a
> >   cb21aafe121b1c3ad4c77cc5c22320163f16ba42
> >   cd4cd3ded8efc49de6f5056dfb0d60e69b388b71
> > 
> >  These commits remove a number of newly inferred modes to attain parity with
> >   quantal.
> >   7b668ebe2fce517873b0c28dd70c10fef1d3dc2f
> >   c09dedb7a50e23f0166e0bbae61c75c7ec23cf7f
> >   b61b2140feaa6aca51c63db94aa5217cd82705d1
> >   54ac76f851a1789b047b74a8e14980f2dd1ac749
> >   cffd75480ceb1cefffb5595b03ce8383d0ba40ad
> > 
> >  Together these patches allow for resolution parity with quantal.
> > 
> > Testcase:
> >    Using a machine with quantal and raring compare the output of xrandr on
> >    both series.  This fix should make the resolution output similar, but
> >    not necessarily identical.
> > 
> > 
> >  drivers/gpu/drm/drm_edid.c       |  161 +++++++++++++++++++-
> >  drivers/gpu/drm/drm_edid_modes.h |  301 +++++++++++++++++++++++++++++++++++++-
> >  include/drm/drm_edid.h           |   26 +++-
> >  3 files changed, 476 insertions(+), 12 deletions(-)
> > 
> > [PATCH 01/10] drm/edid: Update range descriptor struct for EDID 1.4
> > [PATCH 02/10] drm/edid: Add packed attribute to new gtf2 and cvt
> > [PATCH 03/10] drm/edid:
> > [PATCH 04/10] drm/edid: Do drm_dmt_modes_for_range() for all range
> > [PATCH 05/10] drm/edid: Generate modes from extra_modes for range
> > [PATCH 06/10] drm/edid: Add a workaround for 1366x768 HD panel
> > [PATCH 07/10] drm: edid: Don't add inferred modes with higher
> > [PATCH 08/10] drm/edid: support CEA video modes.
> > [PATCH 09/10] drm/edid: Add extra_modes
> > [PATCH 10/10] drm/edid: Give the est3 mode struct a real name
> > 
> 
> Looking at those there are some thoughts I like to bring up:
> 
> First, more technical, it seems that patch #10 is a prerequisite for #9 and #9
> at least is required for #5. This would mean that in between those our tree
> would not be bisectable. Is that really the upstream commit order? But anyway
> for applying to the precise tree we need to make sure the kernel would compile
> even somewhere in between the sequence.

Concur, the patchset seems almost backwards as it stands and bisectability
of the master branch is pretty important to us, so we would need to
resolve that regardless.

> The other thing is that while this looks like a big set initially, the
> individual patches seem to be sensibly doing things in simple steps. Not wanting
> to introduce regressions for currently working cases is the main worry there.
> But overall it looks acceptable. On the other hand adding new modes would be a
> bit more like a feature backport which normally would not qualify for SRU (at
> least not without good reason which maybe there is). Also in general it seemed
> like for features we rather point people to use the backport kernel + X stack.
> Again, if there is good reason why not, this could be different.
> 
> Right now, I at least would hesitate to ack the set.

Again concur, if there is some reason they cannot use the quantal backport
kernel (which I think these are included in) then the set is probabally
acceptable _if_ we can figure out how to sensibly test it.  My main worry
there is that this is primarily to do with external monitor setups which
none of our standard testing likely tests very deeply.  We might need a
proper call for testing for something like this.

-apw