Hi On Fri, May 17, 2013 at 1:47 PM, Nestor Lopez Casado <nlopezcasad@xxxxxxxxxxxx> 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 -- 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
