HIDden History

  • What
  • How
  • History
  • Download

  • I have a Logitech Internet Navigator Keyboard (USB) which has 19 buttons and a scroll wheel in addition to the standard 104 keys. Some buttons worked out of the box, without any special drivers, namely the volume up/down and mute buttons, the restart/sleep button, and the scroll wheel. Some have odd effects: the 'Webcam' button causes a control-click, and 'Messenger/SMS' button is a normal click.

    The others have no effect without the Logitech Control Center, and therein lies the problem. At some point, LCC started causing kernel panics on my machines (G5 iMac and MacBook.) I searched for a replacement, something similar to USBOverdrive (but for keyboards instead of mice.) I found some applications which work to re-map some modifier keys (mainly for Powerbook users) such as fKeys, uControl, and DoubleCommand. Those also worked when using a 'PC' USB keyboard, but in Mac OS X Tiger, the Keyboard and Mouse System Preference Pane allows remapping the Alt key to Command (apple) key. Sadly, in the end, I found nothing that allowed me to map or access those 'extra' keys my keyboard has.

    At about this time, I noticed a good price on for a Kensington Wireless Desktop for Mac on dealmac.com. This keyboard also has a bunch of special keys and a scroll wheel. While included Kensington drivers did not cause kernel panics (pretty low bar for good software, eh?), only 3 of the special keys could be customized. The rest were tied to whatever Kensington thought was appropriate (including a key that launches the Calculator application). Also, there's seems to be a slight delay between mouse or keyboard actions and the result on the computer, but this may be due to the wireless connection and not the Kensington driver.

    So I began to investigate writing my own 'driver' for these keyboards. First, I looked at the source code for fKeys and DoubleCommand. I found that these work by intercepting a keyboard event and altering some for its data before passing it along to the rest of the system. Unfortunately, the interception takes place after raw USB "key press" events have been translated to AppleDesktopBus equivalents (see Cosmo_USB2ADB.c). And while there are ADB codes for things like volume-up and shutdown, there are not ADB codes for all the elements on my keyboard, much less for every one listed in the USB HID specification. (Oddly, in the header file "ev_keymap.h", there are definitions for keys to play, rewind, next, etc., and although these keys on my keyboard are correctly identified according to the USB specifications, they do not cause iTunes to respond as one would hope.)

    The only way I could think of to intercept the events earlier in the system event chain was to modify and recompile the IOHIDConsumer plug-in, but I (and others, I have noticed) am unable to compile IOHIDFamily for reasons I cannot determine.

    The other aspect of fKeys and DoubleCommand is that they are kernel extensions (KEXT). Given the trouble with LCC which started me on this project, I was thinking of trying an Application. I was lead to HID_examples from Apple, and I started writing a user-space program to do my bidding when using the extra keys on my Keyboards.

    When the program had progressed to the point that I could read the keyboard's characteristics, I was surprised to find a lot more controls (i.e. buttons) specified than I could physically find on the keyboard. And when I could detect events caused by the extra keyboard buttons, I started thinking about an old USB joystick I have that never did quite what I hoped for game play. My thoughts led me to envision a program which could identify events from individual devices, including multiple keyboards, and take a specified arbitrary action.

    Other Software | email: AaronProman at Yahoo