Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 590165 - Suspend on closing laptop lid doesn't work and mouse pointer disappears
Suspend on closing laptop lid doesn't work and mouse pointer disappears
Status: CLOSED DUPLICATE of bug 590090
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-07 17:15 EDT by Uno Engborg
Modified: 2010-05-14 21:59 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-14 21:59:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Uno Engborg 2010-05-07 17:15:30 EDT
Description of problem:


When I close the lid on my Thinkpad R50e, suspend to RAM fails. When I open the lid again the display is still on, but the mouse have disappeared.

If I then press Fn-F4, the screen fades down to black, and the computer is suspended. I can then close the lid and when I open the lid again the computer gets unsuspended, and the mouse pointer is back.

In onter words it looks like the lid switch doesn't work when pressed (i.e closing the lid) but works when it is released (i.e. the lid is opened).

I'm not sure i this is a kernel problem, an acpid problem or something to do with pm-suspend.

The problem occurred after upgrading to the kernel-2.6.33.3-85.fc13.i686, pm-utils-1.2.6.1-1.fc13.i686, it worked at least at some point between then and the version on the fedora 13 beta live CD.

Not suspending when closing the lid could be a problem as it could cause overheating on certain laptops.

Version-Release number of selected component (if applicable):
kernel-2.6.33.3-85.fc13.i686

How reproducible: Always


Steps to Reproduce:
1. Close lid, the computer does not suspend
2. Open the lid and the mouse pointer is gone
3. Press Fn-F4, and the screen fades to black and the computer suspends to RAM
4. Open the lid and the computer resumes, with visible mouse pointer
Comment 1 Fabio Airoldi 2010-05-08 09:39:19 EDT
I can confirm the problem on a dell e6400.
Closing lid does not suspend, however I don't have issues with the mouse.
Suspending via System->shutdown->suspend works and closing and re-opening the lid resumes from suspend.
I'm not sure when this stopped working.

Just for clarity, in my case:

Steps to Reproduce:
1. Close lid, the computer does not suspend
2. system->shutdown->suspend, and the screen fades to black and the computer suspends to RAM
3. Open the lid and the computer resumes, with visible mouse pointer
Comment 2 Albert 2010-05-08 11:16:00 EDT
Same thing on my DELL E6400. In /var/log/messages:

localhost kernel: dell-wmi: Received unknown WMI event (0x11)
Comment 3 hansvon 2010-05-09 19:45:35 EDT
I also have the lid-closing problem (but no mouse pointer problem) on a Dell XPS M1330 and Inspiron 640m, eg same as Comment 1.
I don't see any messages in /var/log/messages.
We're running 2.6.33.3-85.fc13 (one x86_64, one i686).
Comment 4 Chris Bagwell 2010-05-10 23:19:16 EDT
Same issue for me on eee pc 1005pe.  Closing lid suspended fine when I was using kernel-2.6.33.3-79.fc13.i686 (not sure of pm utils).  After yum update on May 9th, it stopped working once it booted to kernel-2.6.33.3-85.fc13.i686.

When I close lid, my backlight is turned off but suspend doesn't happen.  Opening lid correctly turns on backlight but you can tell system was running the whole time lid was closed (disk light would occasionally blink for example).

Output of /proc/acpi/event shows events are working:

button/lid LID 00000080 00000009
button/lid LID 00000080 0000000a

Run dbus-monitor --system shows something related to lid but not sure its correct values:

signal sender=:1.6 -> dest=(null destination) serial=552 path=/org/freedesktop/Hal/devices/computer_logicaldev_input_4; interface=org.freedesktop.Hal.Device; member=PropertyModified
   int32 1
   array [
      struct {
         string "button.state.value"
         boolean false
         boolean false
      }
   ]
signal sender=:1.6 -> dest=(null destination) serial=553 path=/org/freedesktop/Hal/devices/computer_logicaldev_input_4; interface=org.freedesktop.Hal.Device; member=Condition
   string "ButtonPressed"
   string "lid"
signal sender=:1.6 -> dest=(null destination) serial=554 path=/org/freedesktop/Hal/devices/computer_logicaldev_input_4; interface=org.freedesktop.Hal.Device; member=PropertyModified
   int32 1
   array [
      struct {
         string "button.state.value"
         boolean false
         boolean false
      }
   ]
signal sender=:1.6 -> dest=(null destination) serial=555 path=/org/freedesktop/Hal/devices/computer_logicaldev_input_4; interface=org.freedesktop.Hal.Device; member=Condition
   string "ButtonPressed"
   string "lid"


Suspend does work if I select it from Gnome's Shut Down prompt.
Comment 5 Chris Bagwell 2010-05-11 22:55:57 EDT
I now suspect this is an issue with an upgrade to gnome-power-manager or resources it uses.  The rational is because gnome-power-manager is were you set the preference that closing lid should invoke Suspend.

Also, I noticed today that when I remove power cord the gnome-power-manager job of dimming the display did not occur.  I believe I'm also now missing some battery related notification messages as well.

As a side note, I have an unrelated app I wrote that monitors dbus for org.freedesktop.UPower and signal Changed and that is no longer being detected after this same upgrade.  I didn't think UPower monitored lid's but perhaps that is real source of issue.
Comment 6 Chris Bagwell 2010-05-14 19:51:32 EDT
I noticed Fedora 13 updates-testing email mentioned an update to upower and a bug description about failing to suspend/hibernate when lid closed.  For me, it turned out a duplicate of bugzilla #590090 .

A "yum --enablerepo updates-testing update upower" and then rebooting fixed the issue for me.
Comment 7 Masood 2010-05-14 21:42:00 EDT
upower-0.9.4-1 from updates-testing has also fixed the same issue on XPS M1330.
Comment 8 Masood 2010-05-14 21:59:35 EDT

*** This bug has been marked as a duplicate of bug 590090 ***

Note You need to log in before you can comment on or make changes to this bug.