Support for Aluminium Keyboards packaged, code-named apple-kbd

After many episodes, the support for Apple Aluminium Keyboards is finally becoming user-friendly. All major distribs now ship a recent version of xkeyboard-config, so there is no need to mess with XKB patches anymore...

To complete the user experience, I'm happy to introduce you apple-kbd, the collection of helpful goodies you need for your Aluminium Keyboard under Linux. Here's what you'll get with this package:

Automatic keyboard detection under X

At boot time or when the keyboard is plugged in, apple-kbd auto-updates the system-wide XKB settings so that the X server sees the Aluminium Keyboard and enables all its keys and its geometry.

Key style preferences

apple-kbd lets you remap some of the keyboard's keys: you'll get back the Insert key, the antique Print, Scroll-Lock and Pause... You can also set the precedence of functions keys over multimedia keys.

User-friendly installation

Both auto-detect and configuration features are available in a single, easy to install package. If you're running Debian or Ubuntu, there's even a package for you which comes with interactive configuration thanks to debconf!

Apple Aluminium Keyboards with udev, Xorg server 1.9

It's been a year now since I published my support for Aluminium Keyboards. Since then, my XKB patches have been accepted in XKeyboardConfig 1.9, with a few modifications:

• The multimedia keys can always be accessed by combining Fxx with the 3rd level chooser (this was option alul3media in my original XKB patches)
• There is now a single XKB option alupckeys to emulate the behaviour of a PC keyboard, i.e. to enable PrintScreen, ScrollLock, SysReq and NumLock (options alupcfkeys and alupcnumlock in the original patches)

Meanwhile, Xorg server 1.9 went stable, becoming more and more pervasive. As far as input hotplugging is concerned, this is a major revision for it dropped HAL in favor of udev: input discovery is achieved via udev and XKB settings for devices are fetched from the udev database.

I have thus ported the support for the Aluminium Keyboards to udev. As before, a configuration file controls the XKB settings to apply, as well as the remapping of the "fn" key to "insert", if requested.

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!

Make your Apple Aluminium Keyboard really work under Linux, X.org

Like many others, I've bought an Aluminium Keyboard for its cool style the smooth typing experience it provides. Mine is a wired version, ISO variant (international, 110-keys). It's not working 100% out-of-the-box under Linux, so this post explains what I did to make it happen:

• Supporting the additional keys (F13..F19) and geometry (physical layout) under X.org
• Making the keyboard auto-configured at X.org startup. No need to mess with xorg.conf!

But wait, there's more. If you're accustomed to PC keyboards, you really need those ones too:

• Making this fn key located on top of the delete key behave like a regular PC keyboard: Insert!
• Making multimedia keys output Fxx symbols by default
• Making F13..F15 behave like those charmingly obsolete Scroll Lock..Print Screen keys
• Keeping the multimedia keys accessible when the fn key is remapped to Insert

Toolchain.sh is amazing!

A few weeks ago, I finally upgraded my iPhone to firwmare 2.2.1. It was actually an utterly painless operation, thanks to the amazing toolchain.sh by the guys from iphonedevlinux.

I remember in the 1.1.4 days, I had a hard time extracting the MacOS 10.5 SDK on Linux and compiling the openSDK on my Core2 Quad by following saurik's great instructions.

It turns out that building an open SDK for firmware 2.2.1 is actually very simple: getting a copy of the phone's sysroot, building GCC, importing headers from the official iphone SDK, classdumping private frameworks... all these operations are now almost automatic thanks to toolchain.sh.

The icing on the cake: those smart people from iphonedevlinux are friendly and reactive! Another good reason for sending them patches and using their script :)

Hello MikMod!

As promised earlier, I've packaged an obligatory example of how to use the iPhone port of libmikmod which I've talked about recently. Go grab this tarball which implements a very simple "Hello World!":

• It shows how to play a module within a UIKit application. This is an adaptation of the skeleton program found in MikMod Documentation.
• It shows how to use the higher level sound API Celestial to control mikmod output. For instance, how to react to volume change events when iPhone buttons are pressed.

What to do with this archive once you've extracted it?

  tar -zxf HelloMikMod.tar.gz
  cd HelloMikMod

Simple! Modify the Makefile to set the location of the AudioQueue.h header, as well as the location where you've installed libmikmod. Once you're done, the makefile should look like:

  # directory where AudioQueue.h is located
  AQDIR=$(HOME)/local/audioqueue
  # directory where MikMod is located
  MMDIR=$(HOME)/local/mikmod-iphone
  # comment the following line when the previous settings are OK for you
  #$(error configure AudioQueue and Mikmod location in the Makefile first)

Then, just build and install the app by typing:

  make
  scp -r HelloMikMod.app root@iphone:/Applications

Where iphone stands for the hostname or the IP of your iPhone. Note that you will need either curl or wget installed or your machine so that the build process is able to download the module played in this example app (fortunately, one of those should always be available on MacOS X or on your favorite Linux distro). For your convenience, the HelloMikMod.app directory is standalone: it contains the app itself linked statically to libmikmod, a launcher descriptor for Springboard and the module to play. For my own pleasure, the mod played is Stardust Memories by Jester / Sanity, my all time favorite Amiga mod (see the compo World of Commodore). This is only a simple example of how to use MikMod on iPhone. I've started implementing a more complex app that mimics the iPod interface for playing mods (Module DB, Screenshot of associated demos...). Now if only I could use Nectarine or Pouet.net DB to make some kind of systematic indexing available!! (sigh....)

MikMod library ported to iPhone

I've always been a big fan of old skool computer music, like chiptunes or demoscene music. Perhaps because they remind me the Good Old Days (tm) of my Amiga. Or perhaps for the same reason I like demoscene: real-time computer art! Because it's definitely cool, I've decided to port MikMod to the iPhone! We'll see later if it might be useful to someone else :) Compiling libmikmod Here are the steps to follow to build libmikmod for your iPhone or iPod Touch. First of all, make sure that you have the necessary header file from Apple, namely AudioQueue.h. This file is part of the AudioQueue framework, which is available in the MacOS X 10.5 SDK. This means that the official iPhone SDK is not required. Then, download the latest libmikmod-3.2.0-beta2 available on the MikMod homepage, as well as this patch for iPhone support. For simplicity, let's consider that both files will be downloaded in the same directory. Once you have them, extract the archive and apply the patch:

tar -zxf libmikmod-3.2.0-beta2.tar.gz
cd libmikmod-3.2.0-beta2
gunzip -cd ../iphone-drv-mikmod-3.2.0-beta2.patch.gz | patch -p1

Among other things, the patch modifies various Makefiles and the configure script, so we have to cleanly regenerate all the autotool-related files:

aclocal
automake
autoconf

Now let's set up the necessary environment variables to configure and build libmikmod. First, where to find the AudioQueue header and where to install libmikmod:

export AQDIR=$HOME/local/audioqueue
export MMDIR=$HOME/local/mikmod-iphone

Make sure you are using absolute paths for the variables above. Then, let's set up some compilation flags and name the tools we'll use from the iPhone toolchain:

export CFLAGS="-I$AQDIR -DAVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER="
export CPPFLAGS="$CFLAGS"
export LDFLAGS="-framework AudioToolbox"
export CC=arm-apple-darwin-gcc
export RANLIB=arm-apple-darwin-ranlib

Okay, now it's time to let configure do its job:

./configure --enable-iphone --host=arm-apple-darwin --disable-oss --disable-esd --prefix=$MMDIR

We're almost done! But there's still a little quirk that must be addressed. The project is configured to build shared libraries, which for some reason refuse to link with the version of the open-source iPhone toolchain I use. To overcome this problem, you just need to patch the generated libtool configuration. Knowing no clever means to do so, I propose something like:

sed -r -i 's/^(allow_undefined_flag.*)"/\1 -Wl,-read_only_relocs,suppress"/' libtool

Phew, now we're done! Just type:

make CFLAGS="$CFLAGS"
make install

And voila! a fresh libmikmod with support for your beloved iPhone or iPod Touch! Oh, by the way: the library comes in both static and dynamic flavor, so it should be pretty usable. Of course, the obligatory example will follow soon :P EDIT: the link to the patch was pointing to a plain file instead of a gzip one, fixed!