hidraw with exclusive access ?

[Timo Teras <timo.teras@iki.fi>]

Hi,

I'm trying to write userland driver for an input controller -
basically a macrokeyboard: some keys act like regular keys, and some
are not really described in the descriptor so it needs custom parser.
It has also extra commands to set/blink LEDs, etc.

I'd need exclusive access to it. Mainly because some of the keys emit
normal looking presses and I would not like them to be fed into the
input system when my application is running. As side effect I get also
in dmesg errors like "input input16: event field not found" due to this.

Now this is of course doable with libusb, not using kernel hid
subsystem, and reimplementing the relevant hid bits (or using some of
the existing hid libraries doing this). But this sounds a bit overkill
and hidraw seems to be exactly for this kind of use case.

The only problem is that I was not able to find a 'grab device' type of
functionality in hidraw. Basically equivalent of EVIOCGRAB in input
subsystem. Something that would make sure the reports come only to
hidraw device.

Would it make sense to implement something like this for hidraw?

As an alternative I think we could have hid-rawonly driver, that would
by default bind to nothing. And when bound, would connect to the hid
device with HID_CONNECT_HIDRAW flag only. I could then in userland
rebind the device from hid-generic to hid-rawonly.

Or finally, to implement a full kernel side driver it. But I'd
rather not go there. Especially since the device has multiple leds, and
the input system allows only limited leds. (The leds could be exported
as led devices, but then I'd need more userland logic to figure out
which led devices map to which input device.)

Thoughts?

Thanks,
Timo