[fixed] Apple Alu keyboard and X.org server 1.9 -hal +udev

[Atha]

Recently, the new X server 1.9 has become stable. With it, HAL was dropped for acquiring input devices on the fly (hot plugging).

The situation is, I used to have a Power Mac G5 and with it a used an Apple Aluminium USB keyboard, but the ISO variant MB110D/A (german). The keyboard is very nice, quite expensive, but I love it. It is non-standard in some ways though, and sadly it is missing the Insert key – it featues a laptop-like Fn (Function) key instead.

The standard (as Apple wanted it) would be to have direct access to the media keys and Fn keys, without pressing Fn. So you'd get easy access to brighness, Dashboard and Exposé, and Play/Stop/Next/Previous as well as volume control. But you'd have to use Fn to get F1 though F12.
For a Linux guy like me this is not what I want.

So, there are three issues to be fixed for this keyboard:

• Use a german keyboard layout
• F1-F12 keys without Fn
• Swap dead circumflex (^)/degree (°) and less (<)/greater (>)/bar (|) – because it is simply swapped with the default layout
• Make the Fn key be an Insert key

Use a german keyboard layout
Setting the keyboard to german in /etc/conf.d/keymaps with KEYMAP="de-latin1" makes it mostly work for non-X11. (I'll explain a little adjustment I made later).

In X11 I simply use Option "XkbLayout" "de". Additionally, Option "XkbModel" "apple_aluiso" should make it work out-of-the-box – but it doesn't. (Read on.)

F1-F12 keys without Fn
The kernel easily fixes this issue, simply add hid_apple.fnmode=2 to the kernel command line.
Sadly, I haven't found a way yet to set this in a sysctl way after the kernel has started, AND with hid_apple compiled into the kernel (not as a module, in which case this option could be added to modprobe.d – /etc/modprobe.d/applehid.conf as I named it).
The importaint thing is: it works.

Swap dead circumflex (^)/degree (°) and less (<)/greater (>)/bar (|)
Now, my problem – which seems to be a commen one btw – is, that the ^° (which should be top left, below the Escape key) and <|> (which should be right next to the left Shift) keys are swapped. I don't know why this is, but it is for all german Apple Aluminium ISO keyboards.

In the console, I simply altered /usr/share/keymaps/i386/qwertz/de-latin1.map.gz. To be more transparent, I made a new map de-AppleAluISO.map.gz and changed to KEYMAP="de-AppleAluISO":

Code: Select all

# de-AppleAluISO.map: German keymap for Apple Alu ISO USB keyboard (MB110D/A)

include "de-latin1.map"

# swap keycodes 86 and 41 to correspond with the actual layout
keycode  86 = dead_circumflex   degree   Meta_asciicircum        Control_asciicircum
keycode  41 = less             greater          bar

NOTE: This keymap applies to all connected keyboards. Since using more than one keyboard at the same time (at least in the console) seems to be very uncommon, this solution is quite okay.

For X11, I used the global Xmodmap /etc/X11/xinit/Xmodmap which makes it work, but is not very clean since it applys the changes to all keyboards. Again, it is very uncommon to connect more than one keyboard, but regardless I don't like this too much.

Code: Select all

! Xmodmap
! Apple Aluminium USB keyboard tweaks

!
! set this right:
!
keycode  49 = less greater less greater bar brokenbar bar
keycode  94 = dead_circumflex degree dead_circumflex degree U2032 U2033 U2032

Make the Fn key be an Insert key
Now comes the big problem:
For X11, until now I used a HAL .fdi file that I found here: http://damienciabrini.blogspot.com/2009 ... board.html (a great blog about how to get the ISO Alu keyboard working right in Linux)
It changes the Fn keycode 464 (Fn key) to 110 (Insert key) in a very uncommon way (the HAL way).

Until now this all worked well. Since the update this hack isn't available anymore which is quite obvious.
So, does anyone know how to get this solution back to working?



Last but not least, I used to have some special unicode keys at different places. E.g. Alt-Gr+- gave – (en dash). Now it is something I've never seen before : ̣. I also miss the dots … a lot, used to be AltGr+., now it gives ·. All the quotation marks (e.g. “”) as well as the mathematical signs (e.g. ÷) also changed position. It seems like everything has changed, but I don't know how and why. These keys are even then changed when don't configure at all, i.e. when I leave all xorg.conf empty – I then get the english keyboard layout, with all the wrong keys (<>/^° and unicode keys).
This is very annoying. Help is most appreciated. Also, I don't know exactly where which unicode sign used to be, so I cannot make a hack mapping for them. I simply want the old behaviour back.


Thanks in advance,
A.

[VoidMage]

I think you should look at /lib/udev/rules.d/95-keymap.rules and /lib/udev/keymaps/.

[Atha]

I think you should look at /lib/udev/rules.d/95-keymap.rules and /lib/udev/keymaps/.

Thanks. This is a good place to start. But the Aluminium keyboard, or rather in general all Apple keyboards are completely missing there. It seems like noone ever had to add its configuration to udev – until now.

I'll try a newer version of udev, and maybe I find something about it in the depth of the world wide web. I certainly don't want to write it for myself.

Thanks, A.

[Atha]

I've emerged sys-fs/udev-164-r1 (ACCEPT_KEYWORDS="~amd64") but it still doesn't include any Apple Alu USB keyboard keymaps yet.

I've run /lib/udev/keymap -i /dev/input/event3 (because event3 and event4 are what my /var/log/Xorg.0.log shows as KEYBOARD inputs, input4 doesn't seem to work with this command) and pressed the Fn key:

