On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxx> wrote: > On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina <jkosina@xxxxxxx> wrote: >> On Sun, 2 Nov 2014, Jiri Kosina wrote: >> >>> 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? >> >> Just to make myself clear here -- this is basically alternative to your >> 1st option, but for cases where you want to make yourself independent on >> sysfs existence (I don't what is the craziness level of setups you are >> considering). >> > > I am a little bit concerned with the user space retrieving the > descriptor, parsing it and then deciding how to set the permissions. > It's not that it is super complex, but it will duplicate the parsing > we already do in the kernel. Wacom tried to do that in their usb > driver, and they never managed to fully implement one. > > I think the HID_GROUP solution is super trivial: > - add a match on the U2F input report and set the group to > HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) > - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). > > Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? --Andy > > Also, if we want to further extend the kernel API for U2F, the group > will already be in place. > > Cheers, > Benjamin -- 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
