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).
Enjoy!
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
14 comments:
Woot! This was exactly what I wanted. Thanks for all the hard work.
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 :)
Cheers
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.
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
Cheers
Haha, bad link for the freedesktop patch, FAIL!
you can find the patch
here
yeah, everything works now.
Thanks.
hi
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
10604000
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 = []
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
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
Cheers!
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)" };
};
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
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.
Never mind, I figured it out myself using xmodmap from xorg-server-utils. Thanks a lot for the keyboard model patch though.
Hi Dam
This looks good, but when applying the patch, I gets this output.
What to do, how to fix ?
BTW, using PCLinuxOS
Cheers
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
Post a Comment