After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 341992 - Sound key bindings are ignored; keybindings applet chooses different names for the keys depending on phase of the moon
Sound key bindings are ignored; keybindings applet chooses different names fo...
Status: RESOLVED DUPLICATE of bug 133815
Product: gnome-control-center
Classification: Core
Component: [obsolete] Keybinding
2.12.x
Other All
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-16 15:47 UTC by Sam Morris
Modified: 2006-08-08 08:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Description Sam Morris 2006-05-16 15:47:17 UTC 
Please describe the problem:
I bound my keyboard's multimedia keys to perform actions such as play, next
track, stop and so on. Some of the keys show up with names like 0xa3, 0xa2 and
ax90. Other keys are comletly ignored and can not be bound. Ssuch keys are not
even visible to xev.

Even the keys that do get bound with the strange names are ignored. This is true
for all the actions in the 'sound' section except for volume mute/up/down.

Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
$ gconftool -R /apps/gnome_settings_daemon/keybindings
 home = <Mod4>h
 eject = disabled
 screensaver = <Mod4>l
 music = disabled
 volume_down = 0xae
 play = 0xa2
 pause =
 sleep = disabled
 brightness_down =
 power = disabled
 calculator = disabled
 www = 0xa0
 volume_up = 0xb0
 next = 0x99
 brightness_up =
 volume_mute = disabled
 stop = 0xa4
 previous = 0x90
 help = disabled
 email = <Mod4>e
 search = <Mod4>f
Comment 1 Sergej Kotliar 2006-05-22 19:00:41 UTC 
Could this be a dupe of bug 125618?
Comment 2 Sam Morris 2006-06-04 23:40:18 UTC 
I upgraded to 2.14 and the buttons still don't work. However the keybinding applet now works *really* oddly. The first time I assign my play/pause button to the play/pause action, it shows up as 0xa2. If I immediatly assign the same key to this function, it shows up as XF86AudioPlay. The next time I do it, it goes back to 0xa2, and so on.

The same thing happens for the Pause action (cycles between 0xa2, XF86AudioPlay and XF86AudioPause), the Stop action (0xa4, XF86AudioStop), skip to previous, skip to next, etc...
Comment 3 Ernst Rohlicek 2006-07-03 18:38:19 UTC 
(In reply to comment #2)

I also upgraded to 2.14.2 recently. The keybindings-applet switches between 0x?? and its XF86Audio* version, though only the hex version is accepted by totem and rhythmbox. So this "works" for me (Logitech Deluxe Access Keyboard), but it doesn't seem to be cleanly implemented. Why those two versions anyway? Historic reasons?

--Ernst
Comment 4 Bastien Nocera 2006-08-08 08:25:16 UTC 
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 133815 ***