Same on fedora 42

There were a lot of updates for Debian/testing as well as a steam client update and now the steam controller is working again in aperture desk job. Unfortunately it still doesn't work in other games I tried (Titan Quest II, Hollow Knight and Silksong).
I've no idea how to track this down. Searching other posts/bug reports didn't help either. In other cases the controller usually don't work at all, which isn't the case here.

I'm facing this issue on the Steam Deck OLED runing CachyOS after the systemd v258 update. Downgrading systemd (systemd-libs lib32-systemd systemd mkinitcpio systemd-resolvconf systemd-sysvcompat) fixes this.

steam-logs.tar.gz

can confirm the smae issues as @Revival8697 with the same fix for me.

Running Cachy OS, controllers tested were two different dualsense, razer wolverine v2 and elite 2. The only controller that would work for me is a wired sn30pro fron 8bitdo.

I could reproduce this on my LCD Deck with systemd v258, main relevant snippet from my Steam console log seems to be:

[2025-09-18 12:36:43] Couldn't initialize virtual gamepad: Couldn't open /dev/uinput for writing

which is also present in @at46 and @Revival8697's steam logs

met the same problem on archlinux. But it is very hard to downgrade systemd to have a test. :(

Possibly related to this change?
https://github.com/systemd/systemd/blob/v258/NEWS#L22-L32

I do not have any hardware to test, so can not reproduce...

I think that makes sense looking at https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules

@matte-schwartz Does Steam create any kind of virtual input device when using Steam Input for games?
My controller works fine in a game if I disable Steam Input for that game.

Also, the OP mentioned:

I can use Big Picture Mode or test the input in the settings and everything works as expected.

So I don’t think this issue is related to the rules for physical devices.

Having the same issue, when I did a system update on cachyos, that included systemd updates.

If you run this command it will work right til reboot.
sudo chmod 666 /dev/uinput

Does an upstream systemd issue exist for this? Anybody want to open one?

OK, although there is

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

in https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules
But we cannot access /dev/uinput as a non-root user.

Does it help if you add the ACTION to your rule?

ACTION!="remove", ...

@eworm-de no. I added a 99-xxx.rules in /usr/lib/udev/rules.d with

KERNEL=="uinput", ACTION!="remove", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

But still

crw------- 1 root root 10, 223 Sep 19 10:00 /dev/uinput

And cannot work in games.

The default access mode of tty/pts device nodes has been changed to 0600

Thanks systemd, for protecting me from myself.

sudo chmod 666 /dev/uinput

I guess we can add MODE="0666" to the rules, so:

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0666", TAG+="uaccess", OPTIONS+="static_node=uinput"

It is technically insecure though, so not a long term solution.

@eworm-de no. I added a 99-xxx.rules in /usr/lib/udev/rules.d with

Possibly 99- is too late and the rule is not hit at all?

My Arch desktop worked fine with controllers last night, but this morning the systemd update came through and none of my games worked with my controller no matter what settings I tried to change or how many times I power cycled my computer. Either rolling back systemd update or chmod 666 uinput fixed the issue for me so definitely a result of that update somewhere.

My controller is an 8bitdo Ultimate 2c.

I installed game-devices-udev from the AUR and rebooted, seems to have fixed the problem for me! Would recommend others see if those rules work for them as well.

I installed game-devices-udev from the AUR and rebooted, seems to have fixed the problem for me! Would recommend others see if those rules work for them as well.

can confirm this also fixed the issue for me

I created a commit that update's the UDEV input rules to add ACTION!="remove", as required by systemd 258 for uaccess.

I would not recommend doing a chmod to any dev devices manually.

I am going to create a pull request on arch's steam package to add this. Who knows how long and even if Valve will respond to this

@HurricanePootis that does not fix the issue though, I tried the same thing earlier on Steam Deck and it made no difference.

@matte-schwartz Are you using systemd 258 on the steam deck? systemd 258 has the following change log related to uaccess tag:

        * ACLs for device nodes requested by "uaccess" udev tag are now always
          applied/updated by systemd-udevd through "uaccess" udev builtin, and
          systemd-logind no longer applies/updates ACLs but triggers "change"
          uevents to make systemd-udevd apply/update ACLs. Hence, the "uaccess"
          udev tag should be set not only on "add" action but also on "change"
          action, and it is highly recommended that the rule is applied all
          actions except for "remove" action.
          Recommended example:
              ACTION!="remove", SUBSYSTEM=="hidraw", TAG+="uaccess"
          The following example does not work since v258:
              ACTION=="add", SUBSYSTEM=="hidraw", TAG+="uaccess"

Edit: I don't have my steam controller on me as a I type, but I will go get it and do a sanity check. I did test my commit via udevadm verify.

Yes, I'm using systemd v258 on Steam Deck. I tried the same thing you did and it did not fix Steam Input on the Deck's controller. made sure to reload udev rules and everything, same with rebooting.

After installing the new udev rules and restarting my laptop, I can use my steam controller to play the native version of Silk Song using steam input. Therefore, my udev rules did fix it.

@matte-schwartz Looking at the /usr/lib/udev/rules.d/60-steam-input.rules, I don't see anything that mentions steam deck controller stuff. Maybe steam distributes a separate udev rule file for the deck?

Btw, I am running Arch Linux. Not cachyos, not manjaro, not endevour or whatever other fork people want to use.

Edit: the ball is in Valve's court now to release a new steam client version with the new udev rules. The new changes should also be valid and work with older systemd versions. If anyone from valve is reading, show your udev rules some love.... (and maybe add the switch 2 joysticks/controller to them???)

It counts as a Valve controller since it has the same vendor ID, but I do wonder if it's possible there are two separate issues here that both hit with systemd v258.

At least for the Steam Deck, I looked at game-devices-udev on the AUR, and the reason it's "fixing" the Steam Deck controls is actually because it adds uinput to modules-load.d. even without installing the package, you can simply add uinput to /usr/lib/modules-load.d/uinput.conf and it'll work after rebooting.

@matte-schwartz Do you know if the steam deck uses USB for its controllers? Maybe its using I2C or another embedded protocol.

Regardless, my pull request fixes the issue for me on the steam controller (via the usb dongle).

Edit: If it wasn't clear, I don't have a steam deck ( 🙁 )

@matte-schwartz Can you actually show me what the usb product id and vendor id is for the steam deck? It is possible that valve is using a different USB vendor ID if the steam dock does indeed use usb.

Bus 003 Device 002: ID 28de:1205 Valve Software Steam Deck Controller

Welp, it does indeed have the same 28de vendor ID as other steam products. To be honest with you, if the udev rule 60-steam-input.rules was giving the steam client access to your steam controller before the systemd v258 update, then this change should make it work after the update. This change should even work with older systemd clients, as the only thing this changes is telling udev to not run this rule whenever the device is removed.

The only thing changed is that instead of systemd-logind applying the uaccess tag to devices, systemd-logind sends events for systemd-udevd to do the uaccess tagging. Therefore, there needs to be an ACTION!="remove" so that systemd-logind gets the trigger on both add and change events.

Thread where they came up with the same answer matte-schwartz did.
https://discuss.cachyos.org/t/proton-controller-support-broken-in-the-last-few-days/11824/15

I looked around after I-Percy said game-devices-udev on the AUR fixed it. Came here to post about it, but matte-schwartz got it 30mins early lol. Anyway here is steps to troubleshoot/fix.

1. Check if uinput is running
   lsmod | grep uinput

2. If no output is returned, load uinput through modprobe
   sudo modprobe uinput

3. Set a module configuration file to load uinput on startup (to avoid Steam Input not working again):
   sudo echo 'uinput' > /etc/modules-load.d/uinput.conf

Not sure which piece of software need to package the "fix" or if it is the best way to do it.

@TheRealYasri thanks, works great (Debian Forky) :

sudo modprobe uinput 
echo 'uinput' | sudo tee /etc/modules-load.d/uinput.conf

Not sure which piece of software need to package the "fix" or if it is the best way to do it.

Steam needs to do it since these files are distributed by steam

1. Check if uinput is running
   `lsmod | grep uinput`

2. If no output is returned, load uinput through modprobe
   `sudo modprobe uinput`

Works fine for me also. Thanks for this workaround.

Not sure which piece of software need to package the "fix" or if it is the best way to do it.

Steam needs to do it since these files are distributed by steam

Half / Half not? Package managers will be the ones to decide to put the updated version depending on the systemd version of their distro.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/12310#issuecomment-3314817496

I am fairly confident that the required changes is backwards compatible with older versions of systemd

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/12310#issuecomment-3314818533

On my case at least. Desktop system, Arch, using a DualSense with USB. I updated the udev rules with the ones on your PR, rebooted and nothing until I also loaded sudo modprobe uinput

I'm not familiar with that module

From my testing:

I'm not sure if all is related to Systemd 258. But the 13/14 weekend everything worked fine (ArchLinux and DualSense using USB).
Now gamepads aren't wortking

Using the @HurricanePootis new UdevRules, if the game has full support for gamepad (Game can handle it without requiring Steam Input) it will work.

For those games that require Steam Input, I need to load the uinput (Is this supposed to be loaded automatically and now has stopped?)

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/12310#issuecomment-3314831660

As a clarification, I tested the new udev rule on hollow knight silksong's native Linux client. I also usually run the envar STEAM_COMPAT_RUNTIME_SDL2=ON, so unity uses a newer sdl2 library from the steam runtime. Maybe my new rules fixes applications from accessing the controllers via the non-hidraw interface? But, I thought steam controllers on linux and on steam always use steam input? It's a confusing situation with how the steam controller is handled, for me.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/12310#issuecomment-3314841725

As far as I undertand (But could be wrong) if the game can handle the detected gamepad by itself, Steam Input gets disabled, since it will basically emulate a Xbox gamepad and if for example playing Space Marine 2, since the game supports the DualSense specific features, using Steam Input will limit it to the basics.

Some other games with basic gamepad controlls may chose to rely on Steam Input so it just works on a basic level.

I had the same problem with my ds4 controller. I needed to change my udev rules (/etc/udev/rules.d/72-ds4tm.rules) with the new systemd change to:

ACTION!="remove", KERNEL=="hidraw*", KERNELS=="*054C:09CC*", MODE="0660", TAG+="uaccess"
ACTION!="remove", KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="09cc", MODE="0660", TAG+="uaccess"

(This was the easiest but, still not working with steam input)

And I also needed to load the uinput 😅 And... I arrived here and found out!

Thank you all for this solution!

https://github.com/systemd/systemd/commit/c960ca2be1cfd183675df581f049a0c022c1c802 this seems to be the commit that made uinput no longer loaded after bootup on Deck

Same on fedora 42

fedora 42 is still on systemd 257 (currently as of 9/21):
https://src.fedoraproject.org/rpms/systemd

the offending commit is in 258:
https://github.com/systemd/systemd/commit/c960ca2be1cfd183675df581f049a0c022c1c802

I am not hitting this issue on fedora 42/nobara with systemd 257. I would double check to verify your issue is not something different.

~~I'm not sure how else you would fix this in the Steam udev rules other than kmod loading uinput in there now. it still does not get loaded with the recommended syntax in the news article, and systemd insists this is not a bug https://github.com/systemd/systemd/issues/39043#issuecomment-3315385189~~

Logind bug confirmed: https://github.com/systemd/systemd/issues/39043#issuecomment-3315790735

A Cachy update today looks to have fixed it.

I had installed game-devices-udev which did the trick, but the OS update failed because it said that package had a file locked. So it must have changed something for good.

Removed that package, rebooted, did the update, rebooted, all back to normal for me

CachyOS implemented a workaround of adding uinput to modules-load.d, the core issue is still there

I think I'm experiencing this too but with a PS4 controller and only non-steam games are affected.

Edit: either the new Proton experimental fixed this or sudo modprobe uinput did because now it's working.

there was a fix merged into systemd this morning to fix the missing uinput module loading:

https://github.com/systemd/systemd/pull/39071

It looks like Arch Linux pulled it into their systemd package for their next rebuild (probably 258-4): https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/commit/ba836b0f3e60fdf1dffad965bc0cfd2c4a68ae70

It looks like Arch Linux pulled it into their systemd package for their next rebuild (probably 258-4)

Yes, just waiting for another fix to be merged before pushing the package.

Edit: either the new Proton experimental fixed this or sudo modprobe uinput did because now it's working.

Thank you! This command made it work for me. My classic SNES like Buffalo USB and the 8bitdo Ultimate 2 Wireless controllers stopped working in Steam games (but otherwise working fine), regardless of any Steam Input setting. Probably after my Archlinux system update. Nothing else worked. And I can confirm its not Proton, because I did not update any Proton yet (current datacap problems).

Edit: either the new Proton experimental fixed this or sudo modprobe uinput did because now it's working.

Thank you! This command made it work for me. My classic SNES like Buffalo USB and the 8bitdo Ultimate 2 Wireless controllers stopped working in Steam games (but otherwise working fine), regardless of any Steam Input setting. Probably after my Archlinux system update. Nothing else worked. And I can confirm its not Proton, because I did not update any Proton yet (current datacap problems).

No problem but I was really just copy/pasting what other people had said. Github should really add a reply highlight feature so temporary issue workarounds get visibility because I had to uncollapse a bunch of comments to even see it.

The fix has landed today on Arch with systemd 258-4

I'm having pretty much the same issue with an Xbox controller, and I noticed this around September 16th.
Steam big picture works, steam input and the overlay work, the linux native version of BeamNG.drive works, but any game running through proton doesn't.
I have systemd updated to version 258-4, but my controller is still not getting recognised by proton games.

im still having the issue of having to manually load in uinput after each restart for steam input to properly work, on systemd-258-4, on arch linux

what is the intended/"correct" solution to this? do i need to just add uinput module on startup?

@zeparu afaik those commits in systemd were the intended fix. What controller are you still seeing the issue with?

im still having the issue of having to manually load in uinput after each restart for steam input to properly work, on systemd-258-4, on arch linux

what is the intended/"correct" solution to this? do i need to just add uinput module on startup?

Thats for steam input. For native controller you have to update the udev rules file manually for now

the issue specifically happens with my 8bitdo ultimate 2 wireless, on binding of isaac rebirth (through proton)

I'm having pretty much the same issue with an Xbox controller, and I noticed this around September 16th. Steam big picture works, steam input and the overlay work, the linux native version of BeamNG.drive works, but any game running through proton doesn't. I have systemd updated to version 258-4, but my controller is still not getting recognised by proton games.

im still having the issue of having to manually load in uinput after each restart for steam input to properly work, on systemd-258-4, on arch linux

what is the intended/"correct" solution to this? do i need to just add uinput module on startup?

What I posted above should fix it for you. Github minimized the post. https://github.com/ValveSoftware/steam-for-linux/issues/12310#issuecomment-3314625037

Anyway here is steps to troubleshoot/fix.

1. Check if uinput is running
   lsmod | grep uinput
2. If no output is returned, load uinput through modprobe
   sudo modprobe uinput
3. Set a module configuration file to load uinput on startup (to avoid Steam Input not working again):
   sudo echo 'uinput' > /etc/modules-load.d/uinput.conf

None of the settings worked for me. After I updated to Gnome 49 Archlinux, where Xorg was disabled, the only game that works perfectly is Monster Hunter Wilds. In other games, Steam recognizes it, but it doesn't work in the game. My controller is wired.

Debian testing finally got a systemd update to 258.1 and with that everything is working again for me.

Not sure if it’s the same issue or if I should open a separate one but I’m having exactly the same problem only with non-steam games launched through Heroic Games Launcher (flatpak release) specifically when Freedesktop runtime 24.08 or newer is used by the Flatpak package.

Issue happens on both, my Steam Deck and a desktop PC, both running SteamOS 3.7.15.

I verified that uinput kernel module is loaded and also that Steam Input is working as expected with Steam games.

Any ideas?

edit: also checked /dev/uinput permissions which by default are crw-rw----+ 1 root input 10, 223 nov 2 15:18 /dev/uinput and tried crw-rw-rw-+ 1 root input 10, 223 nov 2 15:18 /dev/uinput to no avail.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/12310#issuecomment-3478014362

My friend, I solved a problem; it was the Proton version. I was using the beta version, and the stable version is version 9, and it started working again.

My friend, I solved a problem; it was the Proton version. I was using the beta version, and the stable version is version 9, and it started working again.

Are you talking about the same scenario I'm describing (non-steam games running through HGL flatpak latest release -freedesktop 25.08-)?
In my case, Steam Input works just fine regardless of the Proton version (tested both 8 and 9) for Steam games but not for non-Steam games in the specific scenario described above.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/12310#issuecomment-3349166793

This doesnt seem to be working for me, my joysticks are being detected as controllers for specially Elite Dangerous. I did the uinput to see if it would help but does not. My VKB joystick seems to be getting detected as a xbox controller which causes problems for the game to use it properly. I am on CachyOS, anybody else using joysticks and having similar issues?

I'm also getting this issue, it looks like uinput is already loaded (uinput 24576 2), and the steam link virtual controller on my phone works fine in the steam interface, but if I start a game, the virtual controls either do nothing, or continue to control the steam interface rather than the game. I tried it with proton 9 and that didn't affect it. Any other potential fixes?

Not sure if this can be useful. Before I had to manually type 'sudo modprobe uinput' to fix the issue every time when I launch a steam game or else my bluetooth controller (DualSense) will disconnect at start menu. I was getting hidp_send_message() BT socket write error: Resource temporarily unavailable (11) in my bluez logs.

I was able to permanently solve it by going into /etc/bluetooth/input.conf
set UserspaceHID to false (default is true). Restart bluetooth service. And the issue was fixed.

After reboot, the fix was persistent.

bluetoothctl version: 5.85

Fix on Arch Linux, Steam via Flatpak, (Wayland)

• Install "steam-devices" packages instead of AUR "game-devices-udev"
• Ensure kernel module "uinput" is loaded at startup
• Make sure Steam Flatpak has permissions to "devices=all" (default), Filesystem "/dev:rw", Filesystem "/dev/uinput:rw". I've done this via the app "Flatseal" (available via Flatpak)
• Reboot. After reboot confirm that module "uinput" was loaded"

If you are using a Nintendo Controller (e.g. Switch Pro or Clones) you need to unbind it from hid-nintendo with the script below before you start Steam.

#!/bin/bash
# unbind hid-nintendo from every connected Nintendo pad
for d in /sys/bus/hid/drivers/nintendo/*057E:*; do
    [ -e "$d/unbind" ] && echo "${d##*/}" | sudo tee "$d/unbind" >/dev/null
done
# make sure uinput is readable
[ -e /dev/uinput ] && sudo chmod 0666 /dev/uinput