I have a laptop with an internal 1366x768 (16:9) display and I have connected and external 1920x1080 (16:9) monitor via HDMI. By default the display gets mirrored with only 1024x768 (4:3) because this is the highest common resolution of the two reported by xrandr. I can switch to a large desktop formed by the two screens with the System Settings application with each screen using its native resolution.

I have observed it with kernel 3.10.x and 3.11.x and with further investigation I found out that this is a kernel regression from 3.8.0 to 3.8.1.

I can mirror with a higher resolution running the commands:

xrandr --addmode HDMI1 1366x768 xrandr --output HDMI1 --mode 1366x768 xrandr --output HDMI1 --mode 1366x768 --same-as LVDS1

This is rather awkward when using a projector.

The problem also persists when connecting the external screen to the Mini DisplayPort (with adapter) instead of to the HDMI.

The output of "xrandr --prop" with both screens connected in large-desktop-over-both-screens mode (no mirroring):

Screen 0: minimum 320 x 200, current 3286 x 1080, maximum 32767 x 32767 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 277mm x 156mm EDID: 00ffffffffffff0030e47a0300000000 00160103801c10780adce5975a559227 1d505400000001010101010101010101 010101010101241d56d4500016303020 2500159c1000001b0000000000000000 00000000000000000000000000fe004c 4720446973706c61790a2020000000fe 004c503132355748322d534c54310025 BACKLIGHT: 1054 (0x0000041e) range: (0,1054) Backlight: 1054 (0x0000041e) range: (0,1054) scaling mode: Full aspect supported: None Full Center Full aspect 1366x768 59.8*+ 1360x768 59.8 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 510mm x 287mm EDID: 00ffffffffffff0015c3692001010101 2d14010380331d78eaee95a3544c9926 0f5054a1080081808140b30081c00101 010101010101023a801871382d40582c 4500fe1f1100001e000000ff00353732 32393131300a20202020000000fc0045 5632333333570a2020202020000000fd 003b3d1f440f000a2020202020200153 02031b41468102031112042309070783 01000067030c001300881e8c0ad08a20 e02d10103e96000403000000188c0ad0 8a20e02d10103e96001009000000188c 0ad090204031200c4055000403000000 188c0ad090204031200c405500100900 000018011d007251d01e206e28550010 090000001e000000000000000000005c Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 60.0 1280x960 60.0 1280x720 60.0 1024x768 60.0 800x600 60.3 720x576 50.0 720x480 59.9 640x480 60.0 59.9 720x400 70.1 DP1 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on HDMI2 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on DP2 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on

Original bug report to Ubuntu -----------------------------

https://bugs.launchpad.net/bugs/1167301

Testing of older kernels ------------------------

I have tried several mainline kernels from 3.8.1 to 3.11: 3.11.0-rc3, 3.11.0, and also 3.10.0, 3.9.0, 3.8.1. They all show the problem. Mainline kernel 3.8.0 is the newest where the problem does not occur.

Bisect result on upstream kernel --------------------------------

Then I have done a bisect based on

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

finding that the following patch is the culprit:

till@till-twist:~/kernel/linux-stable$ git bisect good 740922ee575f8ee4daa2bfd3db5f69dd7573fc76 is the first bad commit commit 740922ee575f8ee4daa2bfd3db5f69dd7573fc76 Author: Paulo Zanoni paulo.r.zanoni@intel.com Date: Fri Feb 15 13:36:27 2013 -0200

drm: don't add inferred modes for monitors that don't support them

commit 196e077dc165a307efbd9e7569f81bbdbcf18f65 upstream.

If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, "the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks".

For more information, please see the EDID spec, check the notes of the table that explains the "Feature Support" byte (18h) and also the notes on the tables of the section that explains "Display Range Limits & Additional Timing Description Definition (tag #FDh)".

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Reviewed-by: Alex Deucher alexander.deucher@amd.com Reviewed-by: Adam Jackson ajax@redhat.com Signed-off-by: Paulo Zanoni paulo.r.zanoni@intel.com Signed-off-by: Dave Airlie airlied@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

:040000 040000 26e271499e4ff7746011a296e569a985126aeb3f d43c54ed20f43a1459c6adb7d922ee2be55c9317 M drivers till@till-twist:~/kernel/linux-stable$

Here is the patch:

till@till:~/ubuntu/linux/linux-stable$ git diff -r 740922e~..740922e diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 5a3770f..584d5fd 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2020,7 +2020,8 @@ int drm_add_edid_modes(struct drm_connector *connector, st num_modes += add_cvt_modes(connector, edid); num_modes += add_standard_modes(connector, edid); num_modes += add_established_modes(connector, edid); - num_modes += add_inferred_modes(connector, edid); + if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF) + num_modes += add_inferred_modes(connector, edid); num_modes += add_cea_modes(connector, edid);

if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) till@till:~/ubuntu/linux/linux-stable$

Possible fixes --------------

The patch is simple and one can easily see that undoing it would solve the problem.

It seems that some monitors (including my monitor) report that they are non-continuous frequency but in reality they are. The simplest way to fix this bug is simply to undo the patch to support such buggy monitors, the correct fix would be an exception list with the monitors which support resolutions which they do not report.

There should perhaps be a possibility to override this manually by a run-time configuration bit so that for all monitors the non-reported resolutions get listed.

As I have already found the patch causing the problem and also as I have tested many mainline kernels I am not attaching all the /proc/... files asked for in the "KERNEL.ORG FORMAT" on https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Overview_on_Reporti...

In addition, another user with different hardware has reported the same problem in the Ubuntu bug report (Gizmo Chicken, CCed).

I hope this information helps to fix the problem. Please ask me if further information is needed.

Note that I am not subscribed to the mailing list, please CC me.

Till