Description of problem: setxkbdmap with -option -option apple:badmap doesn't work Version-Release number of selected component (if applicable): How reproducible: issue the command setxkbdmap with -option -option apple:badmap doesn't work Steps to Reproduce: 1. 2. 3. Actual results: The bad apple keyboard mapping isn't fixed (the '< , >' keycode is swaped with the '\ , |' keycode Typing the '<' symbol on the keyboard the '\' symbol is output on the screen Expected results: The key codes should be mapped correctly i.e. Typyng the '<' symbol on the keyboard should produce the '<' symbol. Additional info:
Please attach the output of xkbcomp -xkb :0 -. Please attach the output of xev after hitting the keys that are mapped incorrectly.
Created attachment 327317 [details] Output of the xev tool after hitting the mentioned keys
Created attachment 327318 [details] Output of the xkbcomp tool
I've fiddled a bit more with the apple keyboard and have discovered another probably incorrect mapping. I say "probably" because i'm not sure this misfunction is related to the keyboard mapping. Well: all "special" keys (brightness up, volume up, volume down, volume mute, play/stop, next, prev and eject.) work perfectly in the Gnome environment. They display the relevant icon and perform what they're supposed to do, e.g. ejecting a cd. All but one: the "brightness down" key. All other keys work fine. But perhaps this is not a xkb-utils' bug, rather a gnome desktop's one. Thank you
check with lshal -m whether the brightness is recognised, all others probably are. Please download http://people.freedesktop.org/~whot/evtest.c, compile it with "gcc -o evtest evtest.c" and then run it as root with "./evtest /dev/input/eventX" where X is the number for the device. You can get the number by looking at /proc/bus/input/devices. Hit the keys, then attach the output of evtest here. We need to figure out where the keycodes go wrong.
Created attachment 327857 [details] output of the evtest c program The device tested is number six. The system reoprts also a device numer 7 as "apple inc keyboard" but the test doesn't produce any output.
The "brightness down" seems to be recognized (see attachment: evtest_output_device6) properly. When i press the "brightness down" button, i get the correct output from evtest. It seems to be something related to the gnome environment. Furthermore, i experience such problems after a full (and clean) upgrade from Fedora 9 to Fedora 10. The "-option -option apple:badmap" parameter for setxkbmap worked fine. and so did the brightness up/down buttons. The upgrade from F9 to F10 was undoubtedly clean since i reformatted all partitions before installing F10. More than a bad mapping, which is a known issue with the apple keyboard, it seems to be a problem with the switch of the setxkbmap command. Marry Christmas to all
badmap has been dropped from upstream xkeyboard-config. See also: http://bugs.freedesktop.org/show_bug.cgi?id=9095 If this is an issue with current F10, please reopen the bug and supply the required information to the xkeyboard-config maintainer upstream. Some more information I need though: The keys that are mixed up (ignoring brightness for now), which keycode do they have in evtest, and which keycodes do they have in xev? I'm not sure in which order you pressed them in the log files you provided.
Thank you for the hint. Well, i confirm. This is an issue with F10 (in F9 things used to work). I don't know if this is a F10 specific issue or a mere kernel issue since i've not installed other distributions on my machine. Anyway, my 'uname -r' output is: 2.6.27.9-159.fc10.x86_64 The xev output for the '<' and '>' keys (as marked *on the keyboard*, not as shown on screen) is, in the order: KeyPress event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1194374, (-168,-13), root:(1086,12), state 0x0, keycode 49 (keysym 0x5c, backslash), same_screen YES, XLookupString gives 1 bytes: (5c) "\" XmbLookupString gives 1 bytes: (5c) "\" XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1194422, (-168,-13), root:(1086,12), state 0x0, keycode 49 (keysym 0x5c, backslash), same_screen YES, XLookupString gives 1 bytes: (5c) "\" XFilterEvent returns: False ... and ... KeyPress event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1354415, (-583,-17), root:(671,8), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1354551, (-583,-17), root:(671,8), state 0x1, keycode 49 (keysym 0x7c, bar), same_screen YES, XLookupString gives 1 bytes: (7c) "|" XmbLookupString gives 1 bytes: (7c) "|" XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1354623, (-583,-17), root:(671,8), state 0x1, keycode 49 (keysym 0x7c, bar), same_screen YES, XLookupString gives 1 bytes: (7c) "|" XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1354711, (-583,-17), root:(671,8), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ... while the xev output for the '\' and '|' keys (again, as marked *on the keyboard*, *not* as shown on screen) is, in the order: KeyPress event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1594962, (253,320), root:(1507,345), state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES, XLookupString gives 1 bytes: (3c) "<" XmbLookupString gives 1 bytes: (3c) "<" XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1595034, (253,320), root:(1507,345), state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES, XLookupString gives 1 bytes: (3c) "<" XFilterEvent returns: False ... and ... KeyPress event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1634066, (301,256), root:(1555,281), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1634202, (301,256), root:(1555,281), state 0x1, keycode 94 (keysym 0x3e, greater), same_screen YES, XLookupString gives 1 bytes: (3e) ">" XmbLookupString gives 1 bytes: (3e) ">" XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1634266, (301,256), root:(1555,281), state 0x1, keycode 94 (keysym 0x3e, greater), same_screen YES, XLookupString gives 1 bytes: (3e) ">" XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x3e00001, root 0x8b, subw 0x0, time 1634370, (301,256), root:(1555,281), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False The evtest output is (listing is shown for key pressed in the same order as for xev): Event: time 1231233241.885524, type 1 (Key), code 41 (Grave), value 1 Event: time 1231233241.885539, -------------- Report Sync ------------ \Event: time 1231233241.989521, type 1 (Key), code 41 (Grave), value 0 Event: time 1231233241.989536, -------------- Report Sync ------------ ... for the '<' mark on the keyboard, Event: time 1231233450.087606, type 4 (Misc), code 4 (ScanCode), value 700e1 Event: time 1231233450.087624, type 1 (Key), code 42 (LeftShift), value 1 Event: time 1231233450.087633, -------------- Report Sync ------------ Event: time 1231233450.223617, type 1 (Key), code 41 (Grave), value 1 Event: time 1231233450.223633, -------------- Report Sync ------------ |Event: time 1231233450.295616, type 1 (Key), code 41 (Grave), value 0 Event: time 1231233450.295632, -------------- Report Sync ------------ Event: time 1231233450.399616, type 4 (Misc), code 4 (ScanCode), value 700e1 Event: time 1231233450.399632, type 1 (Key), code 42 (LeftShift), value 0 Event: time 1231233450.399641, -------------- Report Sync ------------ ... for the '>' on the keyboard, Event: time 1231233525.936371, type 1 (Key), code 86 (102nd), value 1 Event: time 1231233525.936386, -------------- Report Sync ------------ <Event: time 1231233526.000373, type 1 (Key), code 86 (102nd), value 0 Event: time 1231233526.000390, -------------- Report Sync ------------ ... for the '\' on the keyboard and ... Event: time 1231233600.817104, type 4 (Misc), code 4 (ScanCode), value 700e1 Event: time 1231233600.817122, type 1 (Key), code 42 (LeftShift), value 1 Event: time 1231233600.817130, -------------- Report Sync ------------ Event: time 1231233600.921113, type 1 (Key), code 86 (102nd), value 1 Event: time 1231233600.921130, -------------- Report Sync ------------ >Event: time 1231233600.985110, type 1 (Key), code 86 (102nd), value 0 Event: time 1231233600.985120, -------------- Report Sync ------------ Event: time 1231233601.065088, type 4 (Misc), code 4 (ScanCode), value 700e1 Event: time 1231233601.065100, type 1 (Key), code 42 (LeftShift), value 0 Event: time 1231233601.065105, -------------- Report Sync ------------ ... for the '|' on the keyboard. Thank you P.S. As suggested, I reopened the bug in freedesktop bugzilla.
Reassigning to kernel - upstream maintainer of xkeyboard-config thinks that this needs to be fixed in the kernel, not hacked around in xk-c. FWIW, I agree.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Sorry for replying this late, but it seems that the kernel fix was never upstreamed. Does someone know if it was only part of some Fedora kernels and could point us to the bug or commit fixing it? Cheers, -- Yves-Alexis