Code: Select all

scan code: 0x70028   key code: fn

This is quite interesting. Because when I press the KEY=circumflex/degree (which is mismapped to GIVES=less/greater/bar by the out-of-the-box configuration), I get the same scan code:

Code: Select all

scan code: 0x70028   key code: 102nd

For the completeness: KEY=less/greater/bar GIVES=circumflex/degree:

Code: Select all

scan code: 0x70028   key code: grave

KEY=Shift+less/greater/bar GIVES=circumflex/degree

Code: Select all

scan code: 0x700E1   key code: leftshift
scan code: 0x700E1   key code: grave

I don't know what to do with this value. When 0x70028 is a hexadecimal number (what 0x indicates), this is decimal 458792. Like I mentioned in my initial post, Damien Ciabrini writes (in his excelent blog about the Apple Alu keyboard) that the Fn key is keycode 464.

So now what?

All the keymappings in /lib[64|32|]/udev/rules.d/keymaps include scan codes in hexadecimal form followed by key names (key codes???). So I could write 0x70028 fn for the Fn key to be the Fn key. But how to make it an insert key. 0x70028 insert maybe? But what is 0x70028 102nd then – it does have the same scan code!

Couldn't find a suitable manual for udev /lib/udev/keymap yet.
A complete udev guide for all that /lib/udev stuff would be great – “complete” in the sense of “includes everything”.

Help very much appreciated!
Cheers, A.

[VoidMage]

Well, there is a short readme in udev tarball, it's even installed.
The answer is (more or less) yes. The names are taken from /usr/include/linux/input.h (surprisingly, there is a key named "102nd").

But two minor details:
1. xmodmap often messes things up lately, as you are doing that mapping regardless of console/X, doing it once should be enough
2. it seems that your keymap hack can be applied in the same way as above, making things cleaner

[Atha]

Okay. I've read though it: /usr/share/doc/udev-164-r1/README.keymap.txt.bz2.

Unfortunately, using /lib/udev/keymap as intended doesn't give the expected results.

First, this is the keyboard the fuzz is all about: picture (better would be CC licensed, but this one is quite usable) or order (german). Note that the english version is quite different!

