notification daemon shows two popups for fn-f3 event

Bug #314547 reported by Mario Limonciello on 2009-01-06
4
Affects Status Importance Assigned to Milestone
gnome-power
Fix Released
Medium
gnome-power-manager (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: notification-daemon

I'm running a Jaunty daily from Jan 6.
notification-daemon 0.4.0-0ubuntu2.

Pressing fn-f3 normally pops up one popup of battery status. Pressing it showsing two popups. Pressing it again shows another two popups.

Mario Limonciello (superm1) wrote :
Chris Coulson (chrisccoulson) wrote :

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?

Changed in notification-daemon:
status: New → Incomplete
Mario Limonciello (superm1) wrote :
Chris Coulson (chrisccoulson) wrote :

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

Mario Limonciello (superm1) wrote :

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.

Changed in gnome-power-manager:
status: Incomplete → New
Chris Coulson (chrisccoulson) wrote :

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

Changed in gnome-power-manager:
status: New → Incomplete

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.

Mario Limonciello (superm1) wrote :

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

Changed in gnome-power-manager:
status: Incomplete → New
Chris Coulson (chrisccoulson) wrote :

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

Changed in gnome-power-manager:
importance: Undecided → Low
status: New → Confirmed
Chris Coulson (chrisccoulson) wrote :

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

Chris Coulson (chrisccoulson) wrote :

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

Changed in gnome-power-manager:
status: Confirmed → Incomplete
Mario Limonciello (superm1) wrote :

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

Chris Coulson (chrisccoulson) 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?

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>

Chris Coulson (chrisccoulson) wrote :

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?

Launchpad Janitor (janitor) wrote :

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

Changed in gnome-power-manager:
status: Incomplete → Fix Released
Mario Limonciello (superm1) wrote :

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)

Changed in gnome-power:
status: Unknown → New
Chris Coulson (chrisccoulson) 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?

Mario Limonciello (superm1) wrote :

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>

Changed in gnome-power:
importance: Unknown → Medium
Changed in gnome-power:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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