On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina <jkosina@xxxxxxx> wrote: >> 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. > > Hmm. Would this be like a filter on hidraw actions? > > How would udev distinguish these special hidraw devices from normal > hidraw devices? > > Also, for U2F, this could be a little awkward. There's some crazy > fragmentation stuff to allow a U2F request to be split across HID > requests, and I think a kernel driver would much rather get the > original unfragmented application request. > I started writing a driver for this. I got enumeration working. I assume I should create a "u2f" device class, and then... ? Where am I supposed to get my character device from? Do I register my own chrdev major? Do I use misc? Is there some input thing I'm supposed to use? Thanks, Andy > --Andy > >> >>> > 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 > > > > -- > Andy Lutomirski > AMA Capital Management, LLC -- Andy Lutomirski AMA Capital Management, LLC -- 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
