Resolve communication error by changing wValue from 0x3000 to 0x0300

[Princemachiavelli]

The observed bug is that no response is received from the Steam Deck Controller device. Increasing the timeout or ignoring the timeout error does not resolve the issue. Changing the wValue in the control_transer functions seems to resolve the issue and is consistent with the value during USB communication while SteamOS is running.

Error:

Adding `Jovian Controller` device...
====>
00000000  ae 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
*
00000040
Traceback (most recent call last):
        9: from ./result/bin/Jovian-Controller:2:in `<main>'
        8: from ./result/bin/Jovian-Controller:2:in `load'
        7: from /nix/store/1isvmbzl8mdshy8j0r0pbxypv8qz46hh-Jovian-Controller-unstable-2022-04-15/libexec/jovian-controller.rb:125:in `<top (required)>'
        6: from /nix/store/1isvmbzl8mdshy8j0r0pbxypv8qz46hh-Jovian-Controller-unstable-2022-04-15/libexec/jovian-controller.rb:125:in `tap'
        5: from /nix/store/1isvmbzl8mdshy8j0r0pbxypv8qz46hh-Jovian-Controller-unstable-2022-04-15/libexec/jovian-controller.rb:126:in `block in <top (required)>'
        4: from /nix/store/1isvmbzl8mdshy8j0r0pbxypv8qz46hh-Jovian-Controller-unstable-2022-04-15/libexec/lib/steam_deck_controller.rb:262:in `get_serial'
        3: from /nix/store/1isvmbzl8mdshy8j0r0pbxypv8qz46hh-Jovian-Controller-unstable-2022-04-15/libexec/lib/steam_deck_controller.rb:244:in `send_message'
        2: from /nix/store/1isvmbzl8mdshy8j0r0pbxypv8qz46hh-Jovian-Controller-unstable-2022-04-15/libexec/lib/steam_deck_controller.rb:212:in `get_report'
        1: from /nix/store/6f3is280qllg5g2ma65r8hx8mmjf1m86-ruby2.7.6-libusb-0.6.4/lib/ruby/gems/2.7.0/gems/libusb-0.6.4/lib/libusb/dev_handle.rb:525:in `control_transfer'
/nix/store/6f3is280qllg5g2ma65r8hx8mmjf1m86-ruby2.7.6-libusb-0.6.4/lib/ruby/gems/2.7.0/gems/libusb-0.6.4/lib/libusb/dev_handle.rb:549:in `submit_transfer': error TRANSFER_TIMED_OUT (LIBUSB::ERROR_TIMEOUT)

Device Info:
Steam Deck 512GB Model
BIOS Version: F7A0108
Controller FW: Should be the latest as of 2022-08-20. I updated using jupiter-controller-update and now the tool itself no longer works or show the current controller version. (I'll have to look into this more).

Using Wireshark to debug Steam's USB communication, I changed the wValue to 0x0300 and that seems to fix the issue. The USB communication with SteamOS running fairly noisy so I wasn't sure what actual button/device inputs I was seeing but the wValue was consistently 0x0300 for Setup Data in the SET_REPORT requests. After changing the wValue, I can see all the currently supported inputs working in the verbose output and using evtest.

(Sidenote) I'm not sure how to utilize this service further; libinput seems to explicitly ignore gamepad devices so it's not visible in desktop environments such as swaywm. It appears another tool, sc-controller, has support for mapping gamepad devices (including the Steam Deck) to desktop commands but it would be nice to have a simple service for providing a desktop environment input. Does the intended use case for this service include general desktop environment input devices?

[samueldr]

(Sidenote) I'm not sure how to utilize this service further; libinput seems to explicitly ignore gamepad devices so it's not visible in desktop environments such as swaywm. It appears another tool, sc-controller, has support for mapping gamepad devices (including the Steam Deck) to desktop commands but it would be nice to have a simple service for providing a desktop environment input. Does the intended use case for this service include general desktop environment input devices?

For the moment it's aimed to be a "bog standard gamepad". E.g. using jstest-gtk you should see a gamepad that is sufficient for basic use. This was mainly an experiment to see how far I could go quickly, and I actually ended-up using it to play games outside of Steam.

The ideal goal would be to support any kind of customized control with the service. E.g. add support for (kinetic) mouse movements on the touch pads, be more useful as a generic desktop input device, etc. All of this through profiles you can switch using hand-waves some sort of IPC.

So to answer more succintly: right now it's a simple gamepad, but it's desirable to extend further.

[samueldr]

Hi! 👋 thanks for the contribution!

I will need to test the changes, but I suppose it's possible they're correct. It's entirely possible I typoed 0x3000. Though I wonder why it's working fine on my end.

Are you running the Jovian Experiments module on NixOS, and thus using the vendor (valve's) kernel?

[samueldr]

Huh...

• linux-jovian: 5.13.0-valve21 -> 5.13.0-valve24 Jovian-NixOS#19

A recent kernel update should make the current state of this repo unneeded. If it matters for your use case.

[Princemachiavelli]

Yes, I am running on NixOS using the Jovian Experiments module with the vendor kernel; I did update the module's kernel version so I'm using 5.13.0-valve22 (valve22-final2 GitHub tag) and still using the jupiter-20220624 linux-firmware.

I did test a stock 5.19 kernel and observed the same behavior (on 5.19 the biggest thing I noticed was the built-in audio device not working).

I'll have to checkout the 5.13.0-valve23 kernel. I should be able to test that pretty quickly.