HP 2140 Lid Close Not Detected

Bug #376793 reported by Jeremy Nickurak
132
This bug affects 20 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Jaunty by cosmix
Nominated for Lucid by Jan Pinkas

Bug Description

Binary package hint: gnome-power-manager

 Nothing occurs in response to closing the lid on the HP 2140. /proc/acpi/

/proc/acpi/button/lid/C1C4/state correctly reads either

state: open
 or
state: closed

depending on the state of the lid. Gnome-power-manager is set to suspend on lid close when running on batteries (which I am). Suspend works correctly when used manually (selecting suspend from the quit/logout dialog)

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Gnome power manager Version 2.24.2 in Jaunty

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Bigger problem, that seems to be related: When I suspend manually, and then resume, the screensaver isn't active or locked, so if I suspend my system, anyone can come by and open it and access everything.

Revision history for this message
Valde_91 (claudio-brenni) wrote :

I Jeremy!

For the locking problem: have you disabled the lock options in the gnome-power-settings present in the gconf-editor? Check if this are enabled.

bye bye Valde

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Looks fine.

Andrej Zirko (dixon85)
Changed in gnome-power-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
joko (giorgiochiodi) wrote :

same here:
while "/proc/acpi/button/lid/C1C4/state" is able to recognize the status of the lid (open/closed), "power history" doesn't record it and standby doesn't kick in.

Revision history for this message
Toby Corkindale (tjc-wintrmute) wrote :

I thought I'd give the latest mainline kernel a go, which at time of writing was 2.6.30-rc6.
Results were identical to the standard Jaunty kernel. ie. Lid close is detected in /proc/acpi but suspend is not triggered.

Revision history for this message
Toby Corkindale (tjc-wintrmute) wrote :

It seems likely that Bug #44058 is related or even a duplicate of this one..?

Revision history for this message
Scott Howard (showard314) wrote :

@Toby: Bug 44058 is about an incorrect reporting of the state of the lid. This report is about the correct state, it is just not turning on the standby. Bug 223192 may be a duplicate of this one, however.

@Jeremy: Could you please attach the resulting log files of:

/usr/share/gnome-power-manager/gnome-power-bugreport &> gpm.log

gconftool --recursive-list /apps/gnome-power-manager > gpm.gconf.values.txt

and:

1) run: dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'" 2) close and open your lid 3) post the output from dbus-monitor

1) run: "lshal -m > lshal.log.txt" 2) close and open your lid 3) attach lshal.log.txt to the bug report. This may be a problem with HAL/pm-utils.

Thanks in advance.

