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

Does not seem to work on a Raspberry Pi 4 #3

Closed
wmarler opened this issue May 27, 2020 · 7 comments
Closed

Does not seem to work on a Raspberry Pi 4 #3

wmarler opened this issue May 27, 2020 · 7 comments

Comments

@wmarler
Copy link

wmarler commented May 27, 2020

Hey Rodrigo,

I'm testing on a Raspberry Pi 4 with RetroArch. I configured the Steam Controller as I described in https://retropie.org.uk/forum/topic/26254/steam-controller/9. I'm able to map a bunch of buttons, so it seems like while EmulationStation is running, your driver is working as described ("This driver will disable the lizard mode when the input device is opened and re-enable it when the input device is closed").

The trouble is, the emulators I've tried have all failed to recognize the Steam Controller properly -- I think the device is staying in lizard mode. So I thought I'd test that first via steamctrl disable_keys_cursor but it doesn't seem to be doing anything. I get no output on the command line, and no changes in controller behavior. So I tried just getting the serial number and ... no output. I did check the exit code via $? (and strace), and it's 0.

My conclusion is that steamctrl is unable to find the Steam Controller on the RPi. But ... I don't know what I'm doing :-p..

Here is the output of strace steamctrl get_serial if it helps.

I ran gdb too, but i didn't get anything useful:

pi@George:~ $ gdb steamctrl
GNU gdb (Raspbian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from steamctrl...done.
(gdb) run get_serial
Starting program: /usr/local/bin/steamctrl get_serial
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[Inferior 1 (process 2920) exited normally]
(gdb) run led 1
Starting program: /usr/local/bin/steamctrl led 1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[Inferior 1 (process 2933) exited normally]
(gdb) quit

Since hid-steam is not yet packaged as part of the raspberry pi kernel binaries, in order to test on a Pi you have to build the kernel yourself (or use pi-update, but that'll take you to the rpi-5.4.y kernel branch and the stable kernel branch is 4.19). Since RetroArch uses the stable kernel tree I figured I would too, and built 4.19 from the default branch; It's very easy with the step-by-step instructions. Takes about 30 mins to cross-compile on an Intel CPU.

@rodrigorc
Copy link
Owner

As it happened, I asked for hid-steam to be enabled in the default RPi kernel in this issue, and it was finally there in kernel 4.19.106.

Anyway if you do not have the latest kernel revision you do not need to compile the whole kernel; you can compile this driver out-of-tree, and even in the RPi itself it will take just a couple of minutes. Something like this:

$ mkdir steam-build
$ cd steam-build
$ wget https://raw.githubusercontent.com/raspberrypi/linux/rpi-4.19.y/drivers/hid/hid-steam.c
$ wget https://raw.githubusercontent.com/raspberrypi/linux/rpi-4.19.y/drivers/hid/hid-ids.h
$ echo "obj-m += hid-steam.o" > Makefile
$ make -C /lib/modules/`uname -r`/build/ M=$(pwd)
$ sudo make -C /lib/modules/`uname -r`/build/ M=$(pwd) modules_install

You just need the GCC compiler and the linux-headers package.

About why steamctrl do not detect your device, maybe you are not running as root? By default access to the /dev/hidraw* is restricted to root. In a PC desktop you are likely to have the Steam Client, that install a few udev rules that change these /dev/hidraw* to be usable by the interactive user, so that the Steam Client does not have to be run as root.

But looking at your strace, it looks like permissions are not a problem:

openat(AT_FDCWD, "/dev/hidraw1", O_RDWR) = 3

Other possibility is that the latest firmware has a bug that makes the device reboot itself every 10 seconds or so, if no application or kernel driver is using it. You'll notice that because there is a beep every few seconds. You can prevent the controller from rebooting just reading from the hidraw* device:

$ cat /dev/hidraw1 > /dev/null &

And then you can try the streamctrl getserial again. You can check which hidraw* is yours by using steamctrl -v.

Let me know if this makes a difference.

@wmarler
Copy link
Author

wmarler commented May 27, 2020

Thanks for the instructions on building the kernel module! I had tried building it just by itself on the RPi, but not knowing what I was doing, I couldn't get the Pi to accept that the module was built (modprobe/insmod would fail saying that the hid-steam module didn't exist). I spent about 45 minutes on it before just building everything.

On my RPi I have raspberrypi-kernel 1.20200212-1 package installed, and apt update doesn't find a newer version. Prior to me builing the kernel myself, my uname -r was 4.19.97-v7l+ ... too early for the hid-steam driver.

Ok, now for some testing. steamctrl -v was useful! (Side feature request: add "-v" to the list of arguments displayed when running "steamctrl -h")

pi@George:~/steamctrl $ steamctrl -v
Probing /dev/hidraw1...
Found device 'FC55221294' at /dev/hidraw1
Device '/dev/hidraw1'

Now I can reliably get the serial when I pass steamctrl the -d /dev/hidraw1 device. If I omit it, I get nothing though:

pi@George:~/steamctrl $ steamctrl -d /dev/hidraw1 get_serial
FC55221294
pi@George:~/steamctrl $ steamctrl get_serial
pi@George:~/steamctrl $

steamctrl does not appear to have any effect on the controller... in emulation station I can press A to select a menu item and B to cancel, but then when I start a game, the A and B buttons don't do the A and B button actions. If, while in-game, I run steamctrl -d /dev/hidraw1 disable_keys_cursor I get a popup relating to controller activity, but it doesn't change the behavior of the buttons. I can't be sure where the disconnect is; with steamctl, hid-steam, or the game emulator. I'm shying away from the latter as it's consistently not working across multiple emulators.

That said, you have a Pi, and you have a SteamController ... you're only about 2 steps away from testing in RetroPie with EmulationStation. Maybe you can tell?

Another test is steamctrl led X. This should be reproducible by you: it has no effect when I run it. steamctrl doesn't give any feedback (though I'm not sure it's supposed to, per se). Also of note, steamctrl doesn't find the device when I specify to search by serial number:

pi@George:~/steamctrl $ steamctrl -d /dev/hidraw1 disable_keys_cursor
pi@George:~/steamctrl $ steamctrl -d /dev/hidraw1 led 10
pi@George:~/steamctrl $ steamctrl -s FC55221294 led 10
Steam Controller not found

@rodrigorc
Copy link
Owner

So... you are using the wireless adaptor, I didn't notice before. That makes things tricky.

Can you try to work with a cable?

Also, the hid-steam.ko driver had a bug, that made the wireless SC practically unusable. It was fixed a while ago, and even got backported to 4.19. Can you check whether your kernel has this patch? If not, can you patch and recompile?

If nothing helps, I've added an extra option to steamctrl to make it extra verbose, with -vv (properly documented this time). Please try running steamctrl -vv get_serial and posting the output.

@wmarler
Copy link
Author

wmarler commented May 28, 2020

I connected with wire, and EmulationStation detected it as "Steam Controller" (v. "Steam Controller Wireless"). I mapped all the buttons. There was no difference, as far as I could tell, with the behavior of the SC when it was wired v. when it was wireless (it worked great in EmulationStation, when I started an emulator it would not send the proper A and B button commands, and steamctrl disable_keys_cursor did not disable the keyboard behavior -- testing with updated steamctrl).

My kernel hid-steam.c has the patch you mention. md5sum of hid-steam.c is 32b0be1d510642815e5962841d03acc3

I pulled the latest steamctrl source, and rebuilt it. Here is the output of get_serial when the SC is connected with a cable, as requested:

pi@George:~/steamctrl $ steamctrl -vv get_serial
Probing /dev/hidraw2...
Device '/dev/hidraw2'
Running command 'get_serial'
HID-SET: ae 15 01
HID-GET: 00 ae 15 01 46 43 35 35 32 32 31 32 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FC55221294

Here's the output of disable_keys_cursor (when connected with the wire):

pi@George:~/steamctrl $ steamctrl -vv disable_keys_cursor
Probing /dev/hidraw2...
Device '/dev/hidraw2'
Running command 'disable_keys_cursor'
HID-SET: 81
pi@George:~/steamctrl $

Btw, when I was testing with the wire, I'd unplug the Wireless dongle.

@rodrigorc
Copy link
Owner

You have the latest hid-steam.c, great!

About disable_keys_cursor not working, I think that is expected if you are using the kernel driver, because as soon as the /dev/hidraw* device is closed, the kernel driver takes over and switches the mode according to the lizard_mode parameter.
Remember that you can change the kernel parameter when you load it, but also at any time by writing Y/N to /sys/module/hid_steam/parameters/lizard_mode.

As they are, the steamctrl -vv you pasted are all correct. What I would like to see is the steamctrl -vv of a command that does not work, such as that get_serial with the wireless.

And maybe I will install EmulationStation in my RPi this weekend and see for myself...

@wmarler
Copy link
Author

wmarler commented Jun 6, 2020

The problem with the Steam controller being recognized by EmulationStation but not being recognized by the various emulators is not a problem with the hid_steam driver or the steamctrl utility. It is a configuration in RetroArch. One has to tell RetroArch to map the "Wireless Steam Controller" to the RetroArch "virtual controller" connected to a "virtual port". The hid_steam driver actually performs quite well, being detected and re-detected through numerous power cycles.

Basically I think everything I said earlier can be put to bed, except for the command steamctrl led 10. I'm not able to turn the brightness of the LED down using steamctrl. Does it work for you on your RPi? I'm testing via wireless; and ... really am only interested in the wireless use case, so if the wire is a requisite, then I'll manage (strategically shaped piece of electrical tape ...). Below is the output of the command with -vv (and sudo, just to double show it's not a permissions issue):

