Closing laptop lid does not suspend

Bug #948844 reported by James Tait on 2012-03-07
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gnome-settings-daemon (Ubuntu)
Undecided
Canonical Desktop Team

Bug Description

I can't pinpoint exactly when this started (or rather, stopped) happening, but at some time in the last week suspend on lid close stopped working for me, in spite of the settings in the Power applet.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: gnome-power-manager 3.3.3-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.94-0ubuntu2
Architecture: amd64
CheckboxSubmission: dd3689fa6394f60ec14dbe98d0bab891
CheckboxSystem: b633b4f40868d491c2ae5b50030ce6f3
Date: Wed Mar 7 10:30:05 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
SourcePackage: gnome-power-manager
UpgradeStatus: Upgraded to precise on 2012-01-13 (53 days ago)

James Tait (jamestait) wrote :

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

Changed in gnome-power-manager (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Martin Pitt (pitti) wrote :

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

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

affects: gnome-power-manager (Ubuntu) → gnome-settings-daemon (Ubuntu)
Changed in gnome-settings-daemon (Ubuntu):
status: New → Incomplete
James Tait (jamestait) wrote :

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?

James Tait (jamestait) wrote :

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.

Martin Pitt (pitti) wrote :

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!

James Tait (jamestait) wrote :

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.

Martin Pitt (pitti) wrote :

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

James Tait (jamestait) wrote :

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:~$

Steve Magoun (smagoun) wrote :

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).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers