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. Cheers, Nestor -- 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
