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

joysticks? #53

Closed
BenGardiner opened this issue Oct 16, 2015 · 10 comments
Closed

joysticks? #53

BenGardiner opened this issue Oct 16, 2015 · 10 comments
Labels
technical support request for technical support

Comments

@BenGardiner
Copy link

I've tried usb-mitm with a couple different types of USB joysticks; with host and device proxy both on the BBB (using the release image) and with device proxy on BBB and host proxy on a PC; the result is so far always the same. The host (always linux in my setup) enumerates the proxied joystick device but then fails to create an input device; dmesg shows

[xxx] usb 1-2: can't set config #1, error -110

I also tried using a userspace (libusb-based) driver for the joystick on the host; but that program fails to claim the interface

 Error couldn't claim the USB interface: LIBUSB_ERROR_NOT_FOUND

I can see that USBProxy has worked with joysticks since the -h output shows -x for Xbox360 support.

I'm happy to dig into this and likely (hopefully?) can fix it myself. Any ideas where I should start?

@dominicgs
Copy link
Contributor

This definitely sounds familiar. I think the problem is that we pass most control messages straight through to the device apart from some special cases. Perhaps setting the configuration should be changed from a message that is passed through to the device to a call to libusb_set_configuration() ?

For that, you will probably want to start looking in Plugins/Devices/DeviceProxy_Libusb.cpp (or whatever the file is called, I forget)

@palesius
Copy link
Collaborator

For what it's worth all -x really does (at least when I first wrote it) is
essentially bitwise or any messages from the actual device with the last
message artificially injected via the BBB. Otherwise (at least with xbox
360 controllers) there is a constant stream of updates on the analog
inputs, and an injected value (of say 100% of the range) would be almost
instantly overwritten by one from the physical device.

But other than that it doesn't do anything special. Setup and data
endpoints just pass data back verbatim.
On Oct 16, 2015 9:27 AM, "Ben Gardiner" notifications@github.com wrote:

I've tried usb-mitm with a couple different types of USB joysticks; with
host and device proxy both on the BBB (using the release image) and with
device proxy on BBB and host proxy on a PC; the result is so far always the
same. The host (always linux in my setup) enumerates the proxied joystick
device but then fails to create an input device; dmesg shows

[xxx] usb 1-2: can't set config #1, error -110

I also tried using a userspace (libusb-based) driver for the joystick on
the host; but that program fails to claim the interface

Error couldn't claim the USB interface: LIBUSB_ERROR_NOT_FOUND

I can see that USBProxy has worked with joysticks since the -h output
shows -x for Xbox360 support.

I'm happy to dig into this and likely (hopefully?) can fix it myself. Any
ideas where I should start?


Reply to this email directly or view it on GitHub
#53.

@BenGardiner
Copy link
Author

Thanks @dominicgs and @palesius. I think I know where to look. And now I get what -x is doing to boot.

@palesius, when you last used -x with a 360 controller: what was your host type? e.g. windows? osx? Also could you guess the date or sha1 of this repo where you last tested?

@BenGardiner
Copy link
Author

I've tested with a windows 7 host on master -- works like a charm. I think the problem is limited to Linux.

@palesius
Copy link
Collaborator

Host was an xbox. And as I said the -x only really matters if you are
injecting packets as well. It works just fine without, just injected
packets will likely be overwritten by those from the device in short order.
My guess is around 12/28/2013 based on dates. I am way behind current. I
did make some additional changes a couple of months after that to spoof a
different device descriptor (2/22/14) but I don't think I ever commited
those.
On Oct 16, 2015 11:06 AM, "Ben Gardiner" notifications@github.com wrote:

Thanks @dominicgs https://github.com/dominicgs and @palesius
https://github.com/palesius. I think I know where to look. And now I
get what -x is doing to boot.

@palesius https://github.com/palesius, when you last used -x with a 360
controller: what was your host type? e.g. windows? osx? Also could you
guess the date or sha1 of this repo where you last tested?


Reply to this email directly or view it on GitHub
#53 (comment).

@palesius
Copy link
Collaborator

It might be worth running it with logging on for both windows and linux and
see where things go off the rails. It used to be that if you ran with -d or
maybe -dd it would show all the packet traffic on stdout.
If there's a way to dump usb packets on linux w/o the BBB, you could also
try doing a trace that way of the joystick capture to compare how it is on
the BBB.
On Oct 16, 2015 10:29 PM, "Ben Gardiner" notifications@github.com wrote:

I've tested with a windows 7 host on master -- works like a charm. I think
the problem is limited to Linux.


Reply to this email directly or view it on GitHub
#53 (comment).

@BenGardiner
Copy link
Author

Thanks again, @palesius .

Yeah I've been comparing usbmon pcaps of direct-connect to Linux and USBProxy'd ; the difference is a SET CONFIGURATION response URB Status: of -2 (ENOENT) in the USBProxy'd case. I haven't looked at a pcap of the windows case yet but I agree it should be enlightening.

@dominicgs
Copy link
Contributor

It definitely sounds like we need to do something more sensible with the set_configuration() call instead of passing it through. I'd be interested in the usbmon output when you proxy to a Windows host.

My guess for why they are different is that Linux is explicitly setting the configuration while Windows probably sees that it's the active configuration and doesn't bother. Otherwise we ought to see the same error appear when proxying to a Windows host.

I don't have any hardware that causes this sort of error, although I've heard of it happening before. Are you able to tell us the model of joystick that you're using?

@BenGardiner
Copy link
Author

@dominicgs -- I'll try to get around to the windows pcap -- but I'll be honest with you: windows as a host isn't my rountine so it isn't going to be happening at a high priority.

Of course I can say the joystick types :) Xbox 360, Xboxone and "TigerGame PS/PS2 Game Controller Adapter" / "ID 6666:8802 Prototype product Vendor ID SmartJoy Dual Plus PS2 converter".

BenGardiner pushed a commit to BenGardiner/USBProxy that referenced this issue Oct 19, 2015
resolves issue usb-tools#53 for me; however, it's probably not a full solution
since it doesn't cause any libusb_set_configuration() calls on the
device proxy at all.
@straithe straithe added the technical support request for technical support label Nov 4, 2021
@straithe
Copy link
Member

I'm going to close this as there hasn't been a response in a while, but please re-open this issue or open a new one if you still need assistance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
technical support request for technical support
Projects
None yet
Development

No branches or pull requests

4 participants