Logout screen appears twice [Feisty]

[Vassilis Pandis]

Binary package hint: gnome-power-manager

On current feisty: System->Control Centre > Power Management > General > When power button is pressed > Ask me . Now press the power button. Logout menu appears. Hit spacebar/click to "cancel", it appears again. Ok, it's a minor issue, but still it would be nice if somebody fixed it. Thanks!

[Eddie Hung (eddieh)]

I can confirm this, using the latest feisty gpm dated: 14/2/07.

Eddie

[Jonh Wendell (wendell)]

I guess this bug is not g-p-m's fault. Looking at /var/log/messages while pressed the power button, i see two entries like that (in portuguese):

Feb 14 16:27:15 wendell-laptop gnome-power-manager: (wendell) Sair interativo do GNOME porque o botão liga-desliga foi pressionado
Feb 14 16:27:15 wendell-laptop gnome-power-manager: (wendell) Sair interativo do GNOME porque o botão liga-desliga foi pressionado

Kernel (or another piece of software) is generating 2 key events for power button pressed. That's why g-p-m logout dialog appears twice.

I'm using (as i'm a feisty user) kernel version 2.6.20 as shipped in feisty.

[Vincenzo Ciancia (vincenzo-ml)]

This also happens to me, and this even happens when suspending to ram. Sometimes I suspend to ram and at resume I find the logout screen there again (and I see it close before suspension), other times it just suspends again right after resume - duplicate "power button" events should somewhat be discarded by acpid but I am not sure on how.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

I can confirm this behavior. I wanted to post a bug about this, but found it was already here.

I do hope it gets fixed or at least some work-around found for feisty. It does not install confidence about the quality even though its just minor nuisance. Because it _is_ something everyone should notice. I'm suprised I didn't find a dozen duplicates about this.

I guess all those nerds and tweakers like us, playing with beta-versions, don't turn off their computers often.

[Jonh Wendell (wendell)]

Ralf, "all those nerds and tweakers like us", when wish fill a bug, they search for an already filled bug, exactly like you did. This can be one reason for "I didn't find a dozen duplicates about this."

[williamts99 (williamts99)]

Which is exactly the same reason that I didn't file a bug about it. :-)

[Oliver Grawert (ogra)]

apparently hal gets two events from different sources for the powerbutton:

[watch_device_condition_cb] gpm-hal.c:574 (10:42:25): emitting device-condition : /org/freedesktop/Hal/devices/computer_logicaldev_input, ButtonPressed (power)
[watch_device_condition_cb] gpm-hal.c:574 (10:42:25): emitting device-condition : /org/freedesktop/Hal/devices/acpi_PWRF, ButtonPressed (power)

moving that bug to hal ...

[Guido Conaldi (guido-conaldi)]

I have the same problem using Fiesty Herd 5 on a sony vaio vgn-S1XP.
It could be interesting to note that, at least in the case of vaio laptops, there is a general regress in all the functions related to hot-keys (I guess the power button is also monitored by sonypi).

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

I just wanted to mention that this does *not* happen for me (HP nx6125), so it's not a universal bug. Limited to Vaio laptops, maybe?

[Stéphane Graber (stgraber)]

Same issue on a Toshiba A100-193

[Eddie Hung (eddieh)]

Oops, forgot to mention that I get this issue with a Compaq n410c, in reply to the issue-only-affects-VAIOs comment above.

Eddie

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

I have a Medion PC with an AMD64 here. (a supermarket pc)
Same issue. It may not be universal, but its seems its very common.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

Interestingly, when I use the power-off key on my keyboard (which sends the exact same keycode I think) it does not show up twice.

My guess is there are two keycodes that will trigger a 'shutdown' and some computers are sending both. Linux is catching both and therefore giving two shut-down screens.

Its just a wild guess, but its the only explanation I could come up with, that takes into account that it always happens twice (never three times, never once) and that keyboards do not trigger the same effect.

