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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
