GNOME Bugzilla – Bug 672030
gnome-settings-daemon always prevents suspend on macbookpro5,3
Last modified: 2012-07-18 19:07:46 UTC
1. Ubuntu precise (development branch) 12.04 2. Installed: 3.3.91-0ubuntu2 Candidate: 3.3.91-0ubuntu2 Version table: *** 3.3.91-0ubuntu2 0 500 http://ro.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages 100 /var/lib/dpkg/status 3. When closing the lid, the machine (MacbookPro 5,3) doesn't suspend. Using suspend from the power menu, or using pm-suspend works fine. The lid action is detected fine, and upower reports lid close correctly. Running gnome-settings-daemon --debug gives me the following output: -- ** DEBUG: Syncdaemon not running, waiting for it to start in NameOwnerChanged === Applying Configuration Configuration === Clone: false Output: Unknown attached to default status: on width: 1440 height: 900 rate: 50 primary: true position: 0 0 power-plugin-DEBUG: keyboard toggle on power-plugin-DEBUG: lid is closed; not suspending nor hibernating since some external monitor outputs are still active ** DEBUG: Updating client: index=43 name='gnome-settings-daemon' ** DEBUG: Updating client: index=43 name='gnome-settings-daemon' ** DEBUG: Updating sink: index=0 name='alsa_output.pci-0000_00_08.0.analog-stereo' description='Built-in Audio Analog Stereo' map='front-left,front-right'
Created attachment 209674 [details] [review] If only 1 monitor attached, must be a laptop screen. Don't prevent suspend
Some investigations: The problem seems to be related to non_laptop_outputs_are_all_off in plugins/power/gsd-power-manager.c Also possible culprits could be is_laptop and gnome_rr_output_is_laptop. My Display name is Apple DFP, so it doesn't seem to be caught by gnome_rr_output_is_laptop However, detecting if it is a laptop monitor by name seems a bit flaky. Since I don't have any external monitors connected, it seems that a workaround would be to also count how many displays we have in total. If the number is 1, and since this is a laptop (lid event, etc), is there any case where the one display isn't the laptop display ? I am attaching a patch that fixes (probably incorrectly) the issue for me.
Counting the outputs just won't do. If you used only the external monitor, you would have only one output, defeating the goal. Instead, we can work-around it. Does the patch attached fix the problem? Are you using the NVidia driver, or the nouveau one? What's the output of "xrandr -q" on your machine?
Created attachment 209683 [details] [review] gnome-rr: Detect Apple DFP outputs as internal As used in MacBookPro5,3
Xrandr output: --- xrandr: Failed to get size of gamma for output default Screen 0: minimum 320 x 175, current 1440 x 900, maximum 1440 x 900 default connected 1440x900+0+0 0mm x 0mm 1440x900 50.0* 1360x768 51.0 52.0 1152x864 53.0 1024x768 54.0 55.0 56.0 57.0 960x600 58.0 960x540 59.0 840x525 60.0 61.0 62.0 832x624 63.0 800x600 64.0 65.0 66.0 67.0 68.0 69.0 70.0 800x512 71.0 720x450 72.0 720x400 73.0 700x525 74.0 75.0 76.0 680x384 77.0 78.0 640x512 79.0 80.0 81.0 640x480 82.0 83.0 84.0 85.0 86.0 87.0 640x400 88.0 640x350 89.0 576x432 90.0 91.0 92.0 93.0 94.0 95.0 96.0 512x384 97.0 98.0 99.0 100.0 101.0 416x312 102.0 400x300 103.0 104.0 105.0 106.0 107.0 360x200 108.0 320x240 109.0 110.0 111.0 112.0 320x200 113.0 320x175 114.0
Also, I am using the binary NVidia driver.
The proposed patch (gnome-rr: Detect Apple DFP outputs as internal) doesn't seem to work. Here's how the display looks like in Xorg.0.log [ 11.329] (--) NVIDIA(0): Connected display device(s) on GeForce 9400M at PCI:3:0:0 150 [ 11.329] (--) NVIDIA(0): Apple (DFP-0) 151 [ 11.329] (--) NVIDIA(0): Apple (DFP-0): 330.0 MHz maximum pixel clock 152 [ 11.329] (--) NVIDIA(0): Apple (DFP-0): Internal Dual Link LVDS 153 [ 11.333] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display 154 [ 11.333] (**) NVIDIA(0): device Apple (DFP-0) (Using EDID frequencies has been 155 [ 11.333] (**) NVIDIA(0): enabled on all display devices.) 156 [ 11.366] (II) NVIDIA(0): Assigned Display Device: DFP-0 The name DFP seems to come from the Nvidia driver, from Digital Flat Panel.
I've pushed "gnome-rr: Detect Apple DFP outputs as internal" as it really should fix your problem. Can you make sure you're really linking against the new version of gnome-desktop and make sure you're running a new version of gnome-settings-daemon please. If this doesn't work for you with all package versions up to 3.3.92 then please re-open this bug. Thanks.
I'm pretty sure it doesn't because the NVidia binary driver doesn't report output names properly. You should add a "list-outputs" tool to gnome-desktop to output everything that is known about the outputs, including EDID, output names and guessing types, etc. Would make a good debug tool (I mentioned this to Olivier already).
(In reply to comment #9) > I'm pretty sure it doesn't because the NVidia binary driver doesn't report > output names properly. You should add a "list-outputs" tool to gnome-desktop to > output everything that is known about the outputs, including EDID, output names > and guessing types, etc. Would make a good debug tool (I mentioned this to > Olivier already). I've got something like that here already: http://people.freedesktop.org/~hughsient/temp/test-gnomerr.c which displays things like: [LVDS1] connected: 1 laptop: 1 primary: 1 id: 65 edid: 128 bytes [0:255:255:255] [VGA1] connected: 0 laptop: 0 primary: 0 id: 66 Yell if you want me to commit something like that and hook it into the buildsystem. Richard.
I would add the "nice name" (Hitachi 23" for example) for monitors that have them. But yes, very useful addition. And Andrei can test after that :)
Created attachment 209926 [details] [review] test utility Something like this? Comments welcome.
Also see https://bugs.freedesktop.org/show_bug.cgi?id=26736 - it's about making drivers set the ConnectorType property so clients (including GnomeRR) can find the laptop's display without resorting to heuristics like checking output names. So far, only radeonhd has cared enough to implement that property.
Downstream response: The upstream patch doesn't work for me. output->name is 'default' on my system w/ the NVIDIA binary driver, not something with the string 'DFP'. Using the 'test-gnomerr' program from the upstream bug, I get the following output: steve@steve-laptop:~/src/test-gnomerr$ ./test-gnomerr [default] connected: 1 laptop: 0 primary: 1 id: 352
Giving it a go with the debugging tool, I get pretty much the same results as Martin: [<adragomi@adragomi-mbp>][~/temp/source/ubuntu/gnome-desktop3] $ ./libgnome-desktop/gnome-rr-debug [default] connected: 1 laptop: 0 primary: 1 id: 355 So, apparently the display name is "default", which doesn't help the detection much.
I'd just like to add, that this problem is not limited to Apple devices - Dell devices with nVidia graphics and binary drivers (M1330, E6500, etc.) are suffering from same problems.
This is a problem with the NVidia proprietary driver, as shown with the debug output. Hopefully we'll get XRandR enabled drives from NVidia at some point.
Just for the record, in Ubuntu a patch got applied to also treat "default" as an internal display. If the video driver doesn't do xrandr properly (NVidia), we can't tell the difference between internal and external, and then we consider it better to keep suspend on lid close (as in earlier releases) than avoiding suspend with external monitors. This is mostly a matter of opinion of course, and I don't expect upstream to do the same, I just wanted to point it out for full disclosure.
NVidia should be getting randr support soon, so it won't be a problem too much longer. As far as I can tell from some google searches, ATI doesn't have randr support either, and we've agreed to whitelist their equally ambiguous "LCD" name. I don't see a reason why "default" is all that different. Also, we have this as a regression, since it used to suspend regardless of external displays, and it should probably suspend if there is a "lid close" and only one display, fix as in comment #1
(In reply to comment #18) > Just for the record, in Ubuntu a patch got applied to also treat "default" as > an internal display. This makes sense. Can you please attach the patch (or is it just as trivial as putting "default" as the others)? (In reply to comment #19) > regression, since it used to suspend regardless of external displays, and it > should probably suspend if there is a "lid close" and only one display, fix as > in comment #1 See bug #657201 for the discussion about this; the current policy indeed needs refinement.
Created attachment 211192 [details] [review] Treat "default" display as internal Yes, it's indeed trivial, just adding "default" to the list.
Thanks! Pushed to master as commit cc326c0.
Reverted the patch in comment 4, which wasn't useful anyway, and ended up creating false positives. commit e4ec79dd9ce45e4f2288da1e818a93e38a6e8949 Author: Bastien Nocera <hadess@hadess.net> Date: Mon Jul 16 15:30:33 2012 +0100 gnome-rr: Don't mark DFP outputs as internal Too many false positives, and the bug that it was supposed to fix, on the MacBook Pro, wasn't actually fixed by that check. See: https://bugzilla.gnome.org/show_bug.cgi?id=679858 and: https://bugzilla.gnome.org/show_bug.cgi?id=672030
Is that DFP problem with nouveau? (then it should be made to support the ConnectorType property) Or is it with the proprietary NVidia driver, and it still doesn't do RANDR 1.2?