On Fri, Oct 14, 2022 at 01:18:55PM +0200, Thilo Roerig wrote: > > On Wed, Oct 12, 2022 at 04:35:52PM +0200, Thilo Rörig wrote: > > > Dear maintainer, dear community, > > > > > > I'm new to looking into the linux kernel, but am hoping that this is the > > > right spot to address my problem. > > > Otherwise I would be very thankful, if you could point me in the right > > > direction. > > > > > > I have a problem with a custom usb device on a raspberry pi running a > > > buildroot 64bit linux with a v5.19.14 kernel. > > > I ran into a problem reading data from a custom usb hid device using > > > interrupt transfers. I'm using > > > the python hidapi library (https://pypi.org/project/hidapi/) with the > > > libusb backend. After sending > > > a custom command to the device, the driver changes from usbhid to usbfs. > > > The device starts sending > > > reports of size 1023 bytes to endpoint 0x83. `usb-devices` yields the > > > following output: > > > > USB devices do not "send" anything, they require a request from the host > > to be able to transfer any data. So you have to ask the device "do you > > have any data?" before it can respond with anything. > > > > So just wait, don't ask the device if you are not ready for the data to > > be recieved, do not allow the device to continue to flood the data to > > you if you can not recieve it all. > > Thank you for pointing this out. I looked into the implementation of the hidapi > library. The library immediately starts submitting transfer when opening the > device. So to get a better grip on the issue, I'm now using libusb and in > this case I only get the reports, when I'm asking for it. > > > > T: Bus=3D01 Lev=3D03 Prnt=3D13 Port=3D00 Cnt=3D01 Dev#=3D 14 Spd=3D480 MxC= > > > h=3D 0 > > > D: Ver=3D 2.00 Cls=3D00(>ifc ) Sub=3D00 Prot=3D00 MxPS=3D64 #Cfgs=3D 1 > > > C: #Ifs=3D 1 Cfg#=3D 1 Atr=3D80 MxPwr=3D500mA > > > I: If#=3D 0 Alt=3D 0 #EPs=3D 1 Cls=3D03(HID ) Sub=3D00 Prot=3D00 Driver= > > > =3Dusbfs > > > E: Ad=3D83(I) Atr=3D03(Int.) MxPS=3D1024 Ivl=3D125us > > > > > > The reports are numbered by an increasing report id and are available via > > > interrupt transfer approx. every > > > 230 microseconds (1.85 microframes). The device does not retain any old > > > reports. > > > > So is the buffer in the device overflowing because the host is not > > asking for enough data from it, or is the data overflowing in the host > > because you are not reading the buffers fast enough? > > The buffer on the device does not buffer reports, that are as old as the > reports I am receiving via libusb. Interestingly, the speed that I can receive > the reports in userspace increases, when the wrong pattern starts to occur. > Initially, I receive ~4350 reports per second (with correct report id and > increasing order), but once the wrong pattern occurs, the speed goes up to > ~7650 reports per second, which is approx. 1 microframe. Without having found > any reference in the code, the pattern in the data looks as if some dequeue > pointer is "overtaking" the enqueue pointer in a ring buffer - but this is just > a wild guess. It would maybe explain the pattern in the data and maybe also the > speedup once the ring buffer is not preventing the dequeue from reading once > the enqueue pointer is reached. Are you sure that the firmware in the device itself is not just broken when you ramp up the speed? It is the thing that is filling the buffers to the host, when it has it ready, so it is the thing that is in control of how fast it responds. If all works well at slower speeds, try just doing that and not letting the device itself work too hard. What does other operating systems do with this device, how do they control it? With a in-kernel driver or with userspace code that takes a long time between requests? thanks, greg k-h
