Closed mn1213 closed 4 years ago
root password isn't documented but if you login as debian/temppwd you can
sudo su
into root and change the password to what ever you want. What
image are you using? This is the wired Pro, not the Pro+? THat is odd
that it shows up as a Xbox 360 controller. Let me see what I debug on my
end. I don't have a Pro, but I can get one to test.
On Sat, Oct 19, 2019 at 12:23 AM mn1213 notifications@github.com wrote:
I have a wired 8bitdo SN30 Pro -> Beaglebone Green -> Nintendo Switch (via. StarTech Dual A to Micro B cable USB2HAUBY1).
The controller powers on as player one (in spite of other controllers) and rumbles momentarily. Neither the Switch or the RetroSpy client can read inputs from the controller. It does not seem to matter in which order I connect everything.
dmesg logs the device as a 360 pad on connect. Rarely, it shows up as a Pro Controller for just a second.
[ 410.120831] usb 1-1: New USB device found, idVendor=057e, idProduct=2009 [ 410.120853] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 410.120862] usb 1-1: Product: Pro Controller [ 410.120871] usb 1-1: Manufacturer: Nintendo Co., Ltd. [ 410.120879] usb 1-1: SerialNumber: 000000000001 [ 410.144662] input: Nintendo Co., Ltd. Pro Controller as /devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/usb1/1-1/1-1:1.0/0003:057E:2009.0001/input/input2 [ 410.148793] hid-generic 0003:057E:2009.0001: input,hidraw0: USB HID v1.11 Joystick [Nintendo Co., Ltd. Pro Controller] on usb-musb-hdrc.1-1/input0 [ 411.490604] usb 1-1: USB disconnect, device number 4 [ 412.253553] usb 1-1: new full-speed USB device number 5 using musb-hdrc [ 412.410380] usb 1-1: New USB device found, idVendor=045e, idProduct=028e [ 412.410402] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 412.410411] usb 1-1: Product: Controller [ 412.410419] usb 1-1: Manufacturer: Controller [ 412.410427] usb 1-1: SerialNumber: Controller [ 412.427481] input: Microsoft X-Box 360 pad as /devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/usb1/1-1/1-1:1.0/input/input3
$ lsusb Bus 001 Device 013: ID 045e:028e Microsoft Corp. Xbox360 Controller Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Any advice on troubleshooting the issue would be greatly appreciated!
(Also, is the root password documented, and is there an equivalent to jstest in this image?)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zoggins/RetroSpy/issues/97?email_source=notifications&email_token=AE2CEVT3OTRW6Y2774JYDV3QPKYWPA5CNFSM4JCOTI7KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HS463RA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2CEVVJO5675GUJCM2KKL3QPKYWPANCNFSM4JCOTI7A .
I'm using the image from the 3.3 release, and correct, it's the regular wired-only Pro.
I've been feeling around the system a little now that I've got root (silly me for assuming I would not be able to log in as debian
) and will let you know if I determine the underlying issue.
Am I correct in assuming something should fire off usb-mitm when a controller is connected?
Running with this assumption a bit, I see usb-mitm [...] -a
throws "invalid option -- 'a'", which may explain why the viewer isn't working in 360 mode. Attempting to start usb-mitm in Switch mode is also less than fruitful.
debian@beaglebone:~$ sudo usb-mitm -v 045e -p 028e -dd -z
CP: Vector Plugins
CP: Pointer PacketFilter_Switch::file
Version ShmooCon_2015-131-g3126
Running under kernel 4.14.71-ti-r80
CP: String DeviceProxy = DeviceProxy_LibUSB
CP: String HostProxy = HostProxy_GadgetFS
Connected to device: 045e:028e@02 Controller - Controller
LibUSB> 80 06 00 01 00 00 12 00
LibUSB< 12 01 00 02 ff ff ff 40 5e 04 8e 02 14 01 01 02 03 01
LibUSB> 80 06 00 03 00 00 08 00
LibUSB< 04 03 09 04
LibUSB> 80 06 01 03 09 04 08 00
LibUSB< 16 03 43 00 6f 00 6e 00
LibUSB> 80 06 01 03 09 04 16 00
LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00
LibUSB> 80 06 02 03 09 04 08 00
LibUSB< 16 03 43 00 6f 00 6e 00
LibUSB> 80 06 02 03 09 04 16 00
LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00
LibUSB> 80 06 03 03 09 04 08 00
LibUSB< 16 03 43 00 6f 00 6e 00
LibUSB> 80 06 03 03 09 04 16 00
LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00
LibUSB> 80 06 00 02 00 00 09 00
LibUSB< 09 02 8b 00 04 01 00 a0 fa
LibUSB> 80 06 00 02 00 00 8b 00
LibUSB<
09 02 8b 00 04 01 00 a0 fa 09 04 00 00 02 ff 5d 01 00 11 21 10 01 01 25 81 14 03 03 03 04 13 02
08 03 03 07 05 81 03 20 00 04 07 05 02 03 20 00 08 09 04 01 00 02 ff 5d 03 00 1b 21 00 01 01 01
83 40 01 04 20 16 85 00 00 00 00 00 00 16 05 00 00 00 00 00 00 07 05 83 03 20 00 02 07 05 04 03
20 00 04 09 04 02 00 01 ff 5d 02 00 09 21 00 01 01 22 86 07 00 07 05 86 03 20 00 10 09 04 03 00
00 ff fd 13 04 06 41 00 01 01 03
LibUSB> 80 06 04 03 09 04 08 00
Error sending setup packet: Pipe error
Error sending control request!
For the sake of covering all bases, I'm going to double-check my controller's firmware version and also give the RetroSpy 3.2.1 image a shot. Will update this issue promptly if the situation changes.
No you have to manually run usb-mitm from the shell after you plug in, its not automatic. running 'usb-mitm -z' should be sufficient. the Pipe Error sare common, but not the "error sending control request" Let me get a controller and see what I see. out of curiosity does 'usb-mitm &>2 /dev/null' cause the controller to start working. No display will happen, but does it connect to the switch with that
On Sat, Oct 19, 2019 at 9:54 AM mn1213 notifications@github.com wrote:
I'm using the image from the 3.3 release, and correct, it's the regular wired-only Pro.
I've been feeling around the system a little now that I've got root (silly me for assuming I would not be able to log in as debian) and will let you know if I determine the underlying issue.
Am I correct in assuming something should fire off usb-mitm when a controller is connected?
Running with this assumption a bit, I see usb-mitm [...] -a throws "invalid option -- 'a'", which may explain why the viewer isn't working in 360 mode. Attempting to start usb-mitm in Switch mode is also less than fruitful.
debian@beaglebone:~$ sudo usb-mitm -v 045e -p 028e -dd -z CP: Vector Plugins CP: Pointer PacketFilter_Switch::file Version ShmooCon_2015-131-g3126 Running under kernel 4.14.71-ti-r80 CP: String DeviceProxy = DeviceProxy_LibUSB CP: String HostProxy = HostProxy_GadgetFS Connected to device: 045e:028e@02 Controller - Controller
LibUSB> 80 06 00 01 00 00 12 00 LibUSB< 12 01 00 02 ff ff ff 40 5e 04 8e 02 14 01 01 02 03 01 LibUSB> 80 06 00 03 00 00 08 00 LibUSB< 04 03 09 04 LibUSB> 80 06 01 03 09 04 08 00 LibUSB< 16 03 43 00 6f 00 6e 00 LibUSB> 80 06 01 03 09 04 16 00 LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00 LibUSB> 80 06 02 03 09 04 08 00 LibUSB< 16 03 43 00 6f 00 6e 00 LibUSB> 80 06 02 03 09 04 16 00 LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00 LibUSB> 80 06 03 03 09 04 08 00 LibUSB< 16 03 43 00 6f 00 6e 00 LibUSB> 80 06 03 03 09 04 16 00 LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00 LibUSB> 80 06 00 02 00 00 09 00 LibUSB< 09 02 8b 00 04 01 00 a0 fa LibUSB> 80 06 00 02 00 00 8b 00 LibUSB< 09 02 8b 00 04 01 00 a0 fa 09 04 00 00 02 ff 5d 01 00 11 21 10 01 01 25 81 14 03 03 03 04 13 02 08 03 03 07 05 81 03 20 00 04 07 05 02 03 20 00 08 09 04 01 00 02 ff 5d 03 00 1b 21 00 01 01 01 83 40 01 04 20 16 85 00 00 00 00 00 00 16 05 00 00 00 00 00 00 07 05 83 03 20 00 02 07 05 04 03 20 00 04 09 04 02 00 01 ff 5d 02 00 09 21 00 01 01 22 86 07 00 07 05 86 03 20 00 10 09 04 03 00 00 ff fd 13 04 06 41 00 01 01 03 LibUSB> 80 06 04 03 09 04 08 00 Error sending setup packet: Pipe error Error sending control request!
For the sake of covering all bases, I'm going to double-check my controller's firmware version and also give the RetroSpy 3.2.1 image a shot. Will update this issue promptly if the situation changes.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zoggins/RetroSpy/issues/97?email_source=notifications&email_token=AE2CEVRUEKFBOFZUXAJBX4DQPM3UNA5CNFSM4JCOTI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXWPHA#issuecomment-544171932, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2CEVX55RE7KXINWHFR3J3QPM3UNANCNFSM4JCOTI7A .
I will have a controller to test tomorrow.
On Sat, Oct 19, 2019 at 10:16 AM Christopher Mallery < christopher.mallery@gmail.com> wrote:
No you have to manually run usb-mitm from the shell after you plug in, its not automatic. running 'usb-mitm -z' should be sufficient. the Pipe Error sare common, but not the "error sending control request" Let me get a controller and see what I see. out of curiosity does 'usb-mitm &>2 /dev/null' cause the controller to start working. No display will happen, but does it connect to the switch with that
On Sat, Oct 19, 2019 at 9:54 AM mn1213 notifications@github.com wrote:
I'm using the image from the 3.3 release, and correct, it's the regular wired-only Pro.
I've been feeling around the system a little now that I've got root (silly me for assuming I would not be able to log in as debian) and will let you know if I determine the underlying issue.
Am I correct in assuming something should fire off usb-mitm when a controller is connected?
Running with this assumption a bit, I see usb-mitm [...] -a throws "invalid option -- 'a'", which may explain why the viewer isn't working in 360 mode. Attempting to start usb-mitm in Switch mode is also less than fruitful.
debian@beaglebone:~$ sudo usb-mitm -v 045e -p 028e -dd -z CP: Vector Plugins CP: Pointer PacketFilter_Switch::file Version ShmooCon_2015-131-g3126 Running under kernel 4.14.71-ti-r80 CP: String DeviceProxy = DeviceProxy_LibUSB CP: String HostProxy = HostProxy_GadgetFS Connected to device: 045e:028e@02 Controller - Controller
LibUSB> 80 06 00 01 00 00 12 00 LibUSB< 12 01 00 02 ff ff ff 40 5e 04 8e 02 14 01 01 02 03 01 LibUSB> 80 06 00 03 00 00 08 00 LibUSB< 04 03 09 04 LibUSB> 80 06 01 03 09 04 08 00 LibUSB< 16 03 43 00 6f 00 6e 00 LibUSB> 80 06 01 03 09 04 16 00 LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00 LibUSB> 80 06 02 03 09 04 08 00 LibUSB< 16 03 43 00 6f 00 6e 00 LibUSB> 80 06 02 03 09 04 16 00 LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00 LibUSB> 80 06 03 03 09 04 08 00 LibUSB< 16 03 43 00 6f 00 6e 00 LibUSB> 80 06 03 03 09 04 16 00 LibUSB< 16 03 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 6c 00 65 00 72 00 LibUSB> 80 06 00 02 00 00 09 00 LibUSB< 09 02 8b 00 04 01 00 a0 fa LibUSB> 80 06 00 02 00 00 8b 00 LibUSB< 09 02 8b 00 04 01 00 a0 fa 09 04 00 00 02 ff 5d 01 00 11 21 10 01 01 25 81 14 03 03 03 04 13 02 08 03 03 07 05 81 03 20 00 04 07 05 02 03 20 00 08 09 04 01 00 02 ff 5d 03 00 1b 21 00 01 01 01 83 40 01 04 20 16 85 00 00 00 00 00 00 16 05 00 00 00 00 00 00 07 05 83 03 20 00 02 07 05 04 03 20 00 04 09 04 02 00 01 ff 5d 02 00 09 21 00 01 01 22 86 07 00 07 05 86 03 20 00 10 09 04 03 00 00 ff fd 13 04 06 41 00 01 01 03 LibUSB> 80 06 04 03 09 04 08 00 Error sending setup packet: Pipe error Error sending control request!
For the sake of covering all bases, I'm going to double-check my controller's firmware version and also give the RetroSpy 3.2.1 image a shot. Will update this issue promptly if the situation changes.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zoggins/RetroSpy/issues/97?email_source=notifications&email_token=AE2CEVRUEKFBOFZUXAJBX4DQPM3UNA5CNFSM4JCOTI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXWPHA#issuecomment-544171932, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2CEVX55RE7KXINWHFR3J3QPM3UNANCNFSM4JCOTI7A .
No such luck running usb-mitm &>2 /dev/null
or usb-mitm -z &>2 /dev/null
after a fresh boot and connection.
I'm starting a flash of the older image now.
Ok, I will be able to help more tomorrow when the controller gets here. Unfortunately I have seen problems with some controllers connecting and since I can't test every controller I am still working on it. :) I am currently fighting with DualShock 3 controllers having a similar problem.
On Sat, Oct 19, 2019 at 10:40 AM mn1213 notifications@github.com wrote:
No such luck running usb-mitm &>2 /dev/null or usb-mitm -z &>2 /dev/null after a fresh boot and connection.
I'm starting a flash of the older image now.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zoggins/RetroSpy/issues/97?email_source=notifications&email_token=AE2CEVULRHZKHB7X4QDS22TQPNBAZA5CNFSM4JCOTI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXYCJI#issuecomment-544178469, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2CEVUE3VNQHAA7UC34KDDQPNBAZANCNFSM4JCOTI7A .
The good news is that this does not seem to be a regression from the last image, and the behavior is consistent across all of the SN30 Pro USB's firmware versions.
I'm not sure how the USB version differs from the wireless versions, but I have observed that the 8BitDo Firmware Update tool does something special to put my pad into "Pro Controller" mode on Windows, (granted that tool isn't capable of actually performing the update on wired controllers).
It's real awesome how much you're sticking your neck out to help btw. I'm no RE or USB expert, so I only hope I can help narrow down the problem
I love to help, always concerned when my code doesn't work :) So no worries there. I am sure I can find the problem, just need some time. :)
On Sat, Oct 19, 2019 at 11:31 AM mn1213 notifications@github.com wrote:
The good news is that this does not seem to be a regression from the last image, and the behavior is consistent across all of the SN30 Pro USB's firmware versions.
I'm not sure how the USB version differs from the wireless versions, but I have observed that the 8BitDo Firmware Update tool does something to put my pad into "Pro Controller" mode on Windows, (granted that tool isn't capable of actually performing the update on wired controllers).
It's real awesome how much you're sticking your neck out to help btw. I'm no RE or USB expert, so I only hope I can help narrow down the problem
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zoggins/RetroSpy/issues/97?email_source=notifications&email_token=AE2CEVV5EE7PHYPGW4X6763QPNG7FA5CNFSM4JCOTI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXZVWQ#issuecomment-544185050, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2CEVRGFTM6SZUKSNTCHQ3QPNG7FANCNFSM4JCOTI7A .
I would try to hold the Y button when plugging in the controller.
On the back of the controller you will see different power on modes. Its possible the device is starting in Xinput mode - which is why it's identifying as a 360 controller, and not being recognized by the switch.
Are you starting the contorller up in switch mode when you plug it into the beaglebone? The back says what buttons to hold down. That would explain the XInput mode.
Well isn't that something. Neither the back of my controller or the "instruction manual" say anything of the sort, but holding Y does the trick!
If I can possibly manage, I'll see about submitting a PR against USBProxy to send the same mode-switching interrupts the Firmware Update tool sends. In the meantime, thanks a bunch :)
Sounds good. Not sure what you mean by mode-switching interrupts, but pull requests are always welcome. :)
On Sun, Oct 20, 2019 at 4:26 PM mn1213 notifications@github.com wrote:
Well isn't that something. Neither the back of my controller or the "instruction manual" say anything of the sort, but holding Y does the trick!
If I can possibly manage, I'll see about submitting a PR against USBProxy to send the same mode-switching interrupts the Firmware Update tool sends. In the meantime, thanks a bunch :)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zoggins/RetroSpy/issues/97?email_source=notifications&email_token=AE2CEVWAHMYDGVEN6W53DZ3QPTSLTA5CNFSM4JCOTI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYWUWA#issuecomment-544303704, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2CEVSRYSBIT363GTVUFNDQPTSLTANCNFSM4JCOTI7A .
I have a wired 8bitdo SN30 Pro -> Beaglebone Green -> Nintendo Switch (via. StarTech Dual A to Micro B cable USB2HAUBY1).
The controller powers on as player one (in spite of other controllers) and rumbles momentarily. Neither the Switch or the RetroSpy client can read inputs from the controller. It does not seem to matter in which order I connect everything.
dmesg logs the device as a 360 pad on connect. Rarely, it shows up as a Pro Controller for just a second.
Any advice on troubleshooting the issue would be greatly appreciated!
(Also, is the root password documented, and is there an equivalent to jstest in this image?)