[libhid-discuss] Polling interrupt endpoint

[Peter Stuge]

Hi Rene,

Rene wrote:
> an interrupt ep has a polling time. AFAI understand it, this is used
> for calculating the required bandwidth (along with the ep size, this
> is done by driver code that is on a lower level in the usb stack)
> and off course for setting the polling time. However, when I "steal"
> the device from the kernel hid driver, do I have to see to it that
> this polling time is respected?

No, not in general. However, it depends on how the device is abusing
HID in order to use USB. (It's an extremely bad idea to use HID for
devices that should not use the kernel HID driver. It's like driving
a tractor on the side walk, when there is a street right next to it.)

The poll time is not so much a requirement for the USB driver (your
program) but for the USB host controller chip and the USB system
software (the kernel USB stack, always used, even if you detach the
HID kernel driver).

If the device has data available for you with this interval, and if
you do not want to lose any data, *then* you need to make sure to
read from the device using libhid frequently enough that the lower
level USB software and hardware will consistently perform a transfer
on every opportunity.


> Esp. for reading this is important.

I hope it's clearer from the above. Basically we can't say if it is
important or not, that depends on your particular device and the
assumptions made by the firmware engineers.


> For writing (updating the readings on a display) I can just send
> a package whenever there is something to be sent, being carefull to
> respect the polling time.

You can send any time. The lower level USB software and hardware will
handle scheduling for you.


> Another question is how pressing a button on the usb device might
> wake up the pc if it is suspended. AFAI can see, this is not possible.

So the device has buttons - does it identify itself as a HID
keyboard? If so, then I would strongly recommend interfacing with the
kernel input layer instead of trying to speak directly with the USB
device.

That said - remote resume is possible over USB, what is your question
again? While the PC is suspended, USB still has power. Not a lot, but
some.


> My last question is about the fact that there are two things taking place. 
> The display part (the display is on the device) of my program is reading 
> from a fifo, I could do that with a blocking read or with select with a 
> time-out, the last option allows me to poll the in ep at a regular interval 
> where the first one doesn't. The in ep needs to be read every 50 ms and 
> then something has to be put into another fifo. What would be the most 
> elegant solution to achieve this?

It also depends on how the device wants to be read. If you were using
libusb then one option would be to have two threads, or to use async
USB transfers. I'm not sure you can, with libhid. (Though, if you're
using libhid on top of libusb-compat-0.1 on top of libusb-1.0, then
it would probably be fine anyway.)


> Another option would be to have a select with just a timeout, when it times 
> out (10ms) it polls the in ep every fifth time (polling time for the out ep 
> is 10 ms, for in ep 50 ms)

Please don't mix these timings. Any timeout involved in userspace
calls into the kernel have no guaranteed latency and can always be
longer than the specified time, while the polling time is an
absolutely strict upper limit for the hardware. The polling is done
in the host controller hardware.


> I am not only new to usb and libhid but also rather new to Linux and
> would very much like to hear Your opinions about this or perhaps You
> have a completely different idea about how I would best design this.

Please say more about the process of reading data from the device.


//Peter