protonscr

BPM: no controller detected (0666 permissions in /dev/input/eventX)

steamclosed reviewedGeneral controller / Steam Input
ValveSoftware/steam-for-linux#2995 · opened 2013-11-17 by ghost · updated 2017-10-30 · 15 comments · github
?ghost 2013-11-17 github

I know there have been a lot of people complaining about their controller not being detected in big picture mode, but in all the forum threads/bug reports/blog posts etc I've seen the problem was caused by bad permissions in /dev/input/eventX. That's not my case.

I'm trying to use an Xbox 360 controller in BPM (I've also tried with an old Saitek P880; it has the same problem). I'm running Steam in a 32bit chroot in Gentoo. I can cat /dev/input/event6 and /dev/input/js0 as any user, and it prints characters as I use the gamepad, both outside and inside the chroot. Some games I've tested work fine with the controller (And Yet It Moves, Stealth Bastard Deluxe, Shatter...). But not Steam.

Is there any way to find out why is it failing?

PPon3 2013-11-17 github

How did you run Steam as root?
Here, see /usr/bin/steam :

if [ "$(id -u)" == "0" ]; then
show_message --error $"Cannot run as root user"
exit 1
fi

?ghost 2013-11-17 github

You misunderstand. I don't run Steam as root, but inside a chroot. I have a non-multilib 64bit Gentoo. I have to run Steam inside a 32bit chroot because I don't have 32bit libraries in my main system.

Anyway, everything works fine inside the chroot (including the games I mentioned with gamepad support), so it should not have any influence in the gamepad detection by Steam.

PPon3 2013-11-17 github

Oh, sorry.
Chroot has a poor interaction with external devices such as a network, usb controllers...

?ghost 2013-12-10 github

No, it doesn't help. The only solution in #2092 is permissions-related, and as I stated (in the bug title!) I already have read and write permissions in the eventX device.

Ggabomdq 2013-12-10 github

Did you bind /proc, /dev, /sys to your chroot? If so, it may be a problem with udev, try running "udevadm monitor --environment" inside your chroot, plug and unplug the joystick and see what you get.

?ghost 2013-12-15 github

Yes, I bind /proc, /dev, /dev/pts, /dev/shm, /run/dbus and /sys in the chroot. But I don't have udevadm (or anything udev-related) inside the chroot, just outside (/dev is managed by the 64bit system, not the 32bit system in the chroot). Can that be a problem? Shouldn't steam just try to open /dev/input/eventX, no matter what dev managing system is installed?

Ggabomdq 2013-12-16 github

udev is used by SDL and in consequence by Steam to detect joysticks. If udev is not working, your joystick won't be detected (and I think udev needs access to the system wide database to work properly)

?ghost 2013-12-18 github

Ok. I thought SDL was "dumber" and just looked for event devices in /dev/input instead of asking udev/dbus for them. I'll try to get udev working inside the chroot then.

Fforesto 2014-07-31 github

The permissions set by udev on /dev/input/event* are indeed a problem on many systems, but for some of us, Steam's Big Picture still says "no controller detected" after the permissions have been fixed. Alexey Loukianov did an outstanding job of investigating, and posted details in #1894.

In short:

  • Steam detects game controllers using libsdl, which uses libudev to find the appropriate /dev/input/event* device file. (It ignores /dev/input/js0.)
  • Steam ships its own version of libudev; one that is incompatible with the the version of udev that runs on many modern linux distributions, so it can't find the /dev/input/event* device file it needs. (Meanwhile, other SDL applications on the same system handle game controllers just fine.) This is a problem that really ought to be fixed.
  • As a temporary workaround, you can figure out which /dev/input/event* file corresponds to your gamepad, manually make it readable, and set the SDL_JOYSTICK_DEVICE environment variable to that file's path when launching Steam. Something like this: env SDL_JOYSTICK_DEVICE=/dev/input/event18 steam
Ssonicnkt 2014-09-10 github

Hey the "env SDL_JOYSTCK_DEVICE" Solution works for me, couldnt get my gamepad working before.
Now i wonder if theres a way to get more than one gamepad detected for local multiplayer games this way?

Fforesto 2014-09-10 github

sonicnkt, have you tried putting a list of /dev/input devices, separated by : characters, in the environment variable? env SDL_JOYSTICK_DEVICE=/dev/input/event18:/dev/input/event19

Ssonicnkt 2014-09-10 github

wow didnt think it was that easy :)
thanks for the help

Kkisak-valve maintainer 2017-09-29 github

Hello, is anyone still experiencing this issue with an up to date system?

Kkisak-valve maintainer 2017-10-30 github

Closing pending feedback.

Launch options

Upstream links