On Sun, 2 Nov 2014, Andy Lutomirski wrote: > > Hmmm ... please keep in mind that report_descriptor is actually in > > debugfs, so it's a bit questionable whether you can rely on it being > > present on well-defined location on all systems. > > Huh? I have > /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0013/report_descriptor > on my system. Brainfart on my side. We have 'rdesc' and 'events' in debugfs sice a long time, but then 'report_descriptor' has been added as a proper sysfs attribute some time around 3.0. > >> - HID core code in the kernel to add > >> HID_USAGES=f1d00001:lots:of:other:things to the uevent (or udev code > >> to do the same). This might end up producing a rather long string or > >> some devices. > > > > We have been thinking about this quite a lot in the past, and decided to > > postpone this until there is a very good reason for it to happen. > > I'm not sure that U2F counts as a very good reason. It might well be the justifying reason. I'd first like to see what other options we have though. > >> - An actual kernel driver for U2F devices using the hid group > >> mechanism for enumeration. This seems overcomplicated. > > > > Hmmm ... why do you think so? I believe it actually should be really > > super-trivial. > > The HID group part is trivial, but what interface would the driver > expose? I don't think that a udev rule for hidraw matching the > modalias makes any sense, and, if it were a real driver, what > interface would it expose? Most cross-platform userspace code for U2F > is likely to use HIDAPI. > > Admittedly, a U2F driver in the kernel would be slightly nicer from a > multiplexing standpoint than hidraw. Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? 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
