After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 607035 - laptop does not suspend when lid is closed
laptop does not suspend when lid is closed
Status: RESOLVED OBSOLETE
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
2.28.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-01-14 22:54 UTC by David Tombs
Modified: 2012-07-14 00:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
devkit-power --dump (closed) (1.68 KB, text/plain)
2010-01-18 18:29 UTC, David Tombs
Details
devkit-power --dump (open) (1.59 KB, text/plain)
2010-01-18 18:29 UTC, David Tombs
Details

Description David Tombs 2010-01-14 22:54:36 UTC
Gnome-power-manager is set to suspend on lid close, but when the lid is closed the system does not suspend.

/proc/acpi/button/lid/C1C4/state shows correct state in open and closed case.

See Ubuntu bug at <https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/376793> for more info.
Comment 1 David Tombs 2010-01-14 22:55:36 UTC
Original reporter in Ubuntu bug was using an HP 2140, but others could reproduce the issue with different laptops.
Comment 2 David Tombs 2010-01-14 22:58:17 UTC
Nevermind, all reporters for this specific bug are using the HP 2140.
Comment 3 Richard Hughes 2010-01-15 08:52:13 UTC
(In reply to comment #0)
> Gnome-power-manager is set to suspend on lid close, but when the lid is closed
> the system does not suspend.
> 
> /proc/acpi/button/lid/C1C4/state shows correct state in open and closed case.

Nothing uses /proc/acpi anymore. The more important metric is what DeviceKit-power thinks the state is.

Try running "devkit-power --dump" when the lid is closed and open and see if the lid properties change. It might also be worth trying DeviceKit-power from git master as a debian specific fix was merged recently.
Comment 4 David Tombs 2010-01-18 18:29:18 UTC
Created attachment 151691 [details]
devkit-power --dump (closed)
Comment 5 David Tombs 2010-01-18 18:29:59 UTC
Created attachment 151692 [details]
devkit-power --dump (open)
Comment 6 David Tombs 2010-01-18 18:30:34 UTC
OK, I've attached the dumps from the Ubuntu reporter. Note that the lid status is correct in both.

See the Ubuntu report for more information.
Comment 7 Scott Howard 2010-03-04 15:38:52 UTC
Hello all,

This bug has been reported in Red Hat too. They claim it is a kernel bug, fixed in kernel 2.6.32



https://bugzilla.redhat.com/show_bug.cgi?id=512958

"kynde      2009-12-08 04:12:25 EST

This originates to kernel acpi drivers.

The button.c uses what it gets from acpi_device_bid for the
directory name aswell as for the Lid Switch [%s] printk.

The acpi_device_bid is, if I understood correcrly, filled with
what it gets from drivers/acpi/scan.c:
static void acpi_device_get_busid(struct acpi_device *device)

which in turn defaults to calling acpi_get_name from acpica/nsxfname.c.
Now, why that returns C1D0 rather than LID is beyond me.

And about missing events, I think it has to do with 
acpi_lid_send_state 
 -> acpi_evaluate_integer 
     -> acpi_evaluate_object
         and all the "magic" it does there with names

Someone with more knowledge of kernel acpi internals might want to take a look
at this. I'm willing try any patches or produce debugs etc.

I'll compile the kernel with CONFIG_ACPI_DEBUG later tonight when I have access
to said laptop again (it's my wife's, you see) and check if that shows anything
relevant.    

Comment 6 kynde 2009-12-09 17:09:55 EST

I've just finished testing with the latest fedora 12 kernel (2.6.31.6-162) and
the problem persist, _but_ I compiled the stock 2.6.32 with the config from
said fedora kernel and low and behold, the lid acpi signaling works.

acpi_listen shows the lid events and system suspended when I configured it to
from power management.

This was about the HP mini 5101 and I have no idea what the situation is with
hp mini 2140 what this bug is about.

Hopefully those acpi changes make it to the fedora kernel soon. I glanced
briefly but didn't spot them in 2.6.31.y yet either."
Comment 8 David Tombs 2010-05-29 19:59:10 UTC
The Ubuntu bug has been shown to be a kernel issue, so this issue can be closed as far as I'm concerned.
Comment 9 João Gomes 2010-10-20 22:18:09 UTC
The correction described in
https://bugzilla.redhat.com/show_bug.cgi?id=512958
seems to be only for the cases where /proc/acpi/button/lid/LID0/state does NOT show the correct state.

Though, there are cases where /proc/acpi/button/lid/LID0/state shows the correct state, but the gnome-power-manager does not recognizes the state changes.
In those cases, the workaround suggested in that bug report does not solve the problem. And, in the verbose mode, the gnome-power-manager shows:
"lid is closed, so we are ignoring ->NORMAL state changes" (but the lid is open)

Is this a different problem?
Is there any solution?

Thank you!
Comment 10 João Gomes 2010-10-23 12:22:46 UTC
(In reply to comment #3)
> (In reply to comment #0)
> > Gnome-power-manager is set to suspend on lid close, but when the lid is closed
> > the system does not suspend.
> > 
> > /proc/acpi/button/lid/C1C4/state shows correct state in open and closed case.
> 
> Nothing uses /proc/acpi anymore. The more important metric is what
> DeviceKit-power thinks the state is.
> 
> Try running "devkit-power --dump" when the lid is closed and open and see if
> the lid properties change. It might also be worth trying DeviceKit-power from
> git master as a debian specific fix was merged recently.


In my case this is exactly the problem.
Using upower --dump it says that the lid is closed when it is open:

Daemon:
  daemon-version:  0.9.5
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      yes
  on-low-battery:  no
  lid-is-closed:   yes
  lid-is-present:   yes

That's why the output of gnome-power-manager shows:
"lid is closed, so we are ignoring ->NORMAL state changes"

And that's also why I only experience this problem with gnome-power-manager. Xfce-power-manager works correctly as it uses hal.

However, when I boot the laptop, everything works properly. Only after I close the lid for this first, the problem begins.

I tested this, in the same laptop, in Ubuntu with gpm 2.32 and in Debian with gpm 2.30.

The laptop is an HP dv 1359 with 5 years old.

Is there any workaround or any kind of solution?
Is this the same problem or should I open a different report?

Thank you!
Comment 11 Jean-François Fortin Tam 2012-07-14 00:12:02 UTC
Hi,
This and the downstream bugs have been reported a *very* long time ago, and I'm unable to reproduce this with GNOME 3.4 on Fedora 17 on a Thinkpad X220 (or any other laptop I've used or encountered in the past years).

Reopen this bug if the problem still occurs with a newer version of GNOME, but it is highly probable that this is a kernel bug rather than gnome power manager.