libusb_interrupt_transfer to EP_IN stalls
Closed this issue · 6 comments
ran
22:38:03 mllilek mllilek-debian wii-u-gc-adapter $ sudo ./wii-u-gc-adapter
adapter 0x0x556b8b8787d0 connected
error in kernel logs
Feb 23 22:38:05 mllilek-debian kernel: [ 3607.848069] usb 1-1.2: usbfs: process 5270 (wii-u-gc-adapte) did not claim interface 0 before use
no input registered
22:39:25 mllilek mllilek-debian wii-u-gc-adapter $ sudo ls /dev/input/by-id
usb-04d9_USB-HID_Keyboard-event-if02
usb-04d9_USB-HID_Keyboard-event-kbd
usb-04d9_USB-HID_Keyboard-if02-event-kbd
usb-04d9_USB-HID_Keyboard-if02-event-mouse
usb-04d9_USB-HID_Keyboard-if02-mouse
usb-Logitech_G203_Prodigy_Gaming_Mouse_057138493730-event-if01
usb-Logitech_G203_Prodigy_Gaming_Mouse_057138493730-event-mouse
usb-Logitech_G203_Prodigy_Gaming_Mouse_057138493730-if01-event-kbd
usb-Logitech_G203_Prodigy_Gaming_Mouse_057138493730-mouse
uinput version information
22:40:20 mllilek mllilek-debian wii-u-gc-adapter $ sudo modinfo uinput
filename: /lib/modules/5.4.0-3-amd64/kernel/drivers/input/misc/uinput.ko
libusb info
22:43:09 mllilek mllilek-debian wii-u-gc-adapter $ sudo apt search libusb | grep installed
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libhidapi-libusb0/testing,now 0.9.0+dfsg-1 amd64 [installed,automatic]
libusb-0.1-4/testing,now 2:0.1.12-32 amd64 [installed,automatic]
libusb-1.0-0/testing,now 2:1.0.23-2 amd64 [installed,automatic]
libusb-1.0-0-dev/testing,now 2:1.0.23-2 amd64 [installed]
libusb-1.0-doc/testing,testing,now 2:1.0.23-2 all [installed,automatic]
libusb-dev/testing,now 2:0.1.12-32 amd64 [installed]
libusbmuxd6/testing,now 2.0.1-2 amd64 [installed,automatic]
I think its something about libusb_interrupt_transfer suspending the adapter_thread waiting on a response it never gets
fprintf(stderr, "huh1");
int transfer_ret = libusb_interrupt_transfer(a->handle, EP_IN, payload, sizeof(payload), &size, 0);
fprintf(stderr, "huh2");
23:14:16 mllilek mllilek-debian wii-u-gc-adapter $ sudo ./wii-u-gc-adapter
adapter 0x0x556a9a0457d0 connected
adapter_thread a->quitting 0
huh1
When i set the timeout to some dummy value (1000 * 10) ms I can see that the request times out
I think its something to do with my adapter, which nonstandard. Serial number HS-WU025.
Based on https://gbatemp.net/threads/wii-u-gamecube-adapter-reverse-engineering-cont.388169/
I see that after writing 0x13 to EP_OUT you should be able to poll for the controller status from EP_IN. This doesn't seem to work in my case: it accepts the knock but doesn't respect it
Will compare the HID Device Descriptor with the doc above ^ and see how they differ
Descriptor retrieved by doing
lsusb -v -d 057e:0337
report descriptor: https://pastebin.com/Z4zqhzzW
Here's my interpretation of the above report descriptor:
x11
Report 8 x 5
Output = 0
EP_OUT
0x21
Report 8 x 37
Input = 0
EP_IN
0x12
Report 8 x 1
Output = 0
EP_OUT
0x22
Report 8 x 25
Input = 0
EP_IN
0x13
Report 8 x 1
Output = 0
EP_OUT
0x23
Report 8 x 2
Input = 0
EP_IN
0x14
Report 8 x 1
Output = 0
EP_OUT
0x24
Report 8 x 2
Input = 0
EP_IN
0x15
Report 8 x 1
Output = 0
EP_OUT
0x25
Report 8 x 2
Input = 0
EP_IN
It might just be a bad adapter: regardless of what input I send out (0x1[2-5]) I time out when reading from EP_IN. Testing again with the mayflash adapter which I've read works fine, will update in a couple days
mayflash adapter works fine.
for reference, this is the adapter I bought. Avoid this:
https://www.amazon.com/gp/product/B07F36FWMQ/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
more tags: Cloudream, pdobq