Sidewinder FFB Wheel - detection as gamepad on Steamdeck
EXTgithub99cd2 opened this issue · comments
Hi,
I thought I found a similar description in another issue here about the Sidewinder FFB Wheel being detected as gamepad, but I can not find it anymore. So with the risk of being a duplicate I write my question here.
When I use the Sidewinder FFB Wheel on Windows 10 or Linux desktop (Steamdeck/Arch Linux, desktop mode), it simply works. It is detected as a Sparkfun Pro Micro and/or XBOX 360 Controller. But the wheel and pedals work as 3 axis without problem.
But when I connect it to my Steamdeck in "gaming mode", it is also detected as Sparkfun Pro Micro and/or XBOX 360 controller, but without the 3 axis working. I can get the wheel function as a thumbstick (hard) left/right, I might get the "brake" pedal working as a thumbstick down. However the "gas" pedal does not work at all.
I have found similar detection issues for Logitech wheels being mentioned on reddit with several (deprecated) solutions. One of which eventually referred to the kernel driver for sidewinder (yes, for the Logitech wheels). Then I realised Necroware described using these drivers as a base for the implementation of the gameport adapter. So while I thought this must be a local OS issue, outside of the firmware I seem to end up running circles.
Can someone help Identify where this problem is, is it in the adapter or in the OS? I am confused.
Hi, the linux implementation is been used as an information source, to understand the protocol, but the implementation in this project has been made completely from scratch. But if some assumptions were made in the linux code, that assumptions could end up in this project as well. The detection of the Sidewinder device happens using the packet length. For the GamePad it's 15 bits and for the FFB Wheel it's either 11 or 33 bits depending on the mode, which the wheel is set into. If for some reason the firmware gets 15 bits package from the FFB Wheel, it could be wrongly detected as a GamePad. I didn't see such issues with another joysticks, but I have no wheel to tell what's going on. I could imagine, that the the initialization sequence fails and the Wheel sends another package, which lands out of sync with the firmware, but I can't validate that.
Logitech and Sidewider code is unrelated here, since it is set by switches which path has to be taken. If set to Sidewinder, Logitech code will not be used at all, and the other way around neither. I'll take a look at the linux code for the wheel once again, may be I can recognize something related.
Does the problem disappear if you re-connect the adapter into USB couple of times?
Hi,
thanks for the quick response. The behaviour does not change on reconnecting. Always the same result.
The reference I made to Logitech was only because apparently the sidewinder driver in the kernel is used for Logitech wheels as well, as I understand it anyway. This makes it sound driver related and not directly manufacturer/hardware/wheel related?
And yes, I don't know if this is copied to your project somehow.
If you want me to do some analyses on my side, I am willing to assist if you can guide me on the setup/use of the right tools.
I am however somewhat slower in response :)
I'm quite sure, that Sidwinder code is not used for Logitech, they are completely different. Sidewinder is patented by Microsoft and Logitech uses own ADI protocol, however linux could have autodetection by probing the gameport and trying to detect it as Sidewinder first. May be in such a case a Logitech device could be detected as Sidewinder ending up non functional. However, as I said, this can't happen here, since the firmware doesn't probe it uses what is set by switches.
I'm looking at the code and don't know currently how that can happen to be honest. There coud be two possibilities, timing issues, the Wheel send the data too fast and the adapter swallows some bits, or the wheel sends an ID package, which is accidentally 15 bit long on a Wheel. It's very hard to tell without debugging. As a workaround, you can modify the function guessModel() in Sidewinder.cpp to always return Model::SW_FORCE_FEEDBACK_WHEEL. This is of course not a solution for the wide audience. Strange is, that it works on other OSes, but not on the Steamdeck, which is basically an ArchLinux, which I'm using all the time since 15 years. The whole development of this adapter is been made there.... very strange. It should actually make no difference, which OS is on the other side of the adapter, it has no influence on how the adapter communicates with the input device.
Could it be, that Steamdeck shows all "unknown" Joysticks as two axes gamepads? Did you try something else?
Some reference about a difference in "console" mode and "PC" mode for the Logitech, which resembles my experience for the Sidewinder Wheel in either "Gaming mode" and "Desktop mode"
It mentions "usb_modeswitch".
Reddit
Basically, the Logitech wheels have a "console" and a "PC" mode, and when you plug it in to your Steam Deck, the wheel stays in "console" mode, so it doesn't input to a PC like it should.
That sidewinder part I seem to misread, I can not find it anymore. But above the issue sounds similar. Just because of the driver implementation I don't know where to look for a solution.
Well, as I said, actually the OS on USB side of the adapter knows nothing about the communication of the adapter to the joystick. The same on the other side, joystick knows nothing about which OS it is runing on or in which mode the OS is. So, the only thing, which sounds plausible is that Steamdeck just "cuts" down any input device which it doesn't know officialy to something very simple, like a gamepad. I have no Steamdeck to validate, but if you have another joystick, you could try. You also could try to set the switches to CH Flightstick for example and see, what Steamdeck will say. You can do it even without connecting any joystick to the gameport at all. It will act as a dummy.
I am a keyboard + mouse person, not much else to test with.
I do have a Nintendo Switch and thus have connected joy-cons and Nintendo pro controllers to the steamdeck, however they have been specifically supported to work on the Steamdeck. They don't always connect easy, but they always get recognized correctly when they do connect. I can not think of any other gadget.
I did play with the switches on the Pro Micro in desktop mode, it results in error messages on the Steamdeck (using dmesg -Tw).
I will check what happens in gaming mode, not sure if I can run a console to check while doing that.
You should be able to setup any analog joysticks on the switches incl. CH Flightstick and Thrustmaster. The adapter sends a generic USB descriptor to the operation system, which should be able to handle it properly. The amount of axes, buttons etc. is in that description packet. If the Sidewinder detects it as GamePad it sends a USB description with 2 axes and 10 buttons. If you see something else in Steamdeck, then the problem is there. If you see 2+10, then it's probably in the firmware and the Wheel detection code.
Just connected CH Flightstick DIPswitch 0010 on desktop mode.
[Tue Apr 4 23:26:33 2023] usb 1-1.3: new full-speed USB device number 63 using xhci_hcd
[Tue Apr 4 23:26:33 2023] usb 1-1.3: New USB device found, idVendor=1b4f, idProduct=9206, bcdDevice= 1.00
[Tue Apr 4 23:26:33 2023] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue Apr 4 23:26:33 2023] usb 1-1.3: Product: SparkFun Pro Micro
[Tue Apr 4 23:26:33 2023] usb 1-1.3: Manufacturer: SparkFun
[Tue Apr 4 23:26:33 2023] usb 1-1.3: SerialNumber: HIDCE
[Tue Apr 4 23:26:33 2023] cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device
[Tue Apr 4 23:26:33 2023] input: SparkFun SparkFun Pro Micro as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-1/1-1.3/1-1.3:1.2/0003:1B4F:9206.001E/input/input71
[Tue Apr 4 23:26:33 2023] hid-generic 0003:1B4F:9206.001E: input,hidraw8: USB HID v1.01 Joystick [SparkFun SparkFun Pro Micro] on usb-0000:04:00.3-1.3/input2
[Tue Apr 4 23:26:34 2023] input: Microsoft X-Box 360 pad 1 as /devices/virtual/input/input72
It's worth mentioning which type of controller Steamdeck officially supports:
- XBox 360: USB
- Xbox One: USB and Bluetooth (3rd gen)
- Xbox Series X/S: USB and Bluetooth
- Switch Pro: USB and Bluetooth
- PlayStation DualShock 4: USB and Bluetooth
- PlayStation 5 DualSense: USB and Bluetooth
- Steam Controller: USB and Bluetooth
- Generic XInput controllers: Varies
- DirectInput controllers: Varies
The very last 2 options seem interesting, but I doubt that the current code is (fully?) compatible with XInput and/or DirectInput?
Correct me when I'm wrong.
I am not as knowledgeable on code as you, following a learning curve here.
Steam/OS gets very upset when I change the DIPswitch a couple times (disconnect, change, connect).
[Tue Apr 4 23:34:44 2023] usb 1-1.3: new full-speed USB device number 13 using xhci_hcd
[Tue Apr 4 23:34:44 2023] usb 1-1.3: New USB device found, idVendor=1b4f, idProduct=9206, bcdDevice= 1.00
[Tue Apr 4 23:34:44 2023] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue Apr 4 23:34:44 2023] usb 1-1.3: Product: SparkFun Pro Micro
[Tue Apr 4 23:34:44 2023] usb 1-1.3: Manufacturer: SparkFun
[Tue Apr 4 23:34:44 2023] usb 1-1.3: SerialNumber: HIDCE
[Tue Apr 4 23:34:44 2023] cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device
[Tue Apr 4 23:34:44 2023] input: SparkFun SparkFun Pro Micro as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-1/1-1.3/1-1.3:1.2/0003:1B4F:9206.000E/input/input45
[Tue Apr 4 23:34:44 2023] hid-generic 0003:1B4F:9206.000E: input,hidraw8: USB HID v1.01 Joystick [SparkFun SparkFun Pro Micro] on usb-0000:04:00.3-1.3/input2
[Tue Apr 4 23:34:46 2023] input: Microsoft X-Box 360 pad 1 as /devices/virtual/input/input46
[Wed Apr 5 00:13:22 2023] usb 1-1.3: new full-speed USB device number 8 using xhci_hcd
[Wed Apr 5 00:13:22 2023] usb 1-1.3: New USB device found, idVendor=1b4f, idProduct=9206, bcdDevice= 1.00
[Wed Apr 5 00:13:22 2023] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Wed Apr 5 00:13:22 2023] usb 1-1.3: Product: SparkFun Pro Micro
[Wed Apr 5 00:13:22 2023] usb 1-1.3: Manufacturer: SparkFun
[Wed Apr 5 00:13:22 2023] usb 1-1.3: SerialNumber: HIDAA
[Wed Apr 5 00:13:22 2023] cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device
[Wed Apr 5 00:13:22 2023] usbhid 1-1.3:1.2: can't add hid device: -22
[Wed Apr 5 00:13:22 2023] usbhid: probe of 1-1.3:1.2 failed with error -22
[Wed Apr 5 00:13:47 2023] usb 1-1.3: USB disconnect, device number 8
[Wed Apr 5 00:13:51 2023] usb 1-1.3: new full-speed USB device number 9 using xhci_hcd
[Wed Apr 5 00:13:51 2023] usb 1-1.3: New USB device found, idVendor=2341, idProduct=0036, bcdDevice= 0.01
[Wed Apr 5 00:13:51 2023] usb 1-1.3: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[Wed Apr 5 00:13:51 2023] usb 1-1.3: Product: Arduino Leonardo
[Wed Apr 5 00:13:51 2023] usb 1-1.3: Manufacturer: Arduino LLC
[Wed Apr 5 00:13:52 2023] cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device
[Wed Apr 5 00:13:55 2023] usb 1-1.3: USB disconnect, device number 9
Original Sidewinder setting 1110
[Wed Apr 5 00:13:55 2023] usb 1-1.3: new full-speed USB device number 10 using xhci_hcd
[Wed Apr 5 00:13:55 2023] usb 1-1.3: New USB device found, idVendor=1b4f, idProduct=9206, bcdDevice= 1.00
[Wed Apr 5 00:13:55 2023] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Wed Apr 5 00:13:55 2023] usb 1-1.3: Product: SparkFun Pro Micro
[Wed Apr 5 00:13:55 2023] usb 1-1.3: Manufacturer: SparkFun
[Wed Apr 5 00:13:55 2023] usb 1-1.3: SerialNumber: HIDDD
[Wed Apr 5 00:13:55 2023] cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device
[Wed Apr 5 00:13:55 2023] input: SparkFun SparkFun Pro Micro as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-1/1-1.3/1-1.3:1.2/0003:1B4F:9206.000E/input/input45
[Wed Apr 5 00:13:55 2023] hid-generic 0003:1B4F:9206.000E: input,hidraw8: USB HID v1.01 Joystick [SparkFun SparkFun Pro Micro] on usb-0000:04:00.3-1.3/input2
[Wed Apr 5 00:13:57 2023] input: Microsoft X-Box 360 pad 1 as /devices/virtual/input/input46
Spend some time reading. Its a lot.
Lots of gamepad desciptions in Steam documentation. Where XBOX360 is apparently some kind of standard.
Xinput seems to come down to Input source mode to "Legacy" , where you can choose and define Joystick Move.
Joystick Move
This input will operate as a simple Joystick. This is intended for traditional joystick applications.
Legacy Note: Joystick will only work with XInput compatible gamepad games
source: https://partner.steamgames.com/doc/features/steam_controller/input_source_modes
The Sparkfun Pro Micro does get detected/described as XBOX360 many times, this being some kind of (gamepad) default. Question remains how to switch to Legacy input source mode there.
Going back to my original question, I think here is the answer: it seems this "gaming mode" is actually only the SteamClient in fullscreen, where driver support gets boxed-in on the SteamClient as opposed to Desktop Mode where the OS takes control of the driver support. Support then depending on the applications to support Xinput.
Would be nice if I can figure this out.
Some of the errors when changes made:
lots of:
usbhid 1-1.3:1.2: can't add hid device: -22
once or twice:
usb 1-1.3: can't set config #1, error -32
searchengine suggests it is a timing related issue when disconnecting and reconnecting USB-dongle?
After a lot of testing and tracing we found out, that when we pull out the usb-dongle ot of the usb-socket just that far that the power-pins are still connected and only the connection-pins are disconnected and then plug it back, the device will be detected just fine. Also when using a external usb-hub it will come up normally.
So it seems the problem comes from a timing issue between the ... driver and the dongle. Probably the dongle delivers the usb-config too slow so that the kernel has no config to select the further loading of cdc_acm.
Everytime I had to completely reboot the system after this happened. I can not get the adapter properly connected anymore at such point.
Could it be power issue? After all, this is mobile device. Not sure how the 5V for usb port gets generated - maybe it is enough to drop a little when connecting?
If you have powered usb hub, try connecting it via hub. This should tell if it's powering problem.
Maybe adding a slight delay in code right in the beginning, before anything gets initialized would help?
Ow. I was saving my power related questions for a seperate issue ...
Hi guys, does this issue still exist with the latest state of the firmware and SteamOS? Just trying to clean up some tickets.
Closing due to absence of news on this one. This bug could have been fixed already with other fixes. If it happens again with the recent firmware, please reopen.