Any one else have any speculation as what-is-causing this?
It is a regression b-t-w, shouldn't that be in the bug summery?

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Actually, it'd help if I read the bug more carefully. It *does* happen for me too.

Sorry for the noise!

[Étienne BERSAC (bersace)]

Confirmed on MacBook. No dialog should pops while one is poping. I don't understand how multiple popups can be instanciated.

Regards,
Étienne.

[Peter Whittaker (pwwnow)]

Ralf, we should be able to detect the behavior you posit in comment#13. Could you try this test and report back, please?

    Open a terminal window

    Run lshal -m

    Press the keyboard power off key

The command "lshal -m" monitors for important events and device property changes - the keycode event generated by pressing the poweroff button should appear there.

If there are two events generated, both should be there....

(To capture the output of lshal, you may need to copy and paste from the terminal, or run it within "script" piping to a file or another process does not seem to work, at least not for me - contact me directly if you need assistance with script....)

[anubhavrakshit (anubhavrocks)]

On pressing power button this is the output

anubhav@anubhav-desktop:~ > lshal -m

Start monitoring devicelist:
-------------------------------------------------
acpi_PWRF condition ButtonPressed = power
computer_logicaldev_input_0 condition ButtonPressed = power

On 3/13/07, Peter Whittaker <email address hidden> wrote:
> Ralf, we should be able to detect the behavior you posit in comment#13.
> Could you try this test and report back, please?
>
> Open a terminal window
>
> Run lshal -m
>
> Press the keyboard power off key
>
> The command "lshal -m" monitors for important events and device property
> changes - the keycode event generated by pressing the poweroff button
> should appear there.
>
> If there are two events generated, both should be there....
>
> (To capture the output of lshal, you may need to copy and paste from the
> terminal, or run it within "script" piping to a file or another process
> does not seem to work, at least not for me - contact me directly if you
> need assistance with script....)
>
> --
> Logout screen appears twice [Feisty]
> https://launchpad.net/bugs/81227
>

--
Anubhav Rakshit

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

Same here:

ralf@Freezer:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
computer_logicaldev_input_0 condition ButtonPressed = power
acpi_PWRF condition ButtonPressed = power

[jens_acamedia (commercial-acamedia)]

on and off during feisty over the last month my power button has been shutting the laptop (acer 1644) directly without even asking me. some updates fix it and then it happens again. right now powerbutton causes direct shutdown - dont want to do it now but ill send output when can...

[jens_acamedia (commercial-acamedia)]

why does
"lshal -m > file"
not work while
"lshal -m > /dev/tty1"
works fine.
i cant capture it unless its piped to a file since my computer shuts down when i press powerbutton. help appreciated..thanks

[Peter Whittaker (pwwnow)]

On Wed, 2007-03-14 at 07:46 +0000, jens_acamedia wrote:
> why does
> "lshal -m > file"
> not work

I wondered this myself, and have no explanation. I suppose - and this is
a guess - the lshal dev chose to directly manipulate streams when lshal
is invoked with --monitor (-m) to prevent lshal itself from disturbing
the devices it is monitoring....

> i cant capture it unless its piped to a file since my computer
> shuts down when i press powerbutton. help appreciated..thanks

Try using script:

$ script halout
$ lshal -m

Then, whatever happens, halout should contain what you are looking for
(probably best not to write the script file - halout - to /tmp, it could
cleaned away reboot). For best results, you might try

script -f -c "lshal -m" halout

That puts the whole thing on one line, and the -f option ensures that
output is flushed to disk as it is produced.

[Elliot Hughes (elliot-hughes)]

As this is a confirmed bug in hal, and could not have been caused by ACPI (as far as I know) I am rejecting this bug. Thanks for reporting it.

[Paul Sladen (sladen)]

Note that:

  /etc/acpi/powerbtn.sh

will do a direct "shutdown -h" if it does not find a policy manager (gnome-power-manager/kpowersave) already running.

Is 'hal' generating a 'power' keypress based on the ACPI event and then an ACPI event based on the keypress.

[Paul Sladen (sladen)]

