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

```
# 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.

```
! 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/05/make-your-apple-aluminium-keyboard.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.Last edited by Atha on Thu Oct 27, 2011 12:35 pm; edited 1 time in total

----------

## VoidMage

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

----------

## Atha

 *VoidMage wrote:*   

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

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

```
scan code: 0x70028   key code: 102nd
```

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

```
scan code: 0x70028   key code: grave
```

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

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

```
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

 *VoidMage wrote:*   

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

 *VoidMage wrote:*   

> 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

 *VoidMage wrote:*   

> 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

 *Atha wrote:*   

>  *VoidMage wrote:*   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.

----

 *VoidMage wrote:*   

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

```
#!/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

 *VoidMage wrote:*   

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

 

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.

 :Confused: 

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

```
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

```

```
! 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
```

```
# 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/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

 *Atha wrote:*   

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

----------

