Tuesday, December 22, 2009

Aluminium Keyboard support under X11: all models, all OSes

I finally found the time to update my previous support for Aluminium Keyboard under Xorg, and take it to the Next Level (tm). The overall support is now much more polished. For you this means several things:

  • I've implemented the XKB geometries of all variants of the long Aluminium Keyboard, be it ANSI (American), ISO (Internationnal) or JIS (Japanese)! And believe me, it's darned complicated to support JIS keyboard's dual layout without having access to the real hardware :D
  • I've added support for base XKB rules, which means that the keyboard will now be properly configured on other OSes than Linux. I personally used OpenSolaris during my tests, but it should work equally well on FreeBSD, OpenBSD, and all their cousins!
  • The keyboard support is now aware of the system-wide keyboard settings as found in Debian or Fedora for example. If you configured your system to default to Dvorak layout, the support will use it automatically!

Installing the new support

I'm short on details, but you can find a complete explanation for all these steps in a previous post.

XKB Patch

First of all, download this XKB patch and try to apply it on your XKB install in dry-run. For the sake of the example, I assume you downloaded the patch in your $HOME directory.

sudo bash
cd /usr/share/X11/xkb
gunzip -cd $HOME/applekbd-xkb-support.patch.gz | patch -p1 --dry-run

If the patch applies successfuly, you can proceed and apply it for real:

gunzip -cd $HOME/applekbd-xkb-support.patch.gz | patch -p1

HAL support

Well, even if HAL is meant to be replaced sooner or later by DeviceKit, that's the way to go for the time being. So I reworked the previous HAL support and split it in one fdi file to track your keyboard on your hardware, plus a script to configure XKB for Aluminium Keyboard and to remap the Fn key to Insert. To install it, first remove the fdi file from the previous support if necessary. Then, copy this new fdi file (which you have previously downloaded in your $HOME directory) in the relevant HAL directory. On my Ubuntu Karmic, this gives (update: added missing chmod, thanks Patrick):

sudo bash
rm -f /usr/share/hal/fdi/policy/30user/10-apple-aluminium-kbd.fdi
mkdir -p /usr/share/hal/fdi/policy/30user
cp $HOME/10-applekbd-xkb-settings.fdi /usr/share/hal/fdi/policy/30user

Download (I assume in your $HOME directory) the new script for XKB setting, plus its associated configuration file. Then copy them respectively in HAL's installation directory and in the system-wide configuration directory. On my Ubuntu, ths gives:

sudo bash
cp $HOME/applekbd-xkb-settings.sh /usr/lib/hal
chmod +x /usr/lib/hal/applekbd-xkb-settings.sh
cp $HOME/applekbd-xkb-settings /etc/default

You can tweak the configuration file /etc/default/applekbd-xkb-settings to enable the settings you want for your keyboard. By default, the Fn key is remapped to Insert. The XKB options can be configured there for system-wide setting, as explained in the configuration file itself. But it's more user-friendly to configure XKB in your preferred Desktop Environment (GNOME, KDE, XFCE... whatever).


I'm particularly happy with my revised XKB geometries. A tedious work, but this time keys dimension and layout perfectly match the original hardware, whatever the model. I'm even more happy now that I discovered how Apple decided to implement their EISU and KANA keys on the JIS keyboard! If you are curious, have a look at file xkb/keycodes/machintosh in the patch, or read this post on Parallels' forum.

The XKB patches are now ready for submission to the Xorg people (xkeyboard-config). The rest of the files are also clean enough to start providing .deb packages for this support! Maybe a good opportunity of learning PPA in LaunchPad :P


sarnold said...

Woot! This was exactly what I wanted. Thanks for all the hard work.

Dam said...

Hi sarnold,
There was a missing chmod in the installation procedure, which causes the Fn->Insert trick to fail.

It has been fixed in the post now, when you have time, please tell me if the support works for you :)


Xavier said...

Hi! I'm having problems with the keypad.
even remaping the key to Num_lock with xmodmap, the only way to access the numbers is to press shift.
Any clues?
Thanks a lot.

Dam said...

Hi Xavier,
Yes, sorry there's a bug in this patch. I've submitted an clean one to freedesktop some weeks ago, so hopefully the support will become official someday :)

You can fix the keypad issue yourself by updating the file /usr/share/X11/xkb/rules/evdev. Locate the lines:
! model = types
$macs = complete+numpad(mac)

and add the following line just after
$applealu = complete+numpad(mac)

I'll provide an up-to-date patch ASAP, along with a .deb to simplify the whole process.