Just tested here locally, using the method in the first comment; I get the following messages:

  computer_logicaldev_input_1 condition ButtonPressed = power
  acpi_PWRF condition ButtonPressed = power

but only one log-out dialogue. If I click '[Cancel]' then I do not get a second dialogue.

[Oliver Grawert (ogra)]

a gpm package with a workaround was uploaded (2.18.2-0ubuntu2) but is waiting for the release candidate archive freeze to end before it gets accepted for build. it should be ready soon after RC is out.

[Oliver Grawert (ogra)]

i just got told that the proper hal fix is in 0.5.9 (which we dont have in feisty yet), the link shall be: http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=f30d5efd1458cc43ec90563ea4028a26fdef7689

[Guido Conaldi (guido-conaldi)]

I have just installed gdm 2.18.2-0ubuntu2 on my vaio s1xp, but the logout menu still appears twice.

[Oliver Grawert (ogra)]

even after logging out/in or restarting ? note that after an uipgrade the old binary still runs in memory

[Guido Conaldi (guido-conaldi)]

yes, Oliver. I restarted before trying. I'm using Feisty 32bit up-to-date.

[Eddie Hung (eddieh)]

Bug has been fixed on my Compaq n410c in the latest round of updates, which included the 2.18.2-0ubuntu2 gpm update. Good work people!

[Jonh Wendell (wendell)]

Like Guido commented above, this is still an issue for me. This upload didn't solve the problem :(

[Oliver Grawert (ogra)]

can everybody who still sees it attach the output of lshal -m while pressing the power button ?
currently g-p-m is set to ignore all events from and uid=/org/freedesktop/Hal/devices/acpi_PWRF and only accept the ones from input devices.

[Guido Conaldi (guido-conaldi)]

Here is my lshal.

[Jonh Wendell (wendell)]

wendell@wendell-laptop:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
computer_logicaldev_input_1 condition ButtonPressed = power
acpi_PBTN condition ButtonPressed = power

[Ante Karamatić (ivoks)]

U Čet, 12. 04. 2007., u 12:01 +0000, Oliver Grawert je napisao/la:

> can everybody who still sees it attach the output of lshal -m while
> pressing the power button ? currently g-p-m is set to ignore all
> events from and uid=/org/freedesktop/Hal/devices/acpi_PWRF and only
> accept the ones from input devices.

computer_logicaldev_input_1 condition ButtonPressed = power
acpi_PWRF condition ButtonPressed = power

Could this new g-p-m could be the reason Fn+F3 doesn't work, and syslog
says:

gnome-power-manager: (ivoks) Doing nothing because the suspend button
has been pressed

This worked couple of days ago...

[Eddie Hung (eddieh)]

Ah-ha! Well my Compaq n410c produces the expected result:

Start monitoring devicelist:
-------------------------------------------------
computer_logicaldev_input_0 condition ButtonPressed = power
acpi_PWRF condition ButtonPressed = power

Which is why it works for me...

[Oliver Grawert (ogra)]

ivoks: no, thats not related ...
+ if (strcmp (type, GPM_BUTTON_POWER) == 0 && \
+ strcmp (udi, "/org/freedesktop/Hal/devices/acpi_PWRF") == 0) {
+ gpm_debug ("ignoring acpi event in favor of inputdevice event");
+ return;
+ }
+

as you can see in the fix above the message is a different one ...

seems i should cut he paternmatching after the underscore to match all acpi_**** devices ... :/

[Ante Karamatić (ivoks)]

U Čet, 12. 04. 2007., u 12:19 +0000, Ante Karamatić je napisao/la:

> acpi_PWRF condition ButtonPressed = power

I forgot to mention that it works as expected for me too. Sorry.

[Oliver Grawert (ogra)]

the final fix will be in hal 0.5.9 in feisty+1 closing with workaround in g-p-m

 gnome-power-manager (2.18.2-0ubuntu3) feisty; urgency=low
 .
   * fix #81227 harder by matching all acpi power buttons instead of only
     these which have an udi with acpi_PWRF