-
Notifications
You must be signed in to change notification settings - Fork 350
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
Windows 10 Xbox 360 (Wired) controller not working #25
Comments
@rebootjac : Usbip on android is interesting! Anyway, your issue seems to be related to usbip version mismatch. Please, check old issues #3 and #6. |
Same as for #30 , I'll ask around if someone could lend me a Xbox 360 controller. |
Hey I'm just chiming in to say I'm experiencing the same issue with a wireless controller adapter. I tried the same driver he reported (https://sourceforge.net/projects/usbip/files/usbip_windows/) it worked but it threw a BSOD when I did run the detach. The version I compiled and the version I downloaded from the release page are just showing the above issue on binding. Let me know if I can help investigating. :) |
@jacopomaroli : What is your usbip server ? I think that usbip server of android app is not compatible to usbip-win. |
Hi @cezuni ! I'm using a raspberry pi with usbip server compiled from this source https://github.com/raspberrypi/linux/tree/rpi-4.19.y/tools/usb/usbip |
Small question - did you build the USBIP vhci driver under Debug or Release configuration? Did you build vhci driver on the client system? Did you try to update env. to newest SDK and WDK? If you built usbip vhci driver under Debug conf the driver may not work good in other kernel versions or other systems (systems which has no WDK etc.).... |
@koudis I'm running the driver on the same windows 10 machine which was used to build it in debug x64 and release x64 configs (yes, I spent a bit of time fixing the release config to see if I could produce a working driver) I also tried to apply your patch here #43 just in case since I saw in regedit that Pid/PID was creating two different entries depending if I was attaching the adapter to the usb directly or using usbip-win I set 10.0.17134 version of WDK and SDK for every project in the solution problem persist |
Is an old registry entry(Pid or PID) removed if an usb device is attached in a different way? |
@cezuni The old entry is removed when the driver is replaced/uninstalled. It stays there if I plug it in directly after using usbip or vice versa. I'm referring to the entry in I realised there were few other capitalisation issues around the code: and hex code should be capitalised as well, as in: anyway driver still throw same error. I think it might be intersting if we look at the driver events:
we can see the controller being identified as |
Maybe pnp manager generated that? Different hex styles may imply that both cases are handled differently. One evidence is that when the controller is attached via usbip, the device is not recognized as a composite device. (Note outranked drivers fields in your logs) It is very likely that usb identifiers are different. Can you compare usb identifiers for both cases ? You can find those identifiers in device manager. |
@cezuni I'm sorry, I did another test and I just realised I must have swapped the outputs. I updated the above comment to reflect the actual status of the configuration to avoid confusion. |
@jacopomaroli : From your corrected description, usbip-win rather treats the device as composite.
I want to know compatible IDs for both cases. Maybe usbip-win seems to deliver USB/COMPOSITE as one of compatible IDs to the PNP manager. |
@cezuni the followings are the compatible IDs for both cases
I also did a couple of tries and hardocded the parameters in the driver code in the |
@jacopomaroli : The reason why both methods gives different compatible ids should be investigated later. The more disappointing thing is that the problem still exists after your workaround. Can you share the windows kernel log obtained in the condition that usbip-win provides the same compatible ids in hardcoded style? |
Yeah, sure! Is this a good how-to in order to achieve what we need? https://www.itprotoday.com/microsoft-visual-studio/wpp-tracing-visual-c-2010-projects with this uuid 8b56380d-5174-4b15-b6f4-4c47008801a4 . If not can you post a better source? |
@jacopomaroli : I don't know wpp tracing. I look forward your detailed explanation for wpp tracing. Let me tell my method. usbip-win uses DbgPrintEx API for kernel logging. DebugView is a good tool to view the logs. Before using it, you should enable debug filter by creating a DWORD registry entry(path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter\IHVDRIVER , value: 0xffffffff). Restart is required. Refer this link. Another good candidate is WinDbg. This tool can monitor logs on a remote machine. I resolve a BSOD by using WinDbg via serial communication. Of course, target/development machines are all virtual machines. |
thanks for the info @cezuni ! There you go: these are the logs of the driver version where I'm forcing subclass to 0x5d, protocol to 0x81 and remove USB\composite to match the case where I plug the adapter directly. Also capitalisation of the driver ids is fixed. I'm not an expert but I suspect something was unhappy around here...
|
Since I was blocked I had the Idea to try previous versions and very interesting things happened making the adapter work or breaking it. This is the order of the versions I tested (it helps to follow if you go to the github /commits page): The point I’m trying to make is that it seems there are some versions which are broken and leave the system in broken state, other which are working but not able to recover from broken state, and other which are working and able to recover from broken state. |
@jacopomaroli : A long text log can be attached as a file. You can find a help message in the bottom of github comment window. Anyway, thanks for your log. The warning for URB_FUNCTION_GET_STATUS_FROM_DEVICE is worth to investigate. But the warning may be negligible because the next usbip command(seq:5) was successfully processed. Was there any more logs? The log seems to have more logs after 190 line. IRP_MN_REMOVE_DEVICE at 189 line means that usbip session was disconnected and usually more logs appear after such a log. |
@jacopomaroli: Your testing versions and results are great but diff from two commits are so large. So I give up to find the problem from diff. |
@cezuni thanks for pointing that out, I edited my comment to include the logs as an external file. While working on the commit diff lead, I made a small script which compiles all the version between two git hashes. I now have 88 versions of the driver to play with, going back and forth, to find the offending one :) https://gist.github.com/jacopomaroli/36639202f47331412139869c812d3c75 I'll try to do what you suggested in the above comment in the next few days |
@jacopomaroli : Did you check up-to-date version? Recent uploaded commits may resolve this issue. |
hey @cezuni thanks for the heads up. I tried the new version but it fails the exact same way. I'll try to gather those logs as soon as I have time these days |
Too old issue. Close. |
I'm trying to get the client working for this server for Android to share game controllers through it:
https://play.google.com/store/apps/details?id=org.cgutman.usbipserverforandroid&hl=en_US
I have attempted both v0.0.1 and v0.0.4 drivers from this repository and I am getting the below message in both versions in Device Manager:
I tried googling that error and I found this possible solution here: https://superuser.com/questions/1316839/usb-driver-this-device-cannot-start-code-10-insufficient-system-resources
I have not tried the other versions posted but I did have it working once by using the usbip_windows_v0.2.0.0_signed.zip file from
https://sourceforge.net/projects/usbip/files/usbip_windows/
after which Windows helpfully downloaded an update and broke it after that. I'm on 10.0.17134 (v1803) as I type this. Looking at my Windows Update history (guessing here) according to those dates KB4023057 was the one that may have broke it since I'm 99.9% sure it was working before that.The text was updated successfully, but these errors were encountered: