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

Stefan Bader stefan.bader at canonical.com
Wed Jan 30 10:13:54 UTC 2013


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.

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.

Cheers,
Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20130130/78a15f11/attachment.sig>


More information about the kernel-team mailing list