Bug 476057 - setxkbdmap with -option apple:badmap doesn't work with alu iMac
setxkbdmap with -option apple:badmap doesn't work with alu iMac
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-11 13:36 EST by Raffaele Candeliere
Modified: 2010-11-23 07:57 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:16:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of the xev tool after hitting the mentioned keys (7.17 KB, text/plain)
2008-12-18 07:25 EST, Raffaele Candeliere
no flags Details
Output of the xkbcomp tool (56.63 KB, text/plain)
2008-12-18 07:26 EST, Raffaele Candeliere
no flags Details
output of the evtest c program (8.00 KB, text/plain)
2008-12-26 10:10 EST, Raffaele Candeliere
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 9095 None None None Never

  None (edit)
Description Raffaele Candeliere 2008-12-11 13:36:59 EST
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:
Comment 1 Peter Hutterer 2008-12-17 19:50:27 EST
Please attach the output of xkbcomp -xkb :0 -.
Please attach the output of xev after hitting the keys that are mapped incorrectly.
Comment 2 Raffaele Candeliere 2008-12-18 07:25:39 EST
Created attachment 327317 [details]
Output of the xev tool after hitting the mentioned keys
Comment 3 Raffaele Candeliere 2008-12-18 07:26:44 EST
Created attachment 327318 [details]
Output of the xkbcomp tool
Comment 4 Raffaele Candeliere 2008-12-20 12:07:54 EST
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
Comment 5 Peter Hutterer 2008-12-22 02:34:04 EST
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.
Comment 6 Raffaele Candeliere 2008-12-26 10:10:26 EST
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.
Comment 7 Raffaele Candeliere 2008-12-26 10:21:24 EST
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
Comment 8 Peter Hutterer 2009-01-05 19:06:45 EST
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.
Comment 9 Raffaele Candeliere 2009-01-06 04:49:12 EST
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.
Comment 10 Peter Hutterer 2009-01-07 23:58:09 EST
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.
Comment 11 Bug Zapper 2009-11-18 07:41:26 EST
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
Comment 12 Bug Zapper 2009-12-18 02:16:03 EST
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.
Comment 13 Yves-Alexis Perez 2010-11-23 07:57:55 EST
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

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