Tell me if it works for you

Dam said...

Haha, bad link for the freedesktop patch, FAIL!

you can find the patch

Xavier said...

yeah, everything works now.

Anonymous said...

nice patch. it still doesn't work for me, dunno why.. i get following error:
Error activating XKB configuration.
It can happen under various circumstances:
- a bug in libxklavier library
- a bug in X server (xkbcomp, xmodmap utilities)
- X server with incompatible libxkbfile implementation

X server version data:
The X.Org Foundation

If you report this situation as a bug, please include:
- The result of xprop -root | grep XKB
- The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd

if this helps you:
xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "apple_aluiso", "us", "mac", "grp:alts_toggle,altwin:swap_lalt_lwin,eurosign:e"
_XKB_RULES_NAMES(STRING) = "evdev", "apple", "us", "mac", "grp:alts_toggle,eurosign:e,altwin:swap_lalt_lwin"

gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
model =
options = []
layouts = []

Dam said...

Hi Hugo!

[late comment...] Thanks for your feedback and for the debug info, I'll try to have a look tonight :)

Looking at your XKB settings, it seems you're not using a configuration which should break the patch... so hopefully things should get sorted out soon


Dam said...

HA! Got it :)
_XKB_RULES_NAMES(STRING) = "evdev", "apple", ...

Weird, the model used by xkb is "apple", while it should be "apple_aluiso".

Apparently, you tried to set it somewhere already, maybe from the FDI file, as there exist variable _XKB_RULES_NAMES_BACKUP. What's strange is that gconftool does not contain any setting...

Can you try:
setxkbmap -model apple_aluiso -option "" -layout "us" -print

And see if the symbol apple_aluiso appears in the xkb_geometry tag? This will tell if the patch applies cleanly on your machine


Anonymous said...

hi Dam
sorry for the late reply. here is the output you requested, seems like the patch did not apply (?)
setxkbmap -model apple_aluiso -option "" -layout "us" -print
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc104)" };

Anonymous said...

btw, i have karmic koala,
Linux 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

Mitch said...

Hi, I followed your instructions and it worked fine. However, it didn't do the one thing I really wanted, fixing the media keys. I want to use the F buttons by holding down fn, and using the media keys by default (I turned off the insert mapping in the configuration file). But not all the media keys work -- well actually just two, but it's really annoying me: the expose and dashboard keys. I would really like to have these working so I can map the expose key to the compiz "scale". They should give something like XF86Expose and XF86Dashboard, like the other media keys. Right now they don't work at all in the compiz manager, and in the (gnome) keyboard shortcuts preferences, they give "0x80" and "0xd4" (but when I press the key after it doesn't do anything -- it does with the other media keys which have XF86___ names). If you have the time, and know how to do this, would you consider updating your patch with this functionality? Thanks.

Mitch said...

Never mind, I figured it out myself using xmodmap from xorg-server-utils. Thanks a lot for the keyboard model patch though.

BGRoper said...

Hi Dam
This looks good, but when applying the patch, I gets this output.
What to do, how to fix ?
BTW, using PCLinuxOS

patching file rules/base
Hunk #2 succeeded at 115 (offset 1 line).
Hunk #3 succeeded at 154 (offset 1 line).
Hunk #4 succeeded at 310 (offset 1 line).
Hunk #5 succeeded at 901 with fuzz 2 (offset 2 lines).
Hunk #6 succeeded at 1041 (offset 3 lines).
patching file rules/base.lst
Hunk #2 succeeded at 715 (offset -1 lines).
patching file rules/base.xml
Hunk #2 succeeded at 4937 (offset -7 lines).
patching file rules/evdev
Hunk #2 succeeded at 108 (offset 1 line).
Hunk #3 succeeded at 143 (offset 1 line).
Hunk #4 succeeded at 299 (offset 1 line).
Hunk #5 FAILED at 841.
Hunk #6 succeeded at 980 (offset 1 line).
1 out of 6 hunks FAILED -- saving rejects to file rules/evdev.rej
patching file rules/evdev.lst
Hunk #2 succeeded at 715 (offset -1 lines).
patching file rules/evdev.xml
Hunk #2 succeeded at 4937 (offset -7 lines).
patching file keycodes/macintosh
patching file symbols/macintosh_vndr/apple
The next patch would create the file symbols/macintosh_vndr/jp,
which already exists! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file geometry/apple_vndr/alukbd,
which already exists! Assume -R? [n] y
patching file geometry/apple_vndr/alukbd