Changed in gnome-power-manager (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Here we go:

dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'", and closing/opening the lid returned only:

signal sender=org.freedesktop.DBus -> dest=:1.287 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.287"

lshal -m produced nothing on lid open/close.

Revision history for this message
Jeremy Nickurak (nickurak) wrote :
Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Wasn't clear if you needed it, but the output from just dbus-monitor:

signal sender=org.freedesktop.DBus -> dest=:1.292 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.292"
method call sender=:1.292 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='method_call'"
method call sender=:1.292 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='method_return'"
method call sender=:1.292 -> dest=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='error'"

Changed in gnome-power-manager (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Toby Corkindale (tjc-wintrmute) wrote :

I tried running the dbus-monitor script, and lshal, under kernel 2.6.30-rc6 too.. Same result, ie. identical to Jeremy's post above.

I did this while on battery power, as I think someone else mentioned maybe that would make a difference.. but it didn't.

Revision history for this message
Scott Howard (showard314) wrote :

Thanks to both of you for taking the time to report this bug, debug it, and helping to make Ubuntu better. I found that this particular bug has already been reported and is a duplicate of bug 44058, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. The bug has already been posted upstream, so someone at gnome-power-manager will be working on it (hopefully). Additionally, any further discussion regarding the bug should occur in the other report. Please continue to report any other bugs you may find.

Changed in gnome-power-manager (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Scott Howard (showard314) wrote :

Sorry for the extra email, this bug isn't a duplicate - the bug listed on the other report does not report the correct ACPI state while the bug here does. I'm marking as confirmed, and we should watch http://bugzilla.gnome.org/show_bug.cgi?id=565661 to see if it fixes your problem too since the symptoms and hardware are similar. I'm not marking it as the upstream bug for this, since it is a little different.

Changed in gnome-power-manager (Ubuntu):
status: Invalid → Confirmed
Changed in gnome-power:
status: Unknown → In Progress
Revision history for this message
Jeremy Nickurak (nickurak) wrote :

The patches discussed on b.g.o's #565661 do not address my issue. Unclear if they fix the issue described in 565661 for other people.

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Another potentially relevant observation:

The laptop doesn't resume when I open the lid either.

Revision history for this message
Valde_91 (claudio-brenni) wrote :

Hi!

I upgraded my kernel to 2.6.29.4, but this problem with the lid is still present. I'm still researching the precise situation, but sometimes my hp 2140 behaves correctly when I close the lid, in my case that's means that the machine goes in standby. The only thing that I noticed is that happens after a forced switch off. In fact sometimes my Hp 2140 hangs on the login splash with the keyboard and the mouse blocked, then I force the reboot by holding the power button. When I restart the machine, the machine behaves correctly and gnome-power works perfectly.

I've also noticed what Jeremy has pointed out, also when the machine behaves correctly, it doesn't resume when I open the lid.

Bye valde

Revision history for this message
Scott Howard (showard314) wrote :

Since Jeremy has tested the patch on b.g.o (it did not fix his problem) and the symptoms are different from (although similar to) those reported in bug #44058, I'm removing the bug watch.

@Jeremy: It may be worth filing your own bug report on gnome's bugzilla with your unique systems, then post a link to that report here.

Thanks to everyone for there help on this.

Changed in gnome-power:
importance: Unknown → Undecided
status: In Progress → New
Revision history for this message
Toby Corkindale (tjc-wintrmute) wrote :

Hi,
just noting that on Karmic (beta) the problem is still present on my HP MiniNote 2140.

-Toby

Revision history for this message
Johannes Knaus (johannesknaus) wrote :

Hi,
I installed the Karmic final release yesterday on my 2140 (new install - no upgrade - I erased the jaunty partition).
And now: It works!
Closing the lid puts my 2140 to suspend now.

-Johannes

Revision history for this message
Toby Corkindale (tjc-wintrmute) wrote :

Hi,
On final Karmic release, I ran:
1) dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'"
2) lshal -m

And opened and closed the lid. In both cases, there was no log output at all other than the initial start-up messages from those commands.
I then unplugged the AC cable and repeated the tests - again, no results, and no suspend.

However checking /proc/acpi/button/lid/C1C4/state does show it reading "closed" when the lid is shut.

This is a system which was upgraded from Jaunty to Karmic the other day.
I've checked, and the gnome-power-manager settings *do* have it set to 'Suspend when lid is closed', on both battery and AC power.

-Toby

David Tombs (dgtombs)
Changed in gnome-power:
importance: Undecided → Unknown
status: New → Unknown
MarcRandolph (mrand)
Changed in gnome-power-manager (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Gyorgyi Toth (tgyorgyi27) wrote :

I am running Karmic updated from Jaunty with the latest mainstream kernel.

In my case standby is initiated if I close the lid, but when on AC power, I set it to just turn of the screen, and this is not working properly: that is, the screen goes black in an almost-closed state, but then the backlight is turned on again when the screen the lid is fully closed.

Opening and closing generates messages in lshal -m:

13:23:42.378: computer_logicaldev_input_3 property button.state.value = true
13:23:42.386: computer_logicaldev_input_3 condition ButtonPressed = lid
13:23:43.133: computer_logicaldev_input_0 condition ButtonPressed = switch-videomode
13:23:43.339: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
13:23:47.744: computer_logicaldev_input_3 property button.state.value = false
13:23:47.786: computer_logicaldev_input_3 condition ButtonPressed = lid
13:23:49.241: computer_logicaldev_input_0 condition ButtonPressed = switch-videomode
13:23:49.471: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode

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

Could someone experiencing the issue please attach the output of "devkit-power --dump" both when the lid is closed and when it is open? g-p-m does not use acpi, at least directly.

@Gyorgyi, just to be clear, you have an HP 2140 as well?

Changed in gnome-power-manager (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Attaching. The diff indicates:

< lid-is-closed: yes
---
> lid-is-closed: no

Revision history for this message
Jeremy Nickurak (nickurak) wrote :
Changed in gnome-power-manager (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Jeremy Nickurak (nickurak) wrote :

A few things related I've noticed about this issue.

1) While the lid is closed, the screen is actually left on, meaning it's still drawing power. Makes this a little more severe, and explains why my battery's been dying so much faster than I expected.

2) When the lid closure is triggered, I can see (by peering through a slight crack) that the screen does turn off, then about half a second to a second later turns back on, and the screen flickers.

3) When the lid is opened, the screen flickers once again.

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Both sets of screen flickers take about a second to complete... so it's very noticable. Not sure if the same thing occurs with other laptops.

Revision history for this message
Toby Corkindale (tjc-wintrmute) wrote :

That's curious.. I ran the devkit-power dumps, both on AC and battery power, lid opened and closed. In all four cases the lid was reported as open:
tobyc@hp-mini:~$ grep lid-is-closed devkit-*.txt
devkit-ac-power-closed.txt: lid-is-closed: no
devkit-ac-power-open.txt: lid-is-closed: no
devkit-battery-power-closed.txt: lid-is-closed: no
devkit-battery-power-open.txt: lid-is-closed: no

Full dumps attached -- combined into one file, since Launchpad only allows a single attachment, that I can tell.

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

Thanks for the info, everyone.

@Jeremy: I've copied your devkit dumps to the uptream bug report, thanks a bunch. It'll probably be more useful to continue discussion there with the g-p-m developer, Richard Hughes.

@Toby: Interesting. I guess you have a different issue. You should probably file a different report against devicekit-power.

Revision history for this message
Gyorgyi Toth (tgyorgyi27) wrote :

@David: yupp, HP 2140

Currently using kernel 2.6.31-20
No change, everything is as above.

devkit-power --dump same as above, lid-is-closed is on "no" when lid is open and on "yes" when lid is closed

Revision history for this message
Jan Pinkas (jan-pinkas) wrote :

Ubuntu 10.04 alpha3, same problem, lid close == no sleep mode.

Revision history for this message
Scott Howard (showard314) wrote :

Update on this bug:
David Tombs reported it to the gnome-power-manager author [1]. It would be best to coordinate fixing of the bug at gnome's bugzilla site. Can someone check out what sounds like a similar bug in Red Hat? They have moved that bug to the kernel (fixed in stock kernel 2.6.32):

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

[1] https://bugzilla.gnome.org/show_bug.cgi?id=607035
[2] https://bugzilla.redhat.com/show_bug.cgi?id=512958

affects: gnome-power-manager (Fedora) → linux (Fedora)
Revision history for this message
David Tombs (dgtombs) wrote :

Hmm, but Lucid has 2.6.32 and Jan Pinkas confirmed the issue there. Perhaps someone could try a mainline kernel build of 2.6.32?

Revision history for this message
Ewox (aniss) wrote :

I just installed some updates to Lucid and now it detects lid close :D
Now we just have to wait for lid open... :)

