[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":

[VoidMage]

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

[Atha]

[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:

[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:

[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]

[Atha]

[VoidMage]

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

[Atha]

[VoidMage]

[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.


----

[Atha]

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

[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]

[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.
_________________
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/search/label/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]