dri-devel September 2013

dri-devel@lists.freedesktop.org

153 participants
824 discussions

REGRESSION from 3.8.0 to 3.8.1: Mirroring display works only with 1024x768 (4:3) whereas my laptop has 1366x768 (16:9) & external monitor 1920x1080 (16:9)
by Till Kamppeter 25 Sep '13

25 Sep '13

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(a)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(a)amd.com> Reviewed-by: Adam Jackson <ajax(a)redhat.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni(a)intel.com> Signed-off-by: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)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_Report… 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

1 0

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
by Stephen Rothwell 25 Sep '13

25 Sep '13

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/intel_display.c between commit 67c72a122541 ("drm/i915: preserve pipe A quirk in i9xx_set_pipeconf") from the drm-intel-fixes tree and commit cf532bb25592 ("drm/i915: Move double wide mode handling into pipe_config") from the drm-intel tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au diff --cc drivers/gpu/drm/i915/intel_display.c index e5822e7,d12d563..0000000 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@@ -4775,21 -4881,8 +4881,12 @@@ static void i9xx_set_pipeconf(struct in pipeconf = 0; + if (dev_priv->quirks & QUIRK_PIPEA_FORCE && + I915_READ(PIPECONF(intel_crtc->pipe)) & PIPECONF_ENABLE) + pipeconf |= PIPECONF_ENABLE; + - if (intel_crtc->pipe == 0 && INTEL_INFO(dev)->gen < 4) { - /* Enable pixel doubling when the dot clock is > 90% of the (display) - * core speed. - * - * XXX: No double-wide on 915GM pipe B. Is that the only reason for the - * pipe == 0 check? - */ - if (intel_crtc->config.requested_mode.clock > - dev_priv->display.get_display_clock_speed(dev) * 9 / 10) - pipeconf |= PIPECONF_DOUBLE_WIDE; - } + if (intel_crtc->config.double_wide) + pipeconf |= PIPECONF_DOUBLE_WIDE; /* only g4x and later have fancy bpc/dither controls */ if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {

1 0

[Bug 68235] New: Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
by bugzilla-daemon＠freedesktop.org 25 Sep '13

25 Sep '13

https://bugs.freedesktop.org/show_bug.cgi?id=68235 Priority: medium Bug ID: 68235 Assignee: dri-devel(a)lists.freedesktop.org Summary: Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1 Severity: normal Classification: Unclassified OS: All Reporter: alexandre.f.demers(a)gmail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI I was testing kernel 3.11.0-rc5 and ended up with my display freezing after login (2 tests: one this morning, one tonight). It always freezes when dpm=1, but it doesn't if disabled. The result on my screen looks like screenshot posted in bug 66963 (https://bugs.freedesktop.org/attachment.cgi?id=83470) So I connected through ssh and I got some error in dmesg just after display froze. I'll be attaching my errors.log file in a moment. You'll see VM is also enabled. I could try without it. Also, it doesn't freezes with commit 69e0b57, I've been using and testing it regularly for the last week and half. So I could bisect if we don't have enough info. -- You are receiving this mail because: You are the assignee for the bug.

1 52

[Bug 61811] kms mode breaks when using radeon.agpmode=-1
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '13

24 Sep '13

https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #13 from Bruno Wolff III <bruno(a)wolff.to> --- Kernel kernel-PAE-3.12.0-0.rc0.git22.2.fc21.i686 which worked for me was based off commit d5d04bb. The next kernel which didn;t work (kernel-PAE-3.12.0-0.rc0.git24.1.fc21.i686) was based on commit 3711d86. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 61811] kms mode breaks when using radeon.agpmode=-1
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '13

24 Sep '13

https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #12 from Dieter Nützel <Dieter(a)nuetzel-hh.de> --- (In reply to Alex Deucher from comment #10) > (In reply to Dieter Nützel from comment #8) > > (In reply to Alex Deucher from comment #6) > > > Can you bisect? > > > > Hello Alex, > > > > I'll try 'cause I get the same with clean 3.12-rc2 + > > 0001-drm-radeon-avoid-UVD-corruption-on-AGP-cards-using-G.patch > > > > radeon.agpmode=8 works as before, but > > radeon.agpmode=-1 gave > > > > [-] > > [ 10.958649] radeon: `-1' invalid for parameter `agpmode' > > [ 11.515274] radeon: `-1' invalid for parameter `agpmode' > > FATAL: Error inserting radeon > > (/lib/modules/3.12.0-rc2-1-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko): > > Invalid argument > > > > We haven't touched anything AGP related in radeon in years. I know. ;-) > Maybe some general kernel module parsing change? That was my thought, too. > > > > Any point to start without git-tree? > > You really need a git tree to bisect. I know, second time, but... ...I'll see what I can find in Linus 3.12-rc1 (maybe before) patch file(s) (logs). For several git trees this system is to small... -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 61811] kms mode breaks when using radeon.agpmode=-1
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '13

24 Sep '13

https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #11 from Bruno Wolff III <bruno(a)wolff.to> --- I believe it was after d5d04bb and up to 3711d86. There weren't any radeon changes in that range that I noticed when I read through the git whatchanged output. It's possible that some patch was added or removed in there, but there wasn't a comment in the spec changelog for the rpms. I can check more carefully to make sure. There were some intel changes and maybe there is some common code. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 61811] kms mode breaks when using radeon.agpmode=-1
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '13

24 Sep '13

https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #10 from Alex Deucher <alexdeucher(a)gmail.com> --- (In reply to Dieter Nützel from comment #8) > (In reply to Alex Deucher from comment #6) > > Can you bisect? > > Hello Alex, > > I'll try 'cause I get the same with clean 3.12-rc2 + > 0001-drm-radeon-avoid-UVD-corruption-on-AGP-cards-using-G.patch > > radeon.agpmode=8 works as before, but > radeon.agpmode=-1 gave > > [-] > [ 10.958649] radeon: `-1' invalid for parameter `agpmode' > [ 11.515274] radeon: `-1' invalid for parameter `agpmode' > FATAL: Error inserting radeon > (/lib/modules/3.12.0-rc2-1-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko): > Invalid argument > We haven't touched anything AGP related in radeon in years. Maybe some general kernel module parsing change? > > Any point to start without git-tree? You really need a git tree to bisect. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 61811] kms mode breaks when using radeon.agpmode=-1
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '13

24 Sep '13

https://bugzilla.kernel.org/show_bug.cgi?id=61811 Dieter Nützel <Dieter(a)nuetzel-hh.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #109551|application/octet-stream |text/plain mime type| | -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 61811] kms mode breaks when using radeon.agpmode=-1
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '13

24 Sep '13

https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #9 from Dieter Nützel <Dieter(a)nuetzel-hh.de> --- Created attachment 109551 --> https://bugzilla.kernel.org/attachment.cgi?id=109551&action=edit dmesg-3.12-rc2-agpmode-1.log -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 61811] kms mode breaks when using radeon.agpmode=-1
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '13

24 Sep '13

https://bugzilla.kernel.org/show_bug.cgi?id=61811 Dieter Nützel <Dieter(a)nuetzel-hh.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Dieter(a)nuetzel-hh.de --- Comment #8 from Dieter Nützel <Dieter(a)nuetzel-hh.de> --- (In reply to Alex Deucher from comment #6) > Can you bisect? Hello Alex, I'll try 'cause I get the same with clean 3.12-rc2 + 0001-drm-radeon-avoid-UVD-corruption-on-AGP-cards-using-G.patch radeon.agpmode=8 works as before, but radeon.agpmode=-1 gave [-] [ 10.958649] radeon: `-1' invalid for parameter `agpmode' [ 11.515274] radeon: `-1' invalid for parameter `agpmode' FATAL: Error inserting radeon (/lib/modules/3.12.0-rc2-1-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko): Invalid argument Welcome to openSUSE 12.3 "Dartmouth" - Kernel 3.12.0-rc2-1-desktop (tty1). [-] Your drm-fixes-3.12 (3.11.0-rc7 in reality) + 0001-drm-radeon-avoid-UVD-corruption-on-AGP-cards-using-G.patch works like a charm. Any point to start without git-tree? -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

← Newer
1
...
62
63
64
65
66
67
68
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2013