On Fri, Dec 12, 2014 at 9:32 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > Hi > > On Fri, Dec 12, 2014 at 6:25 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Fri, Dec 12, 2014 at 9:21 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: >>> Hi >>> >>> On Fri, Dec 12, 2014 at 6:18 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>> On Dec 12, 2014 3:05 AM, "David Herrmann" <dh.herrmann@xxxxxxxxx> wrote: >>>>> >>>>> So far, the solution is to use hid_device_io_start() and >>>>> hid_device_io_stop() in ->probe(). It's a hack to allow I/O during >>>>> ->probe(). Maybe your idea is the way to go, but unless someone >>>>> implements it, we're stuck with the current code. >>>> >>>> That should work. >>>> >>>> For normal HID drivers (those that don't start IO from probe), what >>>> happens if userspace starts IO before probe returns? Does the driver >>>> code prevent that somehow? >>> >>> It's only the async hid intr channel that is affected by this. >>> User-space cannot trigger any outgoing I/O on the intr channel. Only >>> the synchronous ctrl channel via SET_REPORT can be triggered, but due >>> to the synchronous nature we always allow I/O on it. >>> >> >> I understand exactly one HID device, and that's U2F. In U2F, >> userspace will (directly or indirectly) use SET_REPORT, and the device >> responds immediately (ish) using the async intr channel. > > How does user-space issue SET_REPORT? Via hidraw? hidraw shouldn't be > used for anything but debugging right now. Using whatever character device I end up using. That is, totally undecided at this point. > > The normal hid drivers are managed through hid-input.c, which > registers the input devices and syncs it up with its ->probe() > function. Most of the hid-xyz.c drivers are just quirks for > hid-input.c. > > If you now invent your own layer on top, you usually don't want > hid-input.c. Instead, you register your own user-space API (for > instance via cdev_add(), or misc-devices). In those cases, you > register your devices from within ->probe() so it is up to you to > enable I/O before doing this. Yeah, I need to do that and turn off the hid-input stuff. This thing isn't really an input device. > > I have no idea what user-space API you intend to use. Unfortunately, I > don't even know what kind of API U2F actually provides, so I cannot > even point you into the right direction. Sorry. > It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard is amazingly vague), that means that the application sends a short (<64kB) binary request to the device (with a type, two "parameters", and a payload), and the device answers with exactly one reply packet that has two bytes of status and a payload. These requests and replies are fragmented into multiple HID reports. At a higher level, there are three defined request types, one for ping, one for key generation, and one for authentication. There are also a couple of useful vendor-specific interfaces. The device has a button, although the way to detect the state of the button is to poll, using the aforementioned packet interface. I kid you not. (This isn't quite as poorly designed as it sounds -- there are operations that consume the most recent button press and can't be repeated without another press. But you still have to keep resubmitting the request until the user presses the button.) --Andy > (btw., Documentation/hid/hid-transport.txt is an overview of how HID > transport layers work) > > Thanks > David -- 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
