Controller not detected or partially detected

[notklaatu]

Game information

Steam client

Distribution name and version where applicable

Tested on:

• Red Hat 8.2
• Slackware 14.2

Flatpak info

$ flatpak --version
Flatpak 1.6.2
$ flatpak --gl-drivers
default
host

Problem description

1. Attach controller (I have Logitech f310 and f370).
2. Start Steam.
3. On RHEL 8.2, controller is not detected
4. On Slackware 14.2, the client detects the controller but no game does.

I can confirm in both cases that lsusb detects the controller in both Xinput and Direct Input modes.

I can also confirm that this issued appeared sometime in February. Everything was working as expected in late January (I know because I was playing Bioshock Infinite, a native Linux game).

Does this issue reproduce with native Steam

No. Controllers work on native Steam (I've resumed playing Bioshock Infinite in the native client, and controller's working as expected).

Yes, I tried installing a udev rule to ensure Flatpak had access:

$ sudo head -n2 /etc/udev/rules.d/60-steam-input.rules
# Logitech f310
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", MODE="0660", TAG+="uaccess"

[TiZ-HugLife]

Try this horrible hack:

sudo flatpak override --filesystem=/run/udev com.valvesoftware.Steam

[notklaatu]

Thanks for the idea.

That doesn't appear to work. Could be a separate issue, maybe, but my test machine that still has Steam installed as a Flatpak now can't see the controller at all (in the Steam client or in a game). I'll have to test on a different system and post more definitive results here.

[RobOT05442309]

Hello,

After switch few month ago to the Steam flatpak, I had the same or similar issue:

• Controller was detected by Steam (I was able to see them in the "controller" settings of any game properties).
• Controller was not detected in game

I have a Xbox 360 wireless dongle to connect my controllers (1 to 4 controllers at the same time).

After digging a lot, I manage to found an "acceptable" workaround for me (I don't really know what it implies in term of data "leak" from the OS to the flatpak, if someone want to explain, I'll be happy to know what this workaround allow the flatpak build to access):

In Flatseal, I add: /dev/uinput:ro

I think a readonly mode to /dev/uinput is way more acceptable than /run/udev in read/write.

This is my whole Flatseal custom overrides rules:

[Context]
filesystems=!xdg-music:ro;!xdg-pictures:ro;!xdg-run/app/com.discordapp.Discord:create;/dev/uinput:ro;xdg-config/MangoHud:ro;
persistent=.local/share/Steam/compatibilitytools.d

Hope this could help !

Edit: I run Fedora 35 Workstation (Gnome)

[nanonyme]

That persistent thing is probably not necessary

[RobOT05442309]

I agree that there might be a better way of getting things to work but it seems there was no real/permanent solution when I was trying to make things to work (I check few month back so things might have evolve since).

I know this is not ideal and defeat partially the purpose of the sandbox but (feel free to correct me if I'm wrong) I assume that it couldn't be worst than installing official Steam Client as it will get access to it anyway and maybe with the right to write instead of read only and other things that the Steam flatpak build will prevent and block.

That beeing said, I would love to had a better/clean alternative to this /dev/uinput and get my controller to be detected on any native/proton games if someone has a real and effective solution on this kind of issue.

[nanonyme]

The app already persists everything so that rule should be no-op.

[nanonyme]

I did not comment on filesystem section, only persistence

[RobOT05442309]

My bad, I misunderstood your sentence, I didn't know that the "persistent" section with a single dot means "everything", I was thinking it will allow me the automatic creation of directories inside the sandbox on first launch of the flatpak app, just like the same thing "xdg-pictures/Steam:create" will do on the real user home. Thanks for the clarification !

[nanonyme]

Naw, everything else in list seems reasonable. I would be really happy if there are useful tested ways to tighten the /dev part of sandbox.

[FilBot3]

I just tried the --filesystem=/dev/uinput:ro thing. I have a big long Gist about most of this.

• https://gist.github.com/FilBot3/a814ca47c76ea04a866fa97597ad7b85

Hopefully that helps shine some light. I got console logs from when Steam launched to when the game launched and didn't recognize the controllers.

[RobOT05442309]

I just realized that I forgot that I use several more tweaks to get controller working with Steam but this wasn't related to the flatpak version (while I was using Ubuntu before switching to Fedora) and I still use them now with the Flatpak Steam.

This is related to how you use Steam (Classic mode or Big Picture), go into your game settings > controller:

• When using Steam in Big Picture mode, change "Use default settings" to "Enable Steam input"
• When using basic client mode, change "Use default settings" to "Disable Steam input"

This workaround was for some issue happening in the official client and make my controller works under proton for some Unity related games (Overcooked).

In any configuration official client or not, I installed the following package from distro repo using apt in Ubuntu or dnf in Fedora:

• steam-devices

For Fedora and Steam Flatpak, I use the following command for gaming related stuff:

From official repository: sudo dnf install -y goverlay gamemode mangohud vkBasalt steam-devices

From flathub (or fedora flatpak repository): flatpak install org.gnome.Platform.Compat.i386 org.freedesktop.Platform.GL32.default org.freedesktop.Platform.GL.default

Note that I use Nvidia drivers (I don't know if the GL things is related or not to GPU). I installed "org.gnome.Platform.Compat.i386" since I was trying to use lutris Flatpak once and I noticed several issues related to gaming using flatpak required this additionnal library so I keep it into my install guide.

Last thing I've notice was with Valheim (I know there is a native build, I just like the way proton work with the compatdata folder work and backup manually game "save" related things) that has the following issue with controller, difference between Steam official and flatpak using the following settings:

• Use Steam client classic interface (no Big Picture)
• Forced proton version 5.13

• Disable steam input from game settings > controller

  With Steam official client:

  • Running official proton 5.13 (game was working great with this build), my controller has to be powered on before launching the game (otherwise not detected).
  • I use wireless Xbox 360 controller, if battery died when the game was running, it was impossible to get it back in game, had to quit and restart game, that was a pain.

  With Steam flatpak build:

  • Running with official proton 5.13, my controller was not detected at all, the only way to get it detected was to use proton 6.3 or 7.0, any proton version under 6.3 does not seems to pass the controller to the game.

  This issue is Valheim + proton game specific, I did not have the issue with other game not detected controller under proton 5.13 or previous in the Steam flatpak build.

I would love to have a feedback on this if someone has Valheim and can confirm the same issue happen when using it with proton 5.13 and get no controller at all while switching to 6.3 or 7.0 make it work.

Hope this can help to debug/make controller work for someone.

[fastoslinux]

I have a "PowerA XBX Spectra Enhanced Wired Controller" that seems to be recognized in Steam logs and settings: Local Device Found type: 20d6 4002 path: sdl://0 serial_number: - 0 Manufacturer: Product: PowerA Spectra Infinity Controller Release: 101 Interface: -1

But only the RT button is not recognized by games. Mapping configuration on Steam recognizes but does not save.

With SDL_JOYSTICK_DEVICE=/dev/input/js0 %command% games recognize RT, but I lose force feedback.

I tested it with Steam .rpm in toolbox f37, and the RT is recognized without problems.

obs: other flatpak's like jstest-gtk, YUZU and PCSX2 recognize everything normally.

[carlosvalin94]

Any progress on this?