Bug 346201 - AudioStop button sends "Eject" signal on ThinkPad X61 in Gnome
Summary: AudioStop button sends "Eject" signal on ThinkPad X61 in Gnome
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-23 02:28 UTC by petrosyan
Modified: 2013-01-10 04:28 UTC (History)
4 users (show)

Fixed In Version: gnome-settings-daemon-2.22.1-1.2008.03.26.8.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-21 14:51:18 UTC

Attachments (Terms of Use)
here is a patch that fixes this bug (507 bytes, patch)
2007-11-20 03:24 UTC, petrosyan
no flags Details | Diff
gsd-handle-keysyms.patch (1019 bytes, patch)
2008-04-28 13:23 UTC, Bastien Nocera
no flags Details | Diff

System ID Priority Status Summary Last Updated
GNOME Bugzilla 530356 None None None Never

Description petrosyan 2007-10-23 02:28:49 UTC
Description of problem:
Play/pause             0xa2
Stop playback          0xa4
Skip to previous track 0x90
Skip to next track     0x99

keys should be bound by default in gnome keyboard shortcuts so that they work as
expected. These keys work by default in Ubuntu 7.10 but not in Fedora rawhide.

Version-Release number of selected component (if applicable):
Fedora rawhide 20071019

Additional info:
ThinkPad X61

Comment 1 Jeremy Katz 2007-10-23 03:59:15 UTC
When did you do your installation?  And what keyboard type did you select?

Comment 2 petrosyan 2007-10-23 04:12:32 UTC
I did not install it I simply booted from rawhide-20071019-x86_64 LiveCD so I
wasn't asked anything about the keyboard type. When booting from 64 bit Ubuntu
7.10 liveCD (without installing it) multimedia keys (play/pause, stop, prev,
next) work as expected in Rhythmbox.

Comment 3 Jeremy Katz 2007-10-23 15:22:17 UTC
This is doing the right thing here on an X60.

Can you look at /etc/X11/xorg.conf and ensure that XkbLayout is set to "us+inet" ?

Also, can you verify that in the gnome keyboard shortcuts that the keys mapped
are XF86AudioPlay, XF86AudioStop, etc?

Comment 4 petrosyan 2007-10-24 01:42:43 UTC
After reinstalling Fedora rawhide multimedia key are working now.

However pressing the stop button XF86AudioStop (Fn+up_arrow) is interpreted by
GNOME as an eject button. It shows an eject picture on the screen and does not
stop playing the music.

Comment 5 Jeremy Katz 2007-10-24 02:05:19 UTC
Looking at the schema file, XF86AudioStop should be bound to stop, not eject --
XF86AudioEject is bound to eject.  Are you sure that Fn+up_arrow is giving
XF86AudioStop and not XF86AudioEject?

Comment 6 petrosyan 2007-10-24 02:28:43 UTC
I quite sure that Fn+up_arrow is giving XF86AudioStop. I tried rebinding it
(press "Backspace" to delete it and then Fn+up_arrow) and got the same result,
namely XF86AudioStop.

Looking at /usr/share/X11/xkb/symbols/inet file I saw entries like this:
    key <I24>   {       [ XF86AudioStop, XF86Eject ] };

Could this be causing it?

Comment 7 Jeremy Katz 2007-10-24 14:02:35 UTC
Yeah, that looks pretty likely (and whoops, didn't see the comment until after
Bastien and I spent time poking at it) 

Comment 8 petrosyan 2007-11-20 03:24:08 UTC
Created attachment 264301 [details]
here is a patch that fixes this bug

Comment 9 petrosyan 2007-11-20 17:27:12 UTC
It looks like this is a GNOME bug and not xkeyboard-config bug.
Pressing Fn+up_arrow sends the correct XF86AudioStop keysym to gnome, however
gnome interprets it like an Eject.

Comment 10 petrosyan 2007-11-20 17:47:03 UTC
Here is what I found:

1. Login into clean Fedora 8 install with all default GNOME settings.
2. Pressing "Stop" button displays the eject icon, and "Stop" button does not work.
3. Disable "Eject" keybinding from gnome-keyboard-shortcuts.
4. Now pressing "Stop" button does not display the eject button, but "Stop"
still does not work. It does not stop the music.
5. Log out and log in again. Stop button now works as expected! It stops the
music. The eject keybinding is still disabled.

