Skip to content
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

Add support for original xbox gamepads and SBC hardware via USB passthrough with libusb #2290

Merged
merged 8 commits into from
Nov 8, 2021

Conversation

ergo720
Copy link
Member

@ergo720 ergo720 commented Nov 3, 2021

Mostly the same as #2289, but with better code. It's a draft because I don't have a SBC to test, so I have no idea if this actually works or it has bugs and/or crashes.

@github-actions github-actions bot added cmake cmake HLE High Level Emulation informational useful information, not a bug input USB and/or game input related LLE Low Level Emulation modules submodules user interface GUI related labels Nov 3, 2021
@medievil1
Copy link
Contributor

seems fine except rumble... either both left and right motors are active when testing the right or the left is just dead(worked in the other incarnation)
gamepad test should activate them separately and did before

@ergo720
Copy link
Member Author

ergo720 commented Nov 4, 2021

@medievil1 I think I found the problem and added a workaround for it. Can you retest to see if it helps?

@faha223
Copy link
Contributor

faha223 commented Nov 4, 2021

I'll take a look at this with my SBC later to verify that it works

@ergo720
Copy link
Member Author

ergo720 commented Nov 4, 2021

@faha223 A note about the SBC. We are currently using a subtype of 0x2 for the virtual SBC, and that's wrong according to the xboxdevwiki which reports a subtype of 0x1 instead. We can know the correct value by looking at the bSubType member of the xid descriptor of the controller, which is dumped to the kernel log when you select the "libusb" logging option at info level. So, can you also report that value as well please?

@faha223
Copy link
Contributor

faha223 commented Nov 4, 2021

I'm seeing this in the logfile:
[0x1DFC] INFO : LIBUSB Xid descriptor dump:
bLength: 0X00000010
bDescriptorType: 0X00000042
bcdXid: 0X00000100
bType: 0X00000080
bSubType: 0X00000001
bMaxInputReportSize: 0X0000001A
bMaxOutputReportSize: 0X00000016
wAlternateProductIds[0]: 0X0000FFFF
wAlternateProductIds[1]: 0X0000FFFF
wAlternateProductIds[2]: 0X0000FFFF
wAlternateProductIds[3]: 0X0000FFFF

So it looks like a real Steel Battalion Controller will have subtype of 0x01.

Inputs seem to all work, but LEDs don't. I had expected either they'd work perfectly, or they'd be off by 2 bytes but they're not working at all.

@faha223
Copy link
Contributor

faha223 commented Nov 4, 2021

Also, rumble doesn't work on any of my OEM Xbox controllers.
VID 0x045E and PIDs 0x0202 (Duke), 0x0285 (Controller S), and 0x0289 (Controller S). I'm going to try building from source as it's possible I downloaded an artifact from before the rumble fix

Edit: Even built from source I'm getting no rumble
Edit2: From tinkering with the source it looks like the Buffer variable being passed into ExecuteIo is not an XidGamepadOutput or a XidSBCOutput structure, but instead an XpadOutput or SBCOutput. I managed to get the LED data writing to the SBC by switching from a libusb_control_transfer to a libusb_bulk_transfer and it was off by 2 bytes (the shifter was turning on the COM button LEDs, which are 2 bytes away from the shifter LEDs), indicating that the reportId and length fields were being written into the start of the data.

@ergo720
Copy link
Member Author

ergo720 commented Nov 4, 2021

@faha223 Yes, I discovered the rumble pointer I was passing was off by two bytes. I also disabled the rumble workaround I added in the previous commit. If it still doesn't work, I'll add it back.

@faha223
Copy link
Contributor

faha223 commented Nov 4, 2021

Rumble works now. SBC LEDs still don't.

If I switch from libusb_control_transfer to libusb_interrupt_transfer or libusb_bulk_transfer when writing the data to the device then it works fine. It seems that either the parameters for libusb_control_transfer are wrong for the SBC out endpoint, or libusb_control_transfer is the wrong function to use to write to the SBC out endpoint.

@medievil1
Copy link
Contributor

Rumble working correctly now.....

@faha223
Copy link
Contributor

faha223 commented Nov 4, 2021

SBC LEDs are working perfectly now

@medievil1
Copy link
Contributor

rumble still good to go as well

@ergo720 ergo720 marked this pull request as ready for review November 4, 2021 23:04
@ergo720
Copy link
Member Author

ergo720 commented Nov 5, 2021

I switched to interrupt transfers directly instead of control transfer, in an attempt to simplify ExecuteIo. Let's see if this still works, otherwise I'll revert it. Another thing that I don't know is whether or not this works out of the box or it requires the installation of additional drivers/libraries for USB passthrough to actually work. If it's the latter, then the additional requirements should be added to the README of the repository.

@ergo720 ergo720 force-pushed the hw_passthrough branch 2 times, most recently from 022f225 to 2425406 Compare November 5, 2021 13:50
@faha223
Copy link
Contributor

faha223 commented Nov 5, 2021

I installed the WinUSB driver using Zadig to get it working, since libusb on Windows is a wrapper around WinUSB. @medievil1 said he used xb2xinput and that worked too.

Edit: I've only tried it with my various xbox controllers and my SBC, but I think you can install the WinUSB driver for just about any USB device. There's probably a way to do it within Device Manager but I just used Zadig so I don't know for certain

@faha223
Copy link
Contributor

faha223 commented Nov 5, 2021

My Xbox Controller S still works (including Rumble), and my SBC still works (including LEDs)

@medievil1
Copy link
Contributor

s controller still works fine (rumble too) via the xb2xinput driver method..which is just libusb pretty much...lol

Copy link
Member

@RadWolfie RadWolfie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some local modification to see how it react to unfiltered usb devices. It cause a crash which I didn't investigate where as it's not that important at this time.

So, since my Xbox 360 Wireless Controller meet WinUSB compliant driver support. I went with non-standard PC controller to see if at least one title able to detect my inputs. Turns out only one button have response whilst other buttons has no response. However, this was only a test to see how xbox title's may response to "emulated" controller type for non-xbox controller.

The code's functionality looks good to me. Just have some nits here and there.

CMakeLists.txt Outdated Show resolved Hide resolved
CMakeLists.txt Show resolved Hide resolved
CMakeLists.txt Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
projects/cxbx/CMakeLists.txt Outdated Show resolved Hide resolved
projects/libusb/CMakeLists.txt Outdated Show resolved Hide resolved
projects/libusb/CMakeLists.txt Outdated Show resolved Hide resolved
src/common/input/InputManager.cpp Outdated Show resolved Hide resolved
src/gui/resource/ResCxbx.h Show resolved Hide resolved
src/common/input/LibusbDevice.cpp Outdated Show resolved Hide resolved
src/gui/resource/Cxbx.rc Outdated Show resolved Hide resolved
@ergo720 ergo720 force-pushed the hw_passthrough branch 2 times, most recently from 0e49859 to 7791c9d Compare November 6, 2021 18:19
Copy link
Member

@RadWolfie RadWolfie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit review remarks are done.

Base on two reports, I believe it is safe to merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmake cmake HLE High Level Emulation informational useful information, not a bug input USB and/or game input related LLE Low Level Emulation modules submodules user interface GUI related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants