On Fri, Nov 19, 2021 at 05:19:15PM -0500, David Niklas wrote: > On Wed, 17 Nov 2021 12:08:17 -0500 > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Nov 17, 2021 at 12:23:59AM -0500, David Niklas wrote: > > > I can also try and use SnoopyPro and busdog if the output is > > > undesirable. USBPcap spits out a pcap file which can be analyzed by > > > wireshark using dissectors -- somehow (I really should practice using > > > wireshark.) > > > > Wireshark on my system has no trouble reading your pcap file. > > Misunderstanding then. I was thinking in terms of the USBPcap docs. I was > saying a dissector would need to be written. I'm glad it worked for you. > https://desowin.org/usbpcap/dissectors.html > "Writing USB class dissector" Evidently wireshark already has built-in dissectors for standard USB communications. > > This will cause the kernel to ask for 1060 bytes rather than 996. > > (It's also potentially dangerous, because it asks for 1060 bytes to be > > stored into a 996-byte buffer; if the device sends more data than > > expected then the excess will be written beyond the end of the buffer.) > > > > Please send a usbmon trace showing what happens with this patch > > applied. And you might as well put the Set-Idle request back in, > > because now we know Windows does send that request. > > > <snip> > > It still disconnects. I've attached the usbmon output. The trace clearly shows the request for a 1060-byte HID report descriptor and the device sending back a 996-byte reply, just like in Windows. And yet the disconnect still occurs. The only remaining difference is the transfer of string descriptors. You can prevent Linux from asking for them by editing usb_string() in drivers/usb/core/message.c. Just make the function return -ENOMEM unconditionally. That will stop the requests from going out. Alan Stern
