-
-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Void Wired Support #6
Comments
Sorry, for the late reply. |
This was outputted along with the regular error message |
Yes, this definitely means a packet type is incorrect. |
Didn't think that the protocol would be completely different. |
Error Output:
|
Can you post the output of |
|
That's weird, your libusb doesn't show the endpoints I see on the wireshark log. But I also saw other packets, it's basically a wild guess, but try to replace the send_sidetone_void_wired function with this:
|
|
I'm kind of clueless, I transfer it exactly as in the wireshark logs. It's like I'm looking at the wrong device. You could try to redo the capture and upload it again. After playing around with the slider do for 10 seconds or so nothing before stopping the capture, so I can filter out the packets which don't belong to the sidetone setting. Also don't have any music or so playing while capturing. |
I redid the capture and waited about 10 seconds as requested. |
Somehow the capture doesn't match the lsusb output. On the capture there are the endpoints 0x82 for input and 0x03 for output. On the lsusb output, there is only 0x84 however. It's like that these are different devices. That's also the reason you get the error, he simply can't find the endpoint. If you already run lsusb and the compiled program as root (with the old transfer interrupt code), I sadly don't know where to look next. |
I think I've found the error. I booted in a VM into linux and checked my lsusb output, it is actually quite the same as yours. However your headset still uses interrupts. Does this (hopefully) work? Edit: If it doesn't work, and you don't mind you could also send me a capture with http://www.usblyzer.com/ The headset should be listed as "USB Composite Device" under which there should be a Sound-Part (named like the device) and "USB Input Device". Make sure to just check USB Input Device, like http://i.imgur.com/EjlMpC1.png . Captures with usblyzer seem to be much more reliable. |
0x83 gave the same IO error:
However 0x84 gave a different error:
I guess that's progress? |
Could be, but not necessarily. You can try to increase the last number from 1000 to 3000, it's the timeout. And you could also try endpoints 0x81 and 0x82. I also checked the packets of my own headset, I noticed that sometimes wireshark shows not every packet, usblyzer instead made it quit easy to find it out. |
0x81 and 0x82 both give the IO error as above. Increasing the timeout to 3000 gave the same timeout error. I even tried 5000 as the timeout to no avail. EDIT: I'll try USBlyzer later tonight and get a capture log for you by tomorrow |
Hello, You can find dumped data from iCUE and my Thanks. |
Try to open one of the existing implementations of the Corsair void, and replace the productId with the id of your product (0x0a1e), then recompile |
I made a fork that implements partial support for the Wired Void. It finds the Void Wired however, the sidetone command for the Void fails with:
This would lead me to believe that possibly the protocol for the Wired version is different than the Wireless? Any ideas?
The text was updated successfully, but these errors were encountered: