On Mon, 3 Nov 2014, David Herrmann wrote: > > Agreed, mostly. My only real concern is that this could be annoying > > for the userspace developers who will need to target Linux and HIDAPI > > separately. Admittedly the Linux support will be trivial. > > I see. I'll not stop you from using hidraw, I'd just not recommend it. > Especially for security stuff I dislike exposing the whole HID device > writable. But yeah, I guess you got my point. Alright, I am basically thinking loudly now, but how about we allow HID drivers that would override default hidraw interface? I am very well aware of the fact that this could be opening a can of worms, so we'll have to make it very restrictive. How about, let's say, we allow HID drivers to provide custom hidraw interface (completely overriding the one that HID core would normally create) only for cases such as: - the intent is to expose only certain parts of a combined device - the intent is to introduce some level of access control I.e. still no interference of kernel with data parsing allowed. > > I can give the driver a try. It'll actually be simpler than the spec > > makes it out, since a real kernel driver will have no need to > > arbitrate with itself. > > I'll gladly review any custom HID drivers. Feel free to put me on CC > when sending to linux-input. There's also a lot of examples in > drivers/hid/ in case you need a head-start (especially if you need the > raw_event callback). Same here, of course. Please always CC me in parallel to sending to linux-input@ to make sure that the patch doesn't fall in between cracks. Thanks, -- Jiri Kosina SUSE Labs -- 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
