dv1550se: upower never registers lid-open event though ACPI does

Bug #561656 reported by S. Christian Collins
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
upower (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

Binary package hint: gnome-power-manager

** Bug Description **
When I unplug the AC power from my laptop, the screen dims, and then 2-4 seconds thereafter, a lid-close event is registered and my screen either goes blank or the laptop suspends, depending on my power settings for closing the laptop lid.

Note that upower shows lid closed while ACPI (correctly) shows lid open when this happens.

** What's Expected **
A lid-close event shouldn't be registered unless the lid is actually closed.

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
OS: Ubuntu 10.04 w/ all updates as of 4/12/10 (including 2.6.32-20 kernel)

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: gnome-power-manager 2.30.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-20.29-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-20-generic i686
Architecture: i386
Date: Mon Apr 12 11:38:15 2010
GnomeSessionIdleInhibited: No
GnomeSessionInhibitors: None
GnomeSessionSuspendInhibited: No
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100318)
Lsusb:
 Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Hewlett-Packard HP Pavilion dv1000 (EP347UA#ABA)
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-20-generic root=UUID=164da737-2a0a-475d-a225-1cf917e16806 ro quiet splash
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: gnome-power-manager
dmi.bios.date: 12/22/2005
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: F.21
dmi.board.name: 308F
dmi.board.vendor: Quanta
dmi.board.version: 46.13
dmi.chassis.type: 10
dmi.chassis.vendor: Quanta
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnHewlett-Packard:bvrF.21:bd12/22/2005:svnHewlett-Packard:pnHPPaviliondv1000(EP347UA#ABA):pvrRev1:rvnQuanta:rn308F:rvr46.13:cvnQuanta:ct10:cvrN/A:
dmi.product.name: HP Pavilion dv1000 (EP347UA#ABA)
dmi.product.version: Rev 1
dmi.sys.vendor: Hewlett-Packard
---
ApportVersion: 2.0.1-0ubuntu11
Architecture: i386
DistroRelease: Ubuntu 12.04
InstallationMedia: Kubuntu 11.04 "Natty Narwhal" - Release i386 (20110427)
Package: upower 0.9.15-3git1
PackageArchitecture: i386
ProcEnviron:
 LANGUAGE=en_US
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.2.0-26.41-generic 3.2.19
Tags: precise
Uname: Linux 3.2.0-26-generic i686
UpgradeStatus: Upgraded to precise on 2012-05-01 (81 days ago)
UserGroups: adm admin audio cdrom dialout lpadmin plugdev sambashare

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :
Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Well, on April 28, 2010, I tested this and was unable to reproduce this bug, so I am closing it.

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Never mind... just tested again and it's still happening. Don't know why it was working earlier. I had my lid close event set to blank screen. When I tested and disconnecting the power didn't blank my screen any more, I thought I could safely set my lid close event back to suspend. Now that I have done that, when I disconnect the AC power, my computer suspends. Changed it back to "Blank Screen", and now it's back to blanking the screen when I disconnect AC power. Better than suspending every time, I guess. Grrr... this is frustrating; I thought this bug had finally been fixed, but I can't find the old bug report.

Revision history for this message
urbandk (evans33) wrote :

This affects me as well and has always happened on every Ubuntu release. I am running fully patched lucid 10.04 on a Dell Inspiron 700m. If the power cord accidentally falls out or if I plug the computer in, Ubuntu responds as though I closed the lid. Consequently, I have set lid close to blank screen instead of suspend. I've had general power difficulties on this computer with it failing to hibernate on critical battery and the battery going completely dead. I'm not very technically saavy, but I can follow explicit directions if you need information from my machine.

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Per David Tombs' comment #55 in bug #481312 (https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/481312/comments/55), this is a upower bug, not gnome-power-manager.

affects: gnome-power-manager (Ubuntu) → upower (Ubuntu)
Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Just some additional info: I can't always trigger this bug, but these steps will trigger it for sure on my system:
1) With the AC power connected, start up Ubuntu and log in.
2) Make sure Ubuntu is set to blank the screen upon lid close (for both battery and AC modes).
3) Close the lid--wait a few seconds--open the lid again. Unlock the screen if necessary to get back to your desktop.
4) Now, unplug the AC power and wait a few seconds. Right at the same instant the "battery discharging" message appears, my screen will go black.

Hope this helps.

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

I created a script that checks the status of /proc/acpi/button/lid/LID/state over time. I ran it while I reproduced the bug (disconnected AC, screen went blank), and /proc/acpi/button/lid/LID/state correctly reported the lid as "open" the whole time.

Revision history for this message
David Tombs (dgtombs) wrote :