/Aniss

Revision history for this message
Ewox (aniss) wrote :

Never mind. It was working until I rebooted.
Its still not working.

I'm not sure if its a help but when I "accidently" got it working I where playing around with Gnome-shell.

Revision history for this message
Jan Pinkas (jan-pinkas) wrote :

I don't know why, but at 9.10 works LID close good. At 9.04 not. 10.4 is bad now.

Revision history for this message
Stanisław Chmiela (schmiela-deactivatedaccount) wrote :

I don't know why, but at 9.10 it doesn't work. For me.

Revision history for this message
hfzorman (hfzorman) wrote :

This bug is affecting me too. As Jan Pinkas say in Ubuntu 9.10 the lid close/open recognition was working perfectly. Now in Ubuntu 10.04 it doesn't work. It neither works in KDE and I wonder why because KDE has another power-daemon.

Revision history for this message
Johannes Knaus (johannesknaus) wrote :

I can confirm Jan Pinkas and hforzman.
Under 9.04 lid close detection didn't work.
Under 9.10 it worked perfectly.
Under 10.04 again, it doesn't work.

N.B. I did a clean install with each new Ubuntu version (formatting root partition, keeping /home partition). This may have an effect, as some people using 9.10 report that lid close detection doesn't work on the HP mini 2140. On my 2140 it worked with 9.10. However 10.04 seems to have broken it again.