Comment 11 petrosyan 2008-03-13 05:25:06 UTC
running lshal -m and pressing the "Stop" button I get the following:

$ lshal -m

Start monitoring devicelist:
01:21:06.041: platform_i8042_i8042_KBD_port_logicaldev_input condition
ButtonPressed = stop-cd

However GNOME is still interpreting this button as "Eject".

Comment 12 Bastien Nocera 2008-04-25 18:37:50 UTC
Test case:
1. Disable the media-keys plugin
/apps/gnome_settings_daemon/plugins/media-keys/active false
2. Restart gnome-settings-daemon (a good ol' killall will do)
3. Bind F12 to that key:
xmodmap -e "keycode 96 = XF86AudioStop XF86Eject"
4. Run test-media-keys in the gnome-settings-daemon sources

I'm pretty certain this would happen on Ubuntu as well if they used the same
keymap (we don't have any patches against this part of the code, except changes
for the default values).

Comment 13 Bastien Nocera 2008-04-28 12:57:15 UTC
FYI, a related bug:

The problem in our case is with the "match key" function, which checks for the
keycode, and ignores the keysym (which we don't have just yet...)

Comment 14 Bastien Nocera 2008-04-28 13:23:05 UTC
Created attachment 303970 [details]

Patch against current gsd SVN trunk to try to match keysyms before matching on
just the keycode.

Comment 15 Bastien Nocera 2008-04-28 13:24:23 UTC
Matthias, how can we get the correct "keyboard group" to pass to
gdk_keymap_translate_keyboard_state() ?

Comment 16 Matthias Clasen 2008-04-28 14:00:06 UTC
From the event, I'd say. Here is what gtkmenu.c does:

  /* Figure out what modifiers went into determining the key symbol */
  gdk_keymap_translate_keyboard_state (gdk_keymap_get_for_display (display),
                                       event->hardware_keycode, event->state,
                                       NULL, NULL, NULL, &consumed_modifiers);

Comment 17 Bastien Nocera 2008-04-28 14:08:35 UTC
(In reply to comment #16)
> From the event, I'd say. Here is what gtkmenu.c does:
>   /* Figure out what modifiers went into determining the key symbol */
>   gdk_keymap_translate_keyboard_state (gdk_keymap_get_for_display (display),
>                                        event->hardware_keycode, event->state,
> event->group,
>                                        NULL, NULL, NULL, &consumed_modifiers);

The event in that snippet is a GdkEventKey, the one we have access to in
match_key() is the X key event (the GdkEvent isn't processed yet, as we're in a
filter function, and all the fields are empty).

Comment 18 Matthias Clasen 2008-04-28 14:25:24 UTC
In that case, you may be interested in learning what
gdkevents-x11.c:translate_key_event does:

  event->key.state = (GdkModifierType) xevent->xkey.state;
  event->key.group = _gdk_x11_get_group_for_state (display, xevent->xkey.state);
  event->key.hardware_keycode = xevent->xkey.keycode;

  event->key.keyval = GDK_VoidSymbol;

  gdk_keymap_translate_keyboard_state (keymap,
                                       NULL, NULL, NULL);

and, if you look at the not exported _gdk_x11_get_group_for_state,
you'll find:

#ifdef HAVE_XKB
  if (display_x11->use_xkb)
      return XkbGroupForCoreState (state);

Comment 19 Bastien Nocera 2008-04-28 16:02:44 UTC
Done upstream:

Comment 20 Fedora Update System 2008-04-29 14:41:50 UTC
gnome-settings-daemon-2.22.1-1.2008.03.26.7.fc9 has been submitted as an update for Fedora 9

Comment 21 Bug Zapper 2008-05-14 03:42:12 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 22 petrosyan 2008-05-21 14:51:18 UTC
Confirming that this bug has been fixed in

Comment 23 Fedora Update System 2008-05-29 02:34:12 UTC
gnome-settings-daemon-2.22.1-1.2008.03.26.7.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.