Alright, here's an 'official' release for my tilt2 keymap stuff

http://www.happyassassin.net/extras/tilt2/rootfs.img

Instructions are the same as before:

1 - grab that and replace the rootfs.img in the root of your SD card with it.
2 - edit the file STARTUP.TXT in the root of your SD card. on the long line with 'cmdline' in it, add this to the parameters:

physkeyboard=tilt2

it should wind up looking something like this:

set cmdline "lcd.density=240 msmts_calib=0x9f.0x39a.0x35c.0x78 clock-7x00.a11=500 msmvkeyb_toggle=off physkeyboard=tilt2 pmem.extra=1 gsensor_axis=-1,-2,3 force_cdma=1"

that's all you need. Most keys and their alternate functions should work, either with the kernel from reefermattness's current CAB build (see my .sig) or kernel htc-msm-android@20100201_185127 or later from http://glemsom.anapnea.net/android/htc-msm-android. 'OK' is mapped to Enter and the 'home' icon key is mapped to Home. Neither of these is that useful as there's an Enter key and the power button acts as a home button, but I couldn't think what else to do with them. Known issues:

1) the d-pad mapping seems erratic - I'm not quite sure exactly what the buttons are *supposed* to do, and what they *currently* do, and the up and left buttons currently do the same thing and this needs fixing at the kernel level.

2) PTT button currently does exactly the same as the 'e' key

3) the Fn mappings for the bottom row keys aren't implemented. I can't find a way to map alternate keys - what you get with the Fn modifier - to the special Android keycodes you'd need to use to make these open the contacts or calendar or browser or whatever. It may not even be possible. But I don't think it's a deal-breaker, it's easy enough to navigate around in an Android fashion.

If anyone can think of anything else useful that isn't mapped that they think should be, do make suggestions and I'll let you know if I can do it.

For anyone who's interested, the source files are available from the same place:

http://www.happyassassin.net/extras/tilt2

All these files wind up within the rootfs.img . To mess with them, you have to make rootfs.img accessible (on Linux you can just loop mount it). The 'init' file goes into the top level of rootfs.img; it's the script that sets up the root filesystem early in the Android boot. It contains a little chunk at the end which lets you set different keymaps via the 'physkeyboard' kernel parameter; as you can see by looking at it, it just greps cmdline for the parameter and copies different files into place as /etc/keymaps/microp-keypad.kl , /etc/keymaps/microp-keypad.kcm.bin and /etc/keymaps/raph_navi_pad.kl depending on which value it finds for the parameter. I added the 'tilt2' value to this little lump and told it to copy the tilt2 files into place when tilt2 is specified.

The .kl and .kcm.bin files go into init.etc/keymaps . They're what get copied into place by the init script, and they contain the actual key mappings. tilt2_microp-keypad.kl contains the basic scancode -> keycode mappings for the keyboard (and also for the menu, back and call buttons: they're handled by the keyboard driver), and tilt2_microp-navi_pad.kl contains the scancode -> keycode mappings for the handful of buttons handled by the gpio driver. These two files tell Android which scancodes (the events emitted by the input drivers when you actually press the buttons) map to which Android keycodes. What these keycodes do is defined elsewhere in Android.

The tilt2_microp-keypad.kcm.bin file contains definitions of what character to emit when using the 'modified' key layouts. Android has several of these, including the most important one for our purposes, which is the layout you get when the Fn key is active. So this file tells Android what to do with the Fn+key combinations. It's not directly editable, without a hex editor - it's compiled from the tilt2_microp-keypad.kcm file by a tool that the Android docs refer to as 'makekcharmap' but which is actually called 'kcm' and which you can only get as part of the complete Android source tree. MrPippy very kindly sent me a compiled version from his system to use. The .kcm file just lists actual characters (or keysym codes) that should be produced when the modified combinations are triggered - not keycodes.

Hope this is useful to everyone! I'll send this to the XDAndroid maintainers so hopefully it will be taken upstream and Matt can do a new CAB build with the appropriate kernel parameter built in and it will work entirely out of the CAB in future.