Fortunate as I am I found and restored the original Apple keyboard from my Power Mac G5 for the purpose of testing: it's the white Apple Keyboard (picture in linked page), derived from the previous Apple Pro Keyboard. Basically, this is a standard PC-style USB keyboard with function keys up to F16 and the additional keys for volume control (up, down, mute) and eject. What Apple labeled "Help" is actually the standard Insert key code/scan code.

This is what I found out by cross checking with the two keyboards:
The Apple Aluminium (apple_aluiso) gives the last sent (or rather received?) scan code when either Fn, circumflex/degree or less/greater/bar is pressed. BUT, surprisingly, the key is recognized correctly by name anyhow. I just don't get why this is happening.

Here is the comparison:
apple_aluiso

• ID (detected as): Apple, Inc Apple Keyboard
• key Fn: no reliable scan code, key code fn
• key circumflex/degree: no reliable scan code, key code 102nd
• key less/greater/bar: no reliable scan code, key code grave
• key Eject: always prints ^@ in /lib/udev/keymap

(classic) Apple Keyboard

• ID (detected as): Mitsumi Electric Apple Extended USB Keyboard
• key “Help”: scan code 0x70035, key code insert
• key circumflex/degree: scan code 0x70064, key code grave
• key less/greater/bar: scan code 0x70049 , key code 102nd
• key Eject: always prints ^@ in /lib/udev/keymap

So how do I map such keys?
For me this is a dead end. I simply don't know how to make this work. HELP!

Cheers, A.

[Atha]

Okay. I have reused my first temporary workaround from >1yr ago: I mapped the Insert key to the F13 key (above Fn i.e. where Insert normally is) with xmodmap. Shift-F13 is the normal F13:

Code: Select all

keycode 191 = Insert F13

I've filed bug #25772 at bugzilla.kernel.org about the Apple Alu ISO not working correctly. The one issue is the mismapped <|>/^° and the second the unremappable Fn key which used to work with HAL.

Maybe the kernel input methods have to be patched to make the key remappable. I don't know. I sure hope someone can come up with a solution, because I've arrived at a point where I can't. It used to work with HAL, so why not with udev?

Thanks anyway.
A.

[VoidMage]

...and did you add a rule applying the remapping ? The rules I pointed you to should serve as a template,
you need to write a rule for your keyboard (and then probably send the corrections upstream, that is to udev,
as advised in that readme).

Edit: sorry, I misunderstood a part of your post. If that util fails, does i.e. xev or xinput give you a scancode ?

[Atha]

...and did you add a rule applying the remapping ? The rules I pointed you to should serve as a template,
you need to write a rule for your keyboard (and then probably send the corrections upstream, that is to udev,
as advised in that readme).

Yes, I read the readme you pointed me to and I was willing to contribute my rule. Only, I couldn't write one.

As I mentioned, HOW can I add a rule, if the scan code is not reliable? The keys that need to be remapped don't give a scan code. And how I see it in udev, a scan code can be mapped to a key code, i.e. you can make a scan code be interpreted as the key code you whish it to be. Not the other way around, and not that you can remap a key code to be interpreted as another key code.

I asked, but noone helped me.
My thinking is, that the missing scan code issue may be a kernel issue. That's why I reported a bug.

Any comments?

[Atha]

Edit: sorry, I misunderstood a part of your post. If that util fails, does i.e. xev or xinput give you a scancode ?

xev does for the ^° and <>| keys, but not for the Fn key. Also, I can only make a global map for all connected keyboards using xmodmap. (Think of a laptop with connected Apple Alu USB keyboard - if I remap, I do this also on the laptops internal keyboard. Not good!)

[VoidMage]

Does 'showkey -s' show it ? It must be run from the console.

[Atha]

Does 'showkey -s' show it ? It must be run from the console.

showkey -s results:

• ^°-key (dead circumflex/degree): 0x29 0xa9
• <>|-key (less/greater/bar): 0x56 0xd6
• fn-key: not recognized (no output whatsoever)