Revision history for this message
Hendrik Borghorst (djselbeck) wrote :

I can confirm this behavior on a HP Mini 5101 as well.

Revision history for this message
hfzorman (hfzorman) wrote :

I have reported this bug to GNOME Bugzilla. I'm almost sure it was already reported, but just in case. It's getting pretty annoying...

Revision history for this message
Gyorgyi Toth (tgyorgyi27) wrote :

For me lid close detection worked in 9.10 for Suspend, but did not work when I just wanted screen light to be turned off (it stayed on). No difference whether plugged or unplugged.

Now, after an upgrade (not new install) to 10.04, it stopped working on my hp mini 2140 entirely.

Revision history for this message
Stanisław Chmiela (schmiela-deactivatedaccount) wrote :

I have Lucid. After hibernation the lid detection started to seem to work. While closing, the display turned off for 1 second. Than it became normal. While closing slowly the same.

Revision history for this message
MatthewS (matthew-sill) wrote :

Same as Gyorgyi, HP 2140, suspend worked perfectly in 9.10 when the lid closed, does not work after upgrading (in place) to 10.04.

Revision history for this message
Diego D (delillod) wrote :

Same problem as MatthewS, I have an HP530, it worked fine with 9.10, but when upgraded to 10.04 it did not work any more.
But now, If I hibernate my laptop, when it wakes up, lid button starts working OK, I mean, the event is recognized and screen turns off. Someone says, It could be a problem related to video driver, where can I find the xorg.conf or where can I check what's the video driver in use on my laptop ?
Thanks all !.

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

It would be helpful if someone could test using a mainline kernel build. See instructions at <https://wiki.ubuntu.com/KernelTeam/MainlineBuilds>. Thanks!

Changed in gnome-power-manager (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Aaron Marburg (aaron-marburg) wrote :

I have an HP Mini 5101 running xubuntu which I dist-upgraded from 9.10 to 10.04. I had the same problems described above (suspend on lid-close worked in 9.10 but stopped working after upgrade) with xfc4-power-manger. Under the "current" 10.04 kernel, as described above, /proc/acpi/button/lib/C1D0/state did correctly reflect open/close but the unit was not suspending.

I've just installed 2.6.34-020634-generic from the Ubuntu mainline kernel site and behaves correctly (close lid -> suspend). I use the power button to wake, so I can't comment on any actions on lid opening.

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

Thank you very much for testing that, Aaron. Unfortunately since your test case differs in two ways from this report (Mini 5101, XFCE), it can't confirm that /this/ specific bug is fixed.

If anyone running vanilla Ubuntu with a Mini 2140 could please test the current mainline build, it will help in getting this bug fixed. (It may sound daunting, but it's not hard.) Thanks!

Revision history for this message
Stanisław Chmiela (schmiela-deactivatedaccount) wrote :

I've tested mainline build on Mini 2140. Especially for you. ;)

On 2.6.34-999 (daily) the lid recognition works. Especially for everything except screen blanking. Computer suspends, when you close the lid, but if the setting is set to blank the screen, it's not working perfectly. The screen blanks for 2-3 seconds, then it lights on. But suspend works.

P.S.: With booting mainline build, I crashed WiFi. Now I can't fix it. :/

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

Great, Stanley, thanks for checking that out! This confirms that the bug is either 1) in the Ubuntu kernel patches, or 2) has been fixed between the current Lucid kernel and the trunk. To tell between these two, could you test using the mainline build from the current Lucid one? You can use the map at <http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html>, and it's probably 2.6.32.11. Thanks in advance, it's nice to see people that are willing to take effort to get a bug fixed.

Revision history for this message
Stanisław Chmiela (schmiela-deactivatedaccount) wrote :

