On Sat, 15 Sep 2018, Alistair Buxton wrote: > When creating a gadget driver in userspace, how do I receive an interrupt or > signal when the host sends a request to an endpoint so that I can handle it? > > Take for example making a HID gadget. There are three ways to do this: > > 1. Using g_hid. > > Under this method you get a character device like /dev/hidg0. You open it and > then write HID reports into it. There is no synchronization. It will accept > reports as fast as you can write them. I don't know how g_hid works internally. If you write multiple reports to the file before the host asks for anything, does the gadget driver queue all of them for sending? Or only the most recent one? In the latter case you would have nothing to worry about. > If the host does not ask the device > for a report, then presumably the reports you write are just dropped, meaning > input is lost if you write reports faster than the host polls - and you have no > way of knowing how fast the host polls as the endpoint bInterval is a minimum > value only and the host is free to poll slower than that. Wrong -- bInterval is a maximum value only and the host is free to poll more quickly. > 2. Using gadgetfs or functionfs. > > Set up for these methods is slightly different but under both you end up opening > endpoints as files - usually ep1in and ep2out for a HID device. You then > write report descriptors into ep1in. This operation blocks until the host > polls for a report, which could be several hours later. This means input is > out of date when the host receives it. You can force an operation to complete unsuccessfully (i.e., before the host has polled) by sending a signal to the thread doing the I/O. > The endpoint file descriptors are not compatible with select() meaning you can't > tell if write() will block without calling it. You can use KAIO to implement > non-blocking write by select() on an event_fd, but in order for this to work you > have to write some data into the endpoint, and then the event_fd will signal > after the host has received it. This means KAIO does not solve the stale > input problem. > > Note that under gadgetfs and functionfs ep0 does support select() but the other > endpoints do not. You submit a report. When/if it becomes stale, from a separate thread you interrupt the I/O operation. Then submit a report containing the updated data and repeat. It's a little less elegant than async I/O but it should work. > So it seems like under method 1. I have no way of knowing when the host asks > for data, and under method 2. I can only be informed that the host > asked for data > *after* the data has been sent, at which point it is too late. > > So am I missing something here or is this just not possible from userspace? It is not possible to know when the host has asked for data until after the data has been sent. This is true for kernel drivers as well as for userspace drivers. Alan Stern
