On Sun, Nov 2, 2014 at 10:13 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Sun, Nov 2, 2014 at 12:47 PM, Tom Gundersen <teg@xxxxxxx> wrote: >> Hi Andy, >> >> On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> I want to get U2F (universal second factor, sometimes called "security >>> key" or even "gnubby") working on Linux. U2F tokens are HID devices >>> that speak a custom protocol. The intent is that user code will speak >>> to then using something like HIDAPI. >>> >>> The trick is that, for HIDAPI to work, something needs to recognize >>> these devices and get udev to set appropriate device permissions. >>> >>> My question is: how should this be done? The official way to >>> enumerate U2F devices is to look for a HID usage page 0xf1d0 >>> containing usage 0x1. >>> >>> Options include: >>> >>> - A builtin udev helper that reads the sysfs report_descriptor for >>> hid or hidraw devices and sets attributes accordingly (either >>> ID_SECURITY_TOKEN or something more general). >> >> I don't think we should have such special-purpose logic in the udev core. >> >> [...] >> >>> - 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. >> >> This makes the most sense to me. We could put this logic (adapting the >> patch you posted) in src/udev/udev-builtin-usb_id.c. > > How would that work? Can't a USB device have more than one HID class > device under it? I could imagine a future U2F keyboard that has a HID > class device for the keyboard part and another one for U2F. Right, a separate built-in makes more sense then. Cheers, Tom -- 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