pi@George:~ $ steamctrl -vv get_serial
Probing /dev/hidraw1...
HID-SET: ae 15 01
HID-GET: 00 ae 15 01 46 43 35 35 32 32 31 32 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Found device 'FC55221294' at /dev/hidraw1
Device '/dev/hidraw1'
Running command 'get_serial'
HID-SET: ae 15 01
HID-GET: 00 ae 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
pi@George:~ $steamctrl -d /dev/hidraw1 led 10
pi@George:~ $ sudo !!
sudo steamctrl -d /dev/hidraw1 led 10
pi@George:~ $ sudo steamctrl -d /dev/hidraw1 -vv led 10
Device '/dev/hidraw1'
Running command 'led'
HID-SET: 87 03 2d 0a 00
pi@George:~ $

@rodrigorc
Copy link
Owner

Yes, I noticed that also in the RetroArch, that I tried installing into my RPi. It looks like every layer in the menus has its own input configuration... weird.

Going back to steamctrl this behavior is really strange, my controller never did this. Note how the first time you send the command "ae 15 01" (get_serial) it replies ok, but the next time it just replies with all zeroes. It it were an error, it would have retried the command, but there is no error, just zeroes, as if the controller and the wireless dongle were disconnected.

Compare how my controller replies to this command:

HID-SET: ae 15 01
HID-SET Feature failed (32), retrying...
HID-GET: 00 ae 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

and then it retries and gets the correct answer. But in your case there is no error, so no retry, I don't understand why.

About the led command, I noticed that it happens to me too, using the wireless connection. But even the Steam Client is unable to change the led brightness with the wireless, so I'm guessing that it is a limitation (bug?) in the device firmware.

Anyway, I would like you to do a couple tests, if you are willing...

  1. Run steamctrl -vv get_serial many times. Does it always give the same output?
  2. Can you connect the controller and the dongle to a PC with the Steam Client and check the firmware version? Just go to "Controller Settings" and click on the "Detected controller: Steam Controller". If you use the wireless dongle you will get one version for the controller and one for the receiver.

@rodrigorc rodrigorc closed this as not planned Won't fix, can't repro, duplicate, stale Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants