Linux keymapping: USBHOTKEY update

[windexlight]

Hello all,

I've spent a little time extending Lars Krueger's USBHOTKEY to
accomplish the same things that I used to do with AutoHotKey in
Windows. I use the AlphaGrip for gaming, and remap the T/N keys to be
L/R mouse buttons, since the AG5's existing mouse buttons are mutually
exclusive with the CYKL cluster that serves as my directional pad.

I spent a while experimenting with various solutions in Linux for
remapping keyboard keys to act as mouse buttons, and could not find
anything that worked as I needed. Xkb's MouseKeys looked promising,
but for some reason would lock out all other keypresses while any
"fake" mouse button was down, making it totally useless for gaming. I
finally settled on USBHOTKEY as the most promising solution, and set
to work adding some functionality to make it better suit me. The
overall gist of the changes are:

-Mapping keys to mouse buttons is now supported.
-Ruby scripts can be much shorter and to the point.

Here's a little more detail:

-Made some changes to the Autotools input scripts as well as a few
changes to Ruby-specific code to get the project to compile against
the latest Ruby (1.9). I'm no expert on Autotools or the GNU make
system, so I don't guarantee that I did everything properly. But it
compiles on my system.

-Added some extra C functions (callable from Ruby) to generate mouse
button events.

-Added a C function (callable from Ruby) to return the Xkb symcode
mapped to a given USB keycode under the current keymap. This allows
the Ruby script to simply "pass through" any keypresses that it wishes
to, eliminating the need for maintaining entire keymap tables in
script.

-Added some checking in C before calling into Ruby methods that the
method actually exists in the script. This means not every method
needs to be defined in every script (scripts can choose to implement
only those that make sense).

-Added extra C functions (callable from Ruby) as well as Ruby methods
(callable from C) to allow handling of up and down events using the
same code. In other words, the up/down-ness of the event is passed as
an argument to an event handler function instead of separate up and
down handlers being needed.

-Added a C function (callable from Ruby) to check if a given USB
keycode was reported as down in the last USB packet. This allows
persistent determination of key state from anywhere in the Ruby
script.

-Added a call into libusb to reset the USB device when the program is
cleaning up before exit. This allows the OS to regain control of the
device automatically (in other words, your keyboard doesn't stop
working if the program exits).

-Spent some time setting up a UDEV rules file and shell script to
allow auto-execution when a device is plugged in (very convenient).
An example of this is included with the project source.

------------

The usefulness here is probably so limited that no one but me will
ever have any need for it (how many people are there out there who
desperately want to use an AG5 on Linux to play games?). Still, I set
up a Googe Code project for some version control, and locked myself
into renaming the project at the time (it wanted a name, and I just
thought up something on the spot - haven't figured out if Google will
let me change it, or potentially port/merge the SVN history into a
different project). I put together a tarball for download in case
anyone might find this useful. Just like USBHOTKEY, the setup might
not be 100% straightforward, and you'll need to be comfortable
compiling from source in Linux. I'm happy to answer questions where I
can, but I don't have the time or knowledge to make everything work
for everybody all the time (or else I would). Anyway, the project is
here:

http://code.google.com/p/usb-remap/

[Mike Willner]

Looks like you did a lot of work on this.

Thank you for sharing!

Mike

---

From: windexlight <winde...@gmail.com>
To: alphagrip <alph...@googlegroups.com>
Sent: Sunday, April 1, 2012 3:25 AM
Subject: [alphagrip] Linux keymapping: USBHOTKEY update

--
You received this message because you are subscribed to the Google Groups "alphagrip" group.
To post to this group, send email to alph...@googlegroups.com.
To unsubscribe from this group, send email to alphagrip+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/alphagrip?hl=en.