(while I ran showkey -s, I had my keymap hack active and an open X11 session!)

Well, but /lib/udev/keymap doesn't give a reliable scan code for them - instead it repeats the last received code. The key code is correct though, also for fn.

[VoidMage]

Does 'showkey -s' show it ? It must be run from the console.

(while I ran showkey -s, I had my keymap hack active and an open X11 session!)

That doesn't seem right (unless you've meant "while I ran it from the console, I had...an open X11 session"). What do you have in your xorg.conf (whole file) ?

[Atha]

/lib/udev/keymap retested:

• all keys have unique scan codes, except the three in question, plus one more:
• the eject key always prints ^@
• 0x70028 is actually Enter, the last key pressed before fn (if fn is the first pressed key, the last actually was Enter to start /lib/udev/keymap)
• I still don't get it, why the hell the key code is correct but the scan code isn't updated ?!?

xev restested:

• ^°-key (dead circumflex/degree): keycode 94
• <>|-key (less/greater/bar): keycode 49
• Eject key: keycode 169 (in my personal KDE settings I've mapped it to XF86Eject and set it to run /usr/bin/eject -T)
• Fn key: not recognized/completely ignored/no event reported

Additional to previous showkey -s:

• Eject key: 0x6c 0xec

So, three different programs to grab scan codes and key codes, and three somewhat different results.


----

That doesn't seem right (unless you've meant "while I ran it from the console, I had...an open X11 session"). What do you have in your xorg.conf (whole file) ?

Yap, that's what I meant to say.

xorg.conf... interesting that you ask. I don't have one. I let X.org determine all by itself.

[Atha]

If you wonder how I set up the keyboard without an xorg.conf -- I use this script:

Code: Select all

#!/bin/sh
# default options
DEV="/dev/input/by-id/usb-Apple__Inc_Apple_Keyboard-event-kbd"
XKB_DEV="input/event3"
XKB_MODEL="applealu_iso"
XKB_LAYOUT="de"
XKB_OPTIONS="apple:alul3media,nbsp:level3n,lv3:ralt_switch,terminate:ctrl_alt_bksp"
# don't use: apple:alupckeys
# may use: misc:typo

# check if DEV is a symlink (it's supposed to be!)
if [ -L "${DEV}" ] ; then
  echo -n "Using device: ${DEV}"
else
  echo "Device symlink wrong or doesn't exist: ${DEV}"
  exit 1
fi

# get the right keyboard
  # get basename of symlinked file
XKB_DEV="$(basename "$(readlink "${DEV}")")"
  # RESULT: "event3"
  # remove trailing "event"
XKB_DEV="${XKB_DEV/\event/}"
  # RESULT: "3"
# DEBUG:
echo " (input/event${XKB_DEV})"

# set keymap
echo "Executing: /usr/bin/setxkbmap -device ${XKB_DEV} -model ${XKB_MODEL} -layout ${XKB_LAYOUT} -option -option ${XKB_OPTIONS}"
/usr/bin/setxkbmap -device ${XKB_DEV} -model ${XKB_MODEL} -layout ${XKB_LAYOUT} -option -option ${XKB_OPTIONS}
echo "Returned: $?"

# set modmap
if [ -e "$HOME/.Xmodmap" ] ; then
  echo
  echo "Found user .Xmodmap, applying"
  echo "Executing: xmodmap \"$HOME/.Xmodmap\""
  xmodmap "$HOME/.Xmodmap"
  echo "Returned: $?"
fi
exit 0

I don't want to use an xorg.conf. I'd rather use udev to set it all up, and not only for X11. But since this isn't working, I autostart this script until... We'll see.
The script echos a lot, so I could check if it is done right when I wrote it. Didn't remove it yet, but I think this way it is better to see what it does.

[VoidMage]

That script is so wrong on just too many levels.
Now, it's quite unsurprising the results are inconsistent.

