notification daemon shows two popups for fn-f3 event

This could also be a g-p-m or libnotify issue. Would you mind running "dbus-monitor --session" whilst you press Fn+F3 and then post the messages that you see?

Thanks Mario. The message is actually sent twice, so this is not a notification-daemon bug. I'll tentatively re-assign it to gnome-power-manager for now, but it could be g-p-m, libnotify, xorg or the kernel. Could you kill gnome-power-manager and run xev, to see if you are experiencing multiple events when you press the key combination?

Thanks

I've killed gnome-power-manager, and without it running, I only see a single keypress and single keyrelease event for XF86Battery in xev.

That should rule out the kernel and xorg.

Thanks. Could you kill gnome-power-manager again and then re-run it with "gnome-power-manager --verbose --no-daemon", and then post any output as you press the key combination?

Thanks

Attached is gpm output as asked. I tee'd all the output to this log, so it includes from when it started and one button press.

whoops, that was actually me, just on the wrong launchpad login :)

Confirmed - g-p-m is raising the same event twice through 2 separate code paths, it seems:

TI:14:31:40 TH:0x8b0b640 FI:gpm-button.c FN:gpm_button_filter_x_events,122
 - Key 244 mapped to HAL key battery
TI:14:31:40 TH:0x8b0b640 FI:gpm-manager.c FN:button_pressed_cb,1020
 - Button press event type=battery
TI:14:31:40 TH:0x8b0b640 FI:gpm-cell-array.c FN:gpm_cell_array_get_description,995
 - accuracy = 0
TI:14:31:40 TH:0x8b0b640 FI:gpm-engine.c FN:gpm_engine_get_summary,349
 - tooltip: Computer is running on AC power
Laptop battery charging (98.5%)
Battery charge time is estimated
TI:14:31:40 TH:0x8b0b640 FI:gpm-notify.c FN:gpm_notify_create,126
 - libnotify: Power Manager : Computer is running on AC power
Laptop battery charging (98.5%)
Battery charge time is estimated
TI:14:31:40 TH:0x8b0b640 FI:gpm-srv-screensaver.c FN:button_pressed_cb,167
 - Button press event type=battery
TI:14:31:40 TH:0x8b0b640 FI:gpm-backlight.c FN:gpm_backlight_button_pressed_cb,536
 - Button press event type=battery
TI:14:31:40 TH:0x8b0b640 FI:gpm-info.c FN:button_pressed_cb,679
 - Button press event type=battery
TI:14:31:40 TH:0x8b0b640 FI:gpm-button.c FN:hal_device_condition_cb,430
 - condition=ButtonPressed, details=battery
TI:14:31:40 TH:0x8b0b640 FI:gpm-button.c FN:emit_button_pressed,374
 - emitting button-pressed : battery
TI:14:31:40 TH:0x8b0b640 FI:gpm-manager.c FN:button_pressed_cb,1020
 - Button press event type=battery
TI:14:31:40 TH:0x8b0b640 FI:gpm-cell-array.c FN:gpm_cell_array_get_description,995
 - accuracy = 0
TI:14:31:40 TH:0x8b0b640 FI:gpm-engine.c FN:gpm_engine_get_summary,349
 - tooltip: Computer is running on AC power
Laptop battery charging (98.5%)
Battery charge time is estimated
TI:14:31:40 TH:0x8b0b640 FI:gpm-notify.c FN:gpm_notify_create,126
 - libnotify: Power Manager : Computer is running on AC power
Laptop battery charging (98.5%)
Battery charge time is estimated

I'll check if this is an upstream issue shortly, unless someone beats me to it.

I wonder if HAL is emitting a signal on this keypress (in addition to the keypress through the Xserver). Could you please run "dbus-monitor --system" as you press the key combination and then post the output?

Thanks

Here's the dbus-monitor --system log.

Thanks. Yeah, it seems that HAL emits a signal for that key as well, which is undesirable. Do you know if you get HAL signals for any other hotkeys, or is it just the battery key?

It does for FN-F10 for me, which is ejectcd-close. Probably a few others
too, but that's all i see offhand.

On Thu, Jan 8, 2009 at 11:31, Chris Coulson <email address hidden>wrote:

> Thanks. Yeah, it seems that HAL emits a signal for that key as well,
> which is undesirable. Do you know if you get HAL signals for any other
> hotkeys, or is it just the battery key?
>
> --
> notification daemon shows two popups for fn-f3 event
> https://bugs.launchpad.net/bugs/314547
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Mario Limonciello
<email address hidden>

It doesn't matter so much for Fn+F10 as that is handled by g-s-d, which I don't think looks at DBUS signals anyway (I might be wrong though). Could you also attach the output of "lshal" please?

This bug was fixed in the package gnome-power-manager - 2.24.0-0ubuntu13

---------------
gnome-power-manager (2.24.0-0ubuntu13) jaunty; urgency=low

  * Drop 79-enable-battery-hotkey.patch. It appears that HAL is now sending
    a dbus event for Battery hotkey presses, so gpm doesn't actually need to
    directly listen anymore. (LP: #314547)

 -- Mario Limonciello <email address hidden> Thu, 08 Jan 2009 12:40:10 -0600

Chris:

Thanks for helping to root cause this so quickly. It looks like this is a pretty easy issue to fix for this release, but future gnome power manager releases are going to have it, so i've filed a bug to see what upstream can do about it (maybe a compile time switch to ./configure to disable the functionality)

I just had a think about this, and if this really is just caused by HAL relaying a signal from the same /dev/input/eventX device that the X server already grabbed, then perhaps a slightly longer-term solution would be a hal-info rule to stop hald-addon-input from monitoring evdev devices (or any device with a 'input.x11_driver' property, if possible), which we know will be grabbed by Xorg anyway? The reason is that this problem could easily affect other hotkeys, eg brightness.

As an example, on my desktop the power button isn't grabbed by Xorg, and has no input.x11_driver property in HAL so I want HAL to relay signals from this device (which it does). But I don't want HAL to relay signals from any hotkeys on my keyboard, which have a input.x11_driver property.

What do you think? Could you think of any issues with doing something like that?

Chris:

I think there is a lot of confusion in this model to having HAL sending
these events, but it's the eventual correct solution that HAL should send
them and they shouldn't have a keysym in X assigned I think. Steve Langasek
and I had a short discussion about this on IRC.

The reason this model makes more sense is because then events that should be
broadcast to the system will be and events that should be broadcast to
specific user's sessions would be.

If there are a lot of other problems that crop up like this for Jaunty, I
think your hal-info solution will be a good idea, but either way this needs
to be revisited at the next UDS.

On Fri, Jan 9, 2009 at 10:49, Chris Coulson <email address hidden>wrote:

> I just had a think about this, and if this really is just caused by HAL
> relaying a signal from the same /dev/input/eventX device that the X
> server already grabbed, then perhaps a slightly longer-term solution
> would be a hal-info rule to stop hald-addon-input from monitoring evdev
> devices (or any device with a 'input.x11_driver' property, if possible),
> which we know will be grabbed by Xorg anyway? The reason is that this
> problem could easily affect other hotkeys, eg brightness.
>
> As an example, on my desktop the power button isn't grabbed by Xorg, and
> has no input.x11_driver property in HAL so I want HAL to relay signals
> from this device (which it does). But I don't want HAL to relay signals
> from any hotkeys on my keyboard, which have a input.x11_driver property.
>
> What do you think? Could you think of any issues with doing something
> like that?
>
> --
> notification daemon shows two popups for fn-f3 event
> https://bugs.launchpad.net/bugs/314547
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Mario Limonciello
<email address hidden>