Re: Overriding default behaviors for USB HID 'keyboard' device?

[Zephaniah E. H. <wa...@ba...>]

On Thu, Jan 01, 2004 at 12:25:40PM -0500, Paul Bohme wrote:
>   Happy new year, hopefully it finds everyone safe (with only mild
> hangovers.. ;-)
>=20
>   I've recently acquired a Belkin Nostromo n52 "SpeedPad" [1] - a USB gam=
ing
> device with a number of keys and a form factor handy for various games.=
=20
> It's ostensibly a successor to the Nostromo n50 [2] for which I've helped
> cook up some userland utilities [3] to configure the n50 and convert butt=
on
> hits to user-configurable keystrokes.
>=20
>   Despite the external similarities the devices are completely different
> internally.  The older n50 doesn't even present itself as any specific ty=
pe
> of HID, and so is automatically handled through the generic event interfa=
ce.
>  This is what my userland tools use, and it's worked well enough so far.=
=20
>=20
>   The newer n52 however presents two interfaces: a USB keyboard and USB
> mouse (it has a wheel similar to a mouse wheel, so is a sharply limited
> 'mouse' device.)  Upon connection, the USB HID subsystem identifies the
> n52 properly and sets up its mouse and keyboard interfaces, redirecting
> button presses on the device into keystrokes indistinguishable from other
> keyboard activity. This prevents (I think?) remapping these keys without
> torching the entire system keyboard setup.
>=20
>   My question is how to approach this?  I'd like to identify this device
> specifically and prevent the association with keyboard/mouse drivers,
> probably just pumping everything out through evdev for simplicity.  I'm
> RTFMing like a madman, but don't want to have to write up yet-another-dri=
ver
> if I can avoid it (but am willing if it's deemed necessary.)  The absolute
> ideal would be to be able to use the same userland tools with both the n50
> and n52, so homogenizing the interfaces would be advantageous.


You will not be able to do this before the fact, however the evdev code
in late 2.5.x kernels and 2.6.x kernels supports a 'grabbing' interface,
an application opening the /dev/input/event<n> belonging to the device
can do a EVIOCGRAB ioctl on the device, causing all future events to be
reported to that application only.

This grabbing goes away when the application gives another EVIOCGRAB
ioctl with a false argument, or when the application closes.

If need be I can provide a simple example application.

(I do not know if the grabbing interface is supported by the 2.4.x
kernels, I never submitted a patch for it, but someone else may have
backported it.)

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

=2E..and the burnt fool's bandaged finger goes wobbling back to the fire.
  -- The Gods of the Copybook Headings, by Kippling.