the built-in ISO USB keyboards on PowerBooks have <> and ^° swapped. Unfortunately, instead of fixing the kernel, a change was made to xkeyboard-config. Finally the kernel was fixed in 2.6.18.3 and 2.6.19. badmap/goodmap should be removed or disabled now. untested patch attached.
Created attachment 7841 [details] [review] badmap.patch
Good news; a better fix is to drop the $macbooks line from rules/base.m_k.part
So, do we decide it is time to drop supporting macbooks on earlier kernels? I think it is a bit too early...
Denis, since it is about 2 years, I am ready to drop that $macbooks line. No "badmap" "goodmap" any more.
Hi everibody. As suggested from Fedora people, i have to reopen the bug. I don't know how things work on macbooks but on my Alu iMac there are still two misdetected keys: the '\|' couple and the '<>' couple. Noticeably, things worked with Fedora 9 (with the 'badmap' option set) but now they don't with Fedora10. 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
Since previous bug was caused by the kernel (and we just provided workaround) - don't you think it would make sense to fix that issue at the kernel level as well? Did you talk to the kernel people?
Yes. You are perfectly right. The best should be to fix things up at kernel level. Actually i didn't speak to kernel people. Mr Hutterer (the package maintainer for Fedora xkbd-utils, i suppose) asked me some details about the exchanged keycodes (which i provided along with my comment also to you) while suggesting me to reopen this bug. I don't know if they're able to fix things up on their own or they intend to reassign the bug to the kernel maintainer. If it can be of some help i can post by myself the bug to the kernel list. The only reason for which i didn't post the bug there is that i didn't mean to spread a lot of (redundant) information all over bug-lists. That's all. Thank you for the quick reply Best regards Raffaele Candeliere
> Actually i didn't speak to kernel people. Mr Hutterer (the package maintainer > for Fedora xkbd-utils, i suppose) asked me some details about the exchanged > keycodes (which i provided along with my comment also to you) while suggesting > me to reopen this bug. Ok, so I guess we agreed to close this bug. In Fedora's bugzilla, I guess you should assign the original bug to the kernel maintainers - so they could push it upstream.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.