s-chriscollins: Just to confirm, "upower --dump" disagrees with /proc/acpi/button/lid/LID/state sometimes?

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Yes, David, I can confirm this. After starting the laptop, "upower --dump" reports the lid as open. After I close the lid and then re-open it, however, "upower --dump" will report the lid as closed (even though /proc/acpi/button/lid/LID/state says it's open), and will continue to do so for a while (I'm not sure if it ever realizes that the lid is open). If I suspend and resume, then upower will properly report the lid as open, until I close it again.

Revision history for this message
David Tombs (dgtombs) wrote :

Hi, sorry for the slow response.

Can you attach the output of "upower --monitor-detail" during these events? Something like:

1) Boot up.
2) upower --monitor-detail | tee upower.log
3) Close the lid.
4) Open the lid.
5) Ctrl+C the upower command.
6) Attach upower.log here.

Thanks!

Changed in upower (Ubuntu):
status: New → Incomplete
Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Here's the upower log generated per your instructions. It seems that only the lid close event was registered--no separate event seems to be logged for the lid opening.

Revision history for this message
David Tombs (dgtombs) wrote :

Thanks, s-chriscollins. I'm confirming this bug and updating the title to reflect the real issue.

Changed in upower (Ubuntu):
status: Incomplete → Confirmed
summary: - disconnecting AC power registers as lid close event
+ dv1550se: upower never registers lid-open event though ACPI does
Revision history for this message
David Tombs (dgtombs) wrote :

Note that doing the lid-close event upon pulling the power plug is expected and valid behavior. The real issue is that upower thinks your lid is closed when it's open (even before pulling the plug).

Revision history for this message
David Tombs (dgtombs) wrote :

Do you still have this issue in 11.10?

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Yes, the bug still exists in 11.10. "upower --dump" shows that upower still thinks the lid is closed after it has been closed and then opened, while /proc/acpi/button/lid/LID/state reports that the lid is indeed open.

Revision history for this message
David Tombs (dgtombs) wrote :

OK, thanks for the info. In 11.10, however, the lid close event should not be triggered when you unplug your laptop, correct?

And just to confirm, the /proc/acpi value is always correct (open when open, closed when closed), while the upower value is correct until you close it for the first time, after which it remains closed?

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

David wrote:
> And just to confirm, the /proc/acpi value is always correct (open when open, closed
> when closed), while the upower value is correct until you close it for the first time,
> after which it remains closed?

Yes, this is the behavior.

David wrote:
> In 11.10, however, the lid close event should not be triggered when you unplug
> your laptop, correct?

The lid close event is triggered both when I unplug or plug in my laptop, but only if upower is reporting the lid as closed.

Revision history for this message
David Tombs (dgtombs) wrote :

Sorry for the lack of activity here. Same behavior for 12.04?

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Yes, same behavior.

Revision history for this message
David Tombs (dgtombs) wrote :

OK, since so much has changed since you reported this bug, please run:

apport-collect 561656

This will refresh the collected information.

Changed in upower (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
S. Christian Collins (s-chriscollins) wrote : Dependencies.txt

apport information

tags: added: apport-collected precise
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for upower (Ubuntu) because there has been no activity for 60 days.]

Changed in upower (Ubuntu):
status: Incomplete → Expired
Revision history for this message
David Tombs (dgtombs) wrote :

Oops, sorry for letting this expire. I was going to report this to upstream upower when I came across this bug report: <https://bugs.freedesktop.org/show_bug.cgi?id=32230>

Would you mind trying to use acpi_listen[1] to see if it detects the lid open event as well as the lid closed? Thanks, and sorry again for the delay.

[1] http://linux.die.net/man/8/acpi_listen

description: updated
Changed in upower (Ubuntu):
status: Expired → Incomplete
Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Using acpi_listen, my laptop generates lid events when the lid closes, but not when it opens. I compared this to another laptop and the second laptop generates laptop lid events both when opening and closing the lid. The lid events look like this:

button/lid LID 00000080 00000001

...and each subsequent event has a higher number than the last, eg.:

button/lid LID 00000080 00000002
button/lid LID 00000080 00000003
button/lid LID 00000080 00000004
...

Revision history for this message
David Tombs (dgtombs) wrote :

Hmm, interesting. Based on my Googling it's probably a kernel bug then. Since this bug is old and has been through a lot, please run 'ubuntu-bug linux' to report a new bug against the kernel and mention that /proc/acpi/button/lid/LID/state is always correct, but upower --dump is not and acpi_listen does not print lid open events. And mention this bug in there and that bug in here. Thanks! Hopefully this will lead us to a solution.

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

Sorry for the delay. Somebody else is currently borrowing my laptop, so I will do as you said in comment #25 when I get it back again.

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

I have done as you asked. The new bug is: bug #1073029

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.