Closing laptop lid does not suspend

I'm not sure if this is by design or not. Assigning to the Desktop Team to take a look.

It's not by design. Please give me the output of

  gsettings list-recursively org.gnome.settings-daemon.plugins.power | grep lid

jtait@sixtymilesmile:~$ gsettings list-recursively org.gnome.settings-daemon.plugins.power | grep lid
org.gnome.settings-daemon.plugins.power lid-close-ac-action 'suspend'
org.gnome.settings-daemon.plugins.power lid-close-battery-action 'suspend'

I verified that this is still a current issue for me. Closing the lid does blank the screen, but doesn't lock it and doesn't suspend.

James Tait [2012-03-13 11:34 -0000]:
> jtait@sixtymilesmile:~$ gsettings list-recursively org.gnome.settings-daemon.plugins.power | grep lid
> org.gnome.settings-daemon.plugins.power lid-close-ac-action 'suspend'
> org.gnome.settings-daemon.plugins.power lid-close-battery-action 'suspend'

That looks correct.

> I verified that this is still a current issue for me. Closing the lid
> does blank the screen, but doesn't lock it and doesn't suspend.

Does suspend work if you explicitly request it through the session
indicator?

Yes, requesting suspend through the session indicator works as expected. I do recall having to add a boot parameter to get that to work. If I'm not mistaken, "acpi_sleep=nonvs" was the one, but I also have nomodeset.

OK, so the machinery seems to work. Can you please attach your ~/.xsession-errors, or have a look yourself, searching for "lid", "suspend", "power", etc.? It might have a relevant error message.

If not, it's worth trying this:

  killall gnome-settings-daemon # do it two or three times until it doesn't auto-respawn
  gnome-settings-daemon --debug 2>&1 | tee /tmp/gsd.log

then close the lid, open it again, Control-C it, and attach /tmp/gsd.log.

Thanks!

Running gnome-settings-daemon without debug output produced nothing when the lid was closed.

Running it with the debug output produced the attached - notably, gsd seems to think there is still an external monitor connected, which there definitely isn't.

Ah, that would be it. Can you please give us the output of "xrandr"?

jtait@sixtymilesmile:~$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 175, current 1920 x 1080, maximum 1920 x 1080
default connected 1920x1080+0+0 0mm x 0mm
   1920x1080 50.0* 51.0 52.0
   1680x1050 53.0
   1600x1024 54.0
   1440x900 55.0
   1400x1050 56.0
   1360x768 57.0 58.0
   1280x1024 59.0 60.0
   1280x960 61.0
   1152x864 62.0 63.0 64.0 65.0 66.0 67.0 68.0
   1024x768 69.0 70.0 71.0 72.0 73.0 74.0
   960x720 75.0
   960x600 76.0
   960x540 77.0
   928x696 78.0 79.0
   896x672 80.0 81.0
   840x525 82.0 83.0 84.0 85.0 86.0
   832x624 87.0
   800x600 88.0 89.0 90.0 91.0 92.0 93.0 94.0 95.0 96.0 97.0
   800x512 98.0
   720x450 99.0
   720x400 100.0
   700x525 101.0 102.0 103.0 104.0
   680x384 105.0 106.0
   640x512 107.0 108.0 109.0
   640x480 110.0 111.0 112.0 113.0 114.0 115.0
   640x400 116.0
   640x350 117.0
   576x432 118.0 119.0 120.0 121.0 122.0 123.0 124.0
   512x384 125.0 126.0 127.0 128.0 129.0
   416x312 130.0
   400x300 131.0 132.0 133.0 134.0 135.0
   360x200 136.0
   320x240 137.0 138.0 139.0 140.0
   320x200 141.0
   320x175 142.0
jtait@sixtymilesmile:~$

I've encountered the same regression in 12.04. From a bit of digging it seems it's related to the implementation of gnome_rr_output_is_laptop() in gnome-desktop. g-s-d uses this function to determine whether an output is an internal or external display; g-s-d only wants to suspend if there are no external displays in use. The problem is that gnome_rr_output_is_laptop() doesn't work properly in some cases. One case is when the NVIDIA binary driver is present; another recently-fixed case was systems with eDP panels (bug 933710).

There is a patch in bug 949296 that fixes the problem for me (I have the NVIDIA driver case).