On 2.6.32-02063214 (which is unfortunately 2.6.32.14; 2.6.32.11 doesn't have linux-headers(...)_all.deb which is dependency) lid close detection works exactly as in 2.6.34-999.

In my opinion the bug is in the Ubuntu kernel patches. If you know where to find all packages for 2.6.32.11, tell me, I will install them and test (only tomorrow afternoon). Then we'll get 100% certainty.

P.S.: In 2.6.32.14 suspending doesn't work. ;)

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

Thanks for the testing again, Stanley. Can't you just run 2.6.32.11 without the headers? You should only need them for extra kernel modules like proprietary drivers.

Revision history for this message
Stanisław Chmiela (schmiela-deactivatedaccount) wrote :

Run 2.6.32.11. Lid detection works as in 2.6.34-999 and 2.6.32.14.

So, the bug is in Ubuntu kernel patches. ;)

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

Great, thank you for taking care of that, Stanley. Reassigning to linux. I'll post about this on the upstream g-p-m bug, too.

affects: gnome-power-manager (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in gnome-power:
status: Unknown → In Progress
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
hivar (hihivar) wrote :

Still an issue after latest update in UNE(10.04), kernel 2.6.32-22, on HP mini 5101.

Revision history for this message
Jeremy Nickurak (nickurak) wrote : Re: [Bug 376793] Re: HP 2140 Lid Close Not Detected

Also still an issue on my 2140 under stock lucid.

On Fri, Jun 11, 2010 at 02:13, hivar <email address hidden> wrote:
> Still an issue after latest update in UNE(10.04), kernel 2.6.32-22, on
> HP mini 5101.
>
> --
> HP 2140 Lid Close Not Detected
> https://bugs.launchpad.net/bugs/376793
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Jeremy Nickurak -= Email/XMPP: <email address hidden> =-

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

@hivar: This but is about the 2140, you need to open a new bug (or find a duplicate) for your 5101. Thanks.

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

hivar,
    per the Ubuntu Kernel Team's new bug policies, I prefer you open a new bug for any issue you feel you are affected by. This enables us to approach the bugs from the perspective of hardware interference and then move forward with our triage.

Thanks!

~JFo

tags: added: kernel-needs-review kernel-power
Revision history for this message
cosmix (cosm7x) wrote :

This bug perists as of Maverick Alpha 3 on the HP Mini 2140 (2.6.35-15)

Changed in gnome-power:
importance: Unknown → Medium
Revision history for this message
Gyorgyi Toth (tgyorgyi27) wrote :

Still present on the HP Mini 2140 in Maverick Beta (2.6.35-20).

Revision history for this message
Gabriel Lindeborg (gabriel-lindeborg) wrote :

Over @ Fedora/RedHat (https://bugzilla.redhat.com/show_bug.cgi?id=512958) they have a workaround that works for me.

Put this

echo 1 > /proc/acpi/video/C088/DOS
echo 0 > /proc/acpi/video/C088/DOS

in a startup script and all seems to work all rightie!

Revision history for this message
João Gomes (jvpgomes) wrote :

This also causes another problem: the display doesn't go to sleep automatically after a certain idle time.

The following appears in the output when I run gnome-power-manager with verbose mode:
"lid is closed, so we are ignoring ->NORMAL state changes"

It assumes that the lid is closed and, because of that, it ignores any change of the display mode.

It works well until the lid is closed for the first time.
After that, it always assumes that the lid is closed.

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Hah. yeah, that would explain why I've lost a lot of battery life...

2010/10/19 João Gomes <email address hidden>

> This also causes another problem: the display doesn't go to sleep
> automatically after a certain idle time.
>
> The following appears in the output when I run gnome-power-manager with
> verbose mode:
> "lid is closed, so we are ignoring ->NORMAL state changes"
>
> It assumes that the lid is closed and, because of that, it ignores any
> change of the display mode.
>
> It works well until the lid is closed for the first time.
> After that, it always assumes that the lid is closed.
>
> --
> HP 2140 Lid Close Not Detected
> https://bugs.launchpad.net/bugs/376793
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Jeremy Nickurak -= Email/XMPP: -= <email address hidden> =-

Revision history for this message
Gabriel Lindeborg (gabriel-lindeborg) wrote :

Strange, because it worked for me in 10.04 and works for me in 10.10 on my Mini 2140. Is HIBERNATE_MODE set to platform in your /etc/default/acpi-support?

Revision history for this message
João Gomes (jvpgomes) wrote :

sorry, I explained it wrong.

I didn't meant to say that the workaround creates a new problem.
What I wanted to say is that what causes this problem also prevents the monitor from going to sleep.
Both problems seems to have the same cause.

By the way, I cannot apply the workaround.
It says "permission denied", even if I use sudo.

$ sudo echo 1 > /proc/acpi/video/GFX0/DOS
bash: /proc/acpi/video/GFX0/DOS: Permission denied
$ sudo echo 0 > /proc/acpi/video/GFX0/DOS
bash: /proc/acpi/video/GFX0/DOS: Permission denied

I also noticed another thing.
If I do the following (as explained in https://bugzilla.redhat.com/show_bug.cgi?id=512958) it recognizes correctly if the lid is closed or open.

$ cat /proc/acpi/button/lid/LID/state
state: closed
$ cat /proc/acpi/button/lid/LID/state
state: open

But the output of the gnome-power-manager in verbose mode (and with the lid open) says that the lid is closed:

TI:12:09:52 TH:0x8a7e8b8 FI:gpm-idle.c FN:gpm_idle_set_mode,108
 - Doing a state transition: normal
TI:12:09:52 TH:0x8a7e8b8 FI:gpm-manager.c FN:gpm_manager_idle_changed_cb,804
 - lid is closed, so we are ignoring ->NORMAL state changes
TI:12:09:52 TH:0x8a7e8b8 FI:gpm-idle.c FN:gpm_idle_evaluate,192
 - X not idle

Revision history for this message
João Gomes (jvpgomes) wrote :

The workaround seems to work only in 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)

Revision history for this message
Gabriel Lindeborg (gabriel-lindeborg) wrote :

I have never had a problem with either screen going to sleep or netbook hibernating on lid closure since I implemented the workaround on my 2140.

I put echo 1 > /proc/acpi/video/C088/DOS and echo 0 > /proc/acpi/video/C088/DOS in /etc/rc.local and as this is run as root there is no problem. I think the reason for not being able to do it with sudo is a configuration thing with the sudo command but haven't had the time/will to check that. If one does a sudo su the command runs as it ought to.

Also check that HIBERNATE_MODE=platform and SUSPEND_METHODS="pm-utils" in /etc/default/acpi-support.

Revision history for this message
João Gomes (jvpgomes) wrote :

Yes, I used
sudo sh -c 'echo 1 > /proc/acpi/video/GFX0/DOS' and sudo sh -c 'echo 0 > /proc/acpi/video/GFX0/DOS'

But, it is not the same case.

For instance, when I do the following, it recognizes correctly if the lid is closed or open.

(with the lid closed)
$ cat /proc/acpi/button/lid/LID/state
state: closed

(with the lid open)
$ cat /proc/acpi/button/lid/LID/state
state: open

However, when the lid is open, the gnome-power-manager stills shows:
"lid is closed, so we are ignoring ->NORMAL state changes"
Because of that, it does not put the display to sleep.
And when I boot, it works properly. This only happens after I close the lid for the first time.
Killing gnome-power-manager and starting it again does not solve the problem.
Only after logging out and logging in or rebooting, it works again.

In fact, also in https://bugzilla.redhat.com/show_bug.cgi?id=512958
the report creator said at the beginning:
"/proc/acpi/button/lid/C1C4/state is changing correctly from open to close and vice versa."

In /etc/default/acpi-support I have:
HIBERNATE_MODE=shutdown
and
SUSPEND_METHODS="dbus-pm dbus-hal pm-utils"
Though, my problem is not the hibernate or suspend modes, which work well.
The problem is that gnome-power-manager recognizes the lid as closed when it is open.
Do you think it might be related?

Thank you for your help!

Changed in gnome-power:
status: In Progress → Expired
Revision history for this message
penalvch (penalvch) wrote :

Jeremy Nickurak, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Changed in linux (Fedora):
importance: Unknown → Medium
status: Unknown → Won't Fix
Revision history for this message
penalvch (penalvch) wrote :

OR using EOL release, no debug logs, and no response since 2013.

no longer affects: linux (Ubuntu)
affects: linux (Fedora) → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Medium → Undecided
status: Won't Fix → New
no longer affects: linux (Ubuntu)
affects: gnome-power → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Medium → Undecided
status: Expired → New
status: New → Invalid
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.