Drop the whole block running setxkbmap, you don't really need full xorg.conf, just a short InputClass snippet
(there is a way for doing it by udev rule only, I actually use it, but I can't find it documented anywhere).
Match rules in InputClass are direct mappings of udev values (as seen by 'udevadm info').
I wouldn't be surprised if .Xmodmap added another smoke screen.

[Atha]

That script is so wrong on just too many levels.
Now, it's quite unsurprising the results are inconsistent.
[...]
I wouldn't be surprised if .Xmodmap added another smoke screen.

I'm sorry ─ what's wrong with it?
setxkbmap is doing exactly what the InputClass snippet of xorg.conf should do.
My way of determining on which input/eventX the Apple Alu keyboard is connected may not be very well written, but it gets the correct number, which is then passed on to -device of setxkbmap.

My .Xmodmap simply switches the <> and ^° keys, as mentioned in my previous posts. No more than that! If you know a way of doing a remapping in xorg.conf(.d/something), or even in udev (with the keys not giving a unique scan code!), then please tell me.

I cannot see how I couldn't be more right. Sorry, but your comment was no help at all. Everything that can be set in xorg.conf should also be adjustable using the xorg command line tools.




For clarification: these are the ONLY settings I have right now:

• /etc/env.d/02locale (LANG="german" LANGUAGE="de_AT.utf8" LC_ALL="de_AT.utf8" GDM_LANG="de_AT.utf8")
• /etc/conf.d/keymaps (KEYMAP="de-AppleAluISO" SET_WINDOWKEYS="yes" EXTENDED_KEYMAPS="" DUMPKEYS_CHARSET="")
• keymap de-AppleAluISO just swaps <> and ^° for the console (with and without X11)
• NO xorg.conf --> english keyboard layout, switched keys <> and ^° when setting german keyboard layout, no fn key scan code or key code
• my script which sets the applealu_iso for only the Apple Alu ISO keyboard and the german keymap
• my script which swaps the <> and ^° keys in X11 for ALL keyboards (not intended, but a temporary workaround).

Code: Select all

Using device: /dev/input/by-id/usb-Apple__Inc_Apple_Keyboard-event-kbd (input/event3)
Executing: /usr/bin/setxkbmap -device 3 -model applealu_iso -layout de -option -option apple:alul3media,nbsp:level3n,lv3:ralt_switch,terminate:ctrl_alt_bksp
Returned: 0

Found user .Xmodmap, applying
Executing: /usr/bin/xmodmap "/home/andreas/.Xmodmap"
Returned: 0

Code: Select all

! Xmodmap 
! Apple Aluminium USB keyboard tweaks 

! 
! set this right: 
! 
keycode  49 = less greater less greater bar brokenbar bar 
keycode  94 = dead_circumflex degree dead_circumflex degree U2032 U2033 U2032

Code: Select all

# de-AppleAluISO.map: German keymap for Apple Alu ISO USB keyboard (MB110D/A)

include "de-latin1.map"

# swap keycodes 86 and 41 to correspond with the actual layout
keycode  86 = dead_circumflex   degree   Meta_asciicircum        Control_asciicircum
keycode  41 = less             greater          bar

Please go on, tell me that this is sooooo wrong again!

[Atha]

Surprisingly, with kernel 2.6.37 (gentoo-sources) the input device changed from input3 to input4. AND, setxkbmap -device 4 (i.e. input4) now returns an error.

I'm now setting the keyboard with xorg.conf snippets, which does work as expected and gives the used-to-be Unicode keys with AltGr. (AltGr+- is again the en dash “–”, and the quotation marks are where they used to be: AltGr+v=„, +b=“, +n=”).

I don't even dare to ask WHY the setxkbmap results are different from the SAME settings in an xorg.conf file…

In my defence: I tried this before, but it didn't work (using the VERY SAME settings=xorg.conf.d/* snippets as I do now). I don't know why, but there have been some updates in portage for X.org specific stuff, so I can only assue that that was it.
Also, my ~/.xmodmap is now loaded by default somehow, which was not the case before. (Why? I don't get it…)

What remains unsolved:

• All keyboard specific remappings are global, but should be specific to the Apple Aluminium keyboard only.
• X11:
• dead circumflex (^)/degree (°) and less (<)/greater (>)/bar (|) are now correct in X11 ONLY with my ~/.xmodmap (see previous post)
• Fn key is not remappable
• Insert key is only available though my ~/.xmodmap (I mapped the F13 key to be Insert, and Shift+F13 to be F13).
• Console:
• dead circumflex (^)/degree (°) and less (<)/greater (>)/bar (|) is corrected by using my modified keymap /usr/share/keymaps/i386/qwertz/de-AppleAluISO.map.gz (see previous post)
• Insert key not available (although remapping is possible)
• Fn key is not remappable (and therefor cannot become the Insert key)

So it basicly comes back to my fist posting. With HAL the remapping of the Fn key was possible, with udev it is not (AFAIK).

Thanks to VoidMage for the help so far. Sadly these issues are still unsolved, and I fear they have to be solved at a much deeper level (presumably in the code of the kernel itself and in udev). So far there have been no reactions to my bug report at the Kernel Bug Tracker.

So, I can only ask again… for HELP!

Thanks,
A.

[psmillie]

Atha,

I too like the Apple Aluminum keyboard, but it is giving me a lot of grief so I am starting to regret my investment.

I read your posts with great interest and was disappointed there was not a final resolution, particularly for remapping the "fn" key. Thanks for taking the time to post the work you did on researching and trying to resolved the problems.

Have you read this Ubuntu documentation web page "https://help.ubuntu.com/community/AppleKeyboard". It may be applicable to gentoo Linux. It is applicable to Debian Linux 6.0, which is the distribution I am using. Even so it has some interesting information on key codes generated by the "fn" key with other keys.

When reading the web page replace "hid-apple" with "hid_apple".

The section "Correcting the two swapped keys for international (non-US) keyboards" will be of particular interest to you.

Regards
Peter S.

[dciabrini]

Hi Atha, Gentoo people,

I have improved the support for the Aluminium Keyboards Atha talked about in his first post. You now get keyboard auto-detection under X, Key remapping preferences and precedence of fonction keys over multimedia keys.

You can get the latest sources for this support at:
https://github.com/dciabrin/apple-kbd

You'll get a bit more info on how it works at:
http://damienciabrini.blogspot.com/sear ... /apple-kbd

Hope this helps!

Cheers,
Damien

[Atha]

Thanks, Dam!

With your udev rule from https://github.com/dciabrin/apple-kbd the Fn key works as Insert again! Thank you very much & sorry for the late reply. I've been quite busy.

What I did:

• I removed my ~/.xmodmap
• /etc/conf.d/keymaps – reset to KEYMAP="de-latin1"
• xorg.conf --> using snippets (for keyboard layout to be german)
• udev-rule from apple-kbd by Dam
• apple-kbd in /etc/conf.d (the Gentoo place for such a file), and the udev rule adapted accordingly

This gives me a working system, with only the nasty keys swapped problem (<>| and ^°). I then found the iso_layout option, mentioned by Stefan Glasenhardt on 2009-06-15 at launchpad.

I then added this option to apple-kbd by Dam accordingly. I sent this patch to Dam for him to review it.

• iso_layout set to 0 fixes the swapped keys problem

Resumé:

• Working/fixed with apple-kbd by Dam

Thanks!

[dciabrini]

I then added this option to apple-kbd by Dam accordingly. I sent this patch to Dam for him to review it.

• iso_layout set to 0 fixes the swapped keys problem

Thanks for the patch! I'll integrate the fix for the typo you pinpointed. I'll have a deeper look at the new option as soon as I get some time