Re: HID vendor access from user space

Hi

On Fri, May 17, 2013 at 1:47 PM, Nestor Lopez Casado
[off-list ref] wrote:

Hi,

In today's linux HID subsystem, a HID device can be accessed for
control and configuration via dev/hidraw, via a hid-specific driver,
as well as /dev/input (setting leds on a kbd for instance)

Some HID devices share multiple functionality in the same HID
interface, think of a keyboard with a touchpad and a vendor specific
collection for configuration, special status, etc.

For such device, there will be one hidraw node, and hid-input will
take care of parsing the keyboard/mouse collections into the proper
input objects.

The vendor collection will be ignored.

If a user wants to configure/control the device there are two choices,
either write a hid-specific driver to deal with the vendor specific
collection, or open the corresponding /hidraw node from userspace.

But a hidraw node that carries system input data requires root priviledges.

I'm interested in hearing your opinions on how to add the capability
for a normal user process to control/configure a HID device via
reports exchanged with a vendor collection.

I have one proposal, which is to create, say  "/dev/hidvendorX", nodes
for all top level HID collections which are today ignored by hid-input
and/or other subsystems.

These nodes would not require root priviledge by default and thus,
users could control/reconfigure their devices from a standard
application while keeping the "standard" input functionality intact.

Why not write a kernel driver? We have a pretty nice infrastructure
for all this.

If it's a license-issue, I recommend using udev rules to change
permissions on the requested devices directly during setup. You can
then use hidraw.
It would also help if you could describe the driver design. Do you run
it as daemon and feed data back into the kernel? Or do you forward it
to the xserver? Or what kind of setup do you have? For instance, a
library design would require dynamic permission setup, while a
daemon-design would allow static file-system permissions.
Furthermore, is it still an input driver? Or do you tunnel non-input
data via HID?

Regards
David