GNOME Bugzilla – Bug 659039
[Regression] gnome control centre does not allow you to disable the laptop screen while leaving an external connected screen working
Last modified: 2012-10-20 21:41:39 UTC
Lenovo T500 with displayport has a 1920x1200 monitor attached, I use the displayport in a similar way to a docking station in that I attach the monitor with a displayport to dvi cable, and then expect to be able to switch off the laptops internal display, only leaving the external monitor working. Screen detection works fine, mirrored screen works fine, but disabling the internal display and activating the external display just leads to the screen going black until the timeout has been reached, whereupon it reverts to its previous setting. I have tested this on both Ubuntu 11.10 alpha and betas fully updated as of today and Fedora 16 Alpha LiveCD downloaded today. This works fine on previous versions, it's just the Gnome 3.x series that appear to be broken. Happy to do whatever it takes to get this fixed.
Should also note all logs etc can be found at: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/828623
Created attachment 197540 [details] gnome-control-center (broken case) I am able to reproduce this bug, or a close facsimile. I've collected dmesg logs with kms debug turned on in the kernel, once using gnome-control-center, and once doing the equivalent configuration change with xrandr (which works) for comparison.
Created attachment 197542 [details] Working case using xrandr
Created attachment 197543 [details] Style of corruption I'm seeing
What exactly do you want us to do with drm debug logs? I don't intend on fixing X.org bugs (isn't that your job Bryce? :). The original report also doesn't mention screen corruption (which wouldn't be GNOME's fault anyway, but a by-product of what GNOME does). Do you have any reason to think this is actually a GNOME bug, and not caused by upgraded kernel/X drivers?
@Bastien, the reason I think it is a GNOME bug is because the configuration operation works fine when doing it with xrandr; it is only when doing it with gnome-control-center that it fails. What I want you to do with the drm debug logs is analyze the difference between how xrandr is correctly doing the configuration, and identify where your code is failing to do so.
(In reply to comment #6) > @Bastien, the reason I think it is a GNOME bug is because the configuration > operation works fine when doing it with xrandr; it is only when doing it with > gnome-control-center that it fails. > > What I want you to do with the drm debug logs is analyze the difference between > how xrandr is correctly doing the configuration, and identify where your code > is failing to do so. Give me the gnome-desktop logs, and the output from xrandr -q in both cases then. I don't think I should have to explain this to you...
Created attachment 197623 [details] gnome-settings-daemon.log Using gnome (corrupt screen showing): Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS1 connected (normal left inverted right x axis y axis) 1366x768 60.0 + 40.0 1360x768 59.8 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 DP1 disconnected (normal left inverted right x axis y axis) Using xrandr (same config but working proper): Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS1 connected (normal left inverted right x axis y axis) 1366x768 60.0 + 40.0 1360x768 59.8 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 DP1 disconnected (normal left inverted right x axis y axis)
First, the gnome-desktop logs are gathered a specific way: touch ~/gsd-debug-randr and a ~/gsd-debug-randr.log file will be created with the logs. A couple of questions regarding reproducability: - does it only happen using the Fn+F7 key, or also using the Display panel in the System Settings? Does Win+P show the same corruption problems as Fn+F7? Does switching VTs bring the display back to life? Or do you need to restart X? Or the computer? - If it happens only using the Fn+F7 key, does it happen when calling the XRandR gnome-settings-daemon plugin directly? $ gdbus call --session --dest org.gnome.SettingsDaemon --object-path /org/gnome/SettingsDaemon/XRANDR --method org.gnome.SettingsDaemon.XRANDR_2.VideoModeSwitch "0" FWIW, I cannot see how that could be a GNOME bug in any case, as the driver shouldn't allow the display to get into an unusable state, but peeling off layers of code should help create a reproducer.
Bastien, it's not likely a gnome-control-center bug, Chris Halse Rogers pointed recently that gnome-desktop has issues, he said he would open a bug once he has some extra details. Basically from what I understood he said that the gnome-desktop code assigns outputs to crtcs in sequence without considering output<->crtc limitations i.e if you get VGA can be driven by crtc 0 and 1 LVDS can be driven by ctrc 0 VGA is listed before LVDS in xrandr (the order is not defined by the protocol) gnome-desktop can lead in buggy setups where it starts by assigned VGA to crtc0 and then hits an issue where there is no possible configuration for LVDS
(In reply to comment #10) > Bastien, it's not likely a gnome-control-center bug, Chris Halse Rogers pointed > recently that gnome-desktop has issues, he said he would open a bug once he has > some extra details. > > Basically from what I understood he said that the gnome-desktop code assigns > outputs to crtcs in sequence without considering output<->crtc limitations > > i.e if you get > > VGA can be driven by crtc 0 and 1 > LVDS can be driven by ctrc 0 > VGA is listed before LVDS in xrandr (the order is not defined by the protocol) > > gnome-desktop can lead in buggy setups where it starts by assigned VGA to crtc0 > and then hits an issue where there is no possible configuration for LVDS And then you have a bug in the driver because it creates broken dual-screen setups instead of erroring out... I didn't say that GNOME was bug free, but there's certainly things to fix down the stack that would make it easier to then fix whatever is in the upper levels, such as gnome-desktop.
"I didn't say that GNOME was bug free, but there's certainly things to fix down the stack that would make it easier to then fix whatever is in the upper levels, such as gnome-desktop." I think you make a good point here. The RANDR interface X.org provides is rather low level and leaves a lot to the client to do (and plenty of room for unexpected errors). If more of that were handled at the X level, it would make bugs like this easier to fix. Chris and I are taking an action to put some work into this over the next few months.
I think there *is* a driver bug here, but it's subtle. Just performing the same RANDR operations that gnome-control-centre does works *almost* all of the time, whereas gnome-control-centre fails almost all of the time. I suspect that there's a race somewhere that's more easy to trigger with g-s-d's timing - as far as I can tell, the kernel believes that it's turned on all the appropriate outputs and they're working fine.
So is this bug NOTGNOME then?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!