When did you do your installation?  And what keyboard type did you select?

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.

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?

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.

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?

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?

Yeah, that looks pretty likely (and whoops, didn't see the comment until after
Bastien and I spent time poking at it) 

Created attachment 264301 [details]
here is a patch that fixes this bug

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.

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.

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

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

FYI, a related bug:
https://bugs.freedesktop.org/show_bug.cgi?id=15741

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

Created attachment 303970 [details]
gsd-handle-keysyms.patch

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

Matthias, how can we get the correct "keyboard group" to pass to
gdk_keymap_translate_keyboard_state() ?

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);

(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).

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,
                                       event->key.hardware_keycode,
                                       event->key.state,
                                       event->key.group,
                                       &event->key.keyval,
                                       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);
    }
  else
#endif

Done upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=530356

gnome-settings-daemon-2.22.1-1.2008.03.26.7.fc9 has been submitted as an update for Fedora 9

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Confirming that this bug has been fixed in
gnome-settings-daemon-2.22.1-1.2008.03.26.8.fc9

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.