Code change:
Describe the bug I'm trying to get Steam big picture to work with , xbox wireless adapter and a couple of xbox controllers. But if Steam is already running and I turn on my controllers, they successfully connect to the dongle, but steam doesn't detect them. If i first turn on the controllers, and then i start Steam, it recognizes them and they work fine. xow: I couldn't use the service file provided by the package because it would never start. I read somewhere that systemd is picky with symlinks, so i defined it myself, now it's starting fine. I also had to blacklist else xow would crash. Steam: To Reproduce Steps to reproduce the behavior: sure xow is running fine Steam on steam controllers to see if they work (they dont) Additional context I think xow is working fine. I tried the latest version (0.5) and the last commit, importing udev rules from the package and adding them to I also tried adding my user to the group. It doesn't matter if steam is running in big picture or not, i also tried steam native, still not working. Metadata Edit: Steam won't detect controllers even when using the wire. And also i tested the controllers with and and they work as expected. So i'm pretty sure the issue must be with steam.
This might be an upstream problem with , have you tried using it on a non NixOS system? I also maintain (a kernel driver for Xbox controllers) and I don't have this problem with Steam. Maybe try to test if there's still a problem on your system with xpadneo?
You might also want to try enabling xow using the NixOS module instead of writing a custom service:
Yes, i have another system with Arch and it's working fine there. Steam detects controller connections even when it's already running. That's what i tried at first, but xow wouldn't start, the service was hanging in an state. And I think it might be because when importing the service from the package, nix is creating a symlink to the service and it might cause some issues. Also I did some more tests with xow and controllers are working fine, , , this website https://gamepad- everywhere it works as expected, even Stardew Valley is able to detect them, but not Steam (well unless i restart it with controllers connected, then they are detected and working). It's really weird, I am able to pair them, xpadneo detects them, but they are totally unresponsive, everywhere. I uninstalled xow, and removed the wireless dongle when i tested this. Since xow it's working fine in browser with https://gamepad- and with some games, then udev rules should be fine , right? I would say it's an upstream issue with Steam, but it's working fine on Arch, so there might be some issues with some libs?
The xow NixOS module is fixed now. The problem was that NixOS specifically bypasses the Install section of service files and the module wasn't setting WantedBy for the service explicitly.
I am wih something similar here, I am using the gamepad via USB , before the config all software detected the control, and I was able to play without problems except for steam, which prevented me from using the big picture, after enabling this option I have the same behavior as steam for all applications, if I plug in the control it does not work until the next reboot. Any suggestions on where to debug to understand why this behavior? Dmesg and lsusb look ok.
Having a similar issue, since I'm not using xow or anything but kernel drivers: Steam isn't able to detect a hotplugged Xbox one wired controller. It works perfectly fine if I plug it in before starting Steam. I can also confirm this behavior works on Arch.
that's my situation too
I guess no news on this? :(
i'll take a look, probably something to do with udev rules. i dont have a xbox controller though, only a steam controller
This problem sufficiently annoys me at this point that if there are any instructions I can follow to provide information I'm happy to do so. Thanks for offering to look. I am currently in possession of 2 xbox controllers, several controllers that show up as xbox controllers, and some controllers that don't show up as xbox controllers. I have this issue with all these controllers to the best of my recollection.
the steam udev rules are almost the same as on other distros, though arch does i'll try borrowing a xbox controller. does this happen with only the xbox one or does it happen with 360 too
sadly i can't find a xbox one controller. the udev rules provided by the steam package are the same as on other distros, maybe it has something to do with our other udev rules. may also have something to do with bubblewrap
It seems to be related to linux usernamespaces which to my understanding remaps the id of the sender of udev events (from 0 to a big number) leading udev to ignore these messages if it's not zero. Running directly on my system and under (running as root and as a normal user) led me to believe this (). This issue may need to be fixed with bubblewrap, I don't think something can be done here. Unfortunately I don't have a solution :sweatsmile: PS : I don't know if fixing this issue will make everything work, .
these look related
I merged someone who has this issue please look into using the patched systemd with the steam fhsenv
I've just tested on latest NixOS unstable. A hotplugged Xbox One controller was successfully detected by Steam Big Picture. Thank you!
i haven't done anything that would have fixed this
Well that is exceptionally weird! Because it's definitely working for me, looks like an unrelated PR fixed it? This is straight out of my terminal, after starting Steam with no controller, disconnecting and connecting again:
This must be a change to how steam recognizes controllers. The program from still does not show events when started within There is still something odd: My joystick Logitech X52 HOTAS is recognized as a gamepad, while when I run steam packages on flatpak, it works properly. I don't know what they do differently in the flatpak version to get it working. Maybe using libgudev or a flatpak specific version of udev in the runtime packages? I have tested adding patched systemd to the fhs of steam, but this did not change anything (maybe some other udev library version was shadowing it)
I marked this as stale due to inactivity. &rarr;
I still have this issue, with both an xbox 360 controller with the wireless adapter as well with an 8Bitdo SN30+ in both wired and wireless mode. Starting steam with any of these already connected works, but if one gets connected after starting steam (or worse - shortly disconnects while playing) it will not be reconnected until a Steam restart. However, with a Steam Controller hotplugging works just fine! This happens with Steam Big Picture mode (and also in games, but I guess Big Picture mode is more readily reproducable). I assume I am doing something wrong as others have it fixed, is this really no longer an issue for others? Happy for any pointers and to assist in debugging. (my config is at in case it is needed, i am currently on )
I assume I am doing something wrong as others have it fixed, is this really no longer an issue for others? I have the same issue, with PS5 DualSense controllers. I debugged a bit during the christmas holiday, based on some info in either this issue or some other... By applying a patch (linked from the issue) I was able to see udev starting to detect hotplugging the controller in the Steam FHS env (it didn't detect these events by default), but still Steam wouldn't pick up the hotplugged controller.
I found my experimental config snippet from back then: AFAIR, I was worried that steam itself didn't use the patched libudev, but I'm pretty sure I looked up the process map and found it had (only) loaded the patched libudev, so I'm not sure what's going on. Didn't look at it since.
If anyone just wants to throw money at this problem I highly suggest the to solve it. The real win with this gamepad is that it always shows up as connected to your PC, even when it is powered off. It achieves this by coming with a usb dongle that shows up effectively as a wired joystick regardless if the gamepad is being used or not. Perfect solution for this problem... I have 3. I'll mention a potential con, though: Make sure you have good line of sight between the usb dongle and the gamepad (don't worry, it comes with a ~1m usb extension cable to allow good line of sight) and aren't too far away (3-4 m I would guess) or else the signal is really spotty. In my last setup I used this through the wall and it absolutely wouldn't work for any serious gaming, but now I have the pc in the same room as the gamepads with direct line of sight and it is perfect. But yeah... a real solution would be better and still appreciated by me. Just thought I'd post this in case anyone could benefit from it. :man_shrugging:
Another alternative is to use : in the config: then install and run it: I didn't have any issues since doing it since flatpak was updated to = 1.12
I still have this issue on Nix's version of steam using nixos-unstable. Enabling xpadneo did not fix it either.
may have fixed this
Seems like didn't fix it. I see that it is in nixos-unstable and it seems like Steam still displays the same issue with my DualSense controller. I need to restart Steam before it detects it
I am having this issue on every controller I have: Steam Controller Nintendo Switch Pro Controller PS3 Controller Gulikit King Kong Pro 2 Controller in all 4 modes (Switch, XInput, DInput, Android/iOS) USB adapters for NES, SNES, and Gamecube controllers It occurs when using both Bluetooth and USB, so I am 90% certain it has nothing to do with which controller you are using. The behavior is the same for all of them; when I connect any USB/Bluetooth controller it is not recognized or noticed by Steam if it is already running, but only when Steam is starting up while the controller is currently plugged in. Here's some information on what happens when I use the Gulikit controller (XInput mode via bluetooth): Controller connected and Steam is not started At this point, and are now created Now I start Steam And reports: And now and are created (???) Disconnected the controller with Steam running Nothing new in I reconnect the controller with Steam running* And and is back TL;DR - So it looks like Steam will normally start up and find the controller and then it will create the virtual input devices and . However, it won't create these devices when they are connected after Steam is already running. The question I have is why this happens and what can be done to fix it. It looks to be a NixOS specific issue as the problem doesn't appear to be on other Linux distributions like Arch (just reading off of what's in this thread, I haven't tried myself). If anyone wants me to try anything and test it on a fair variety of USB/Bluetooth controllers please let me know. I think something might be wrong with how the FHS wrapper () seems to be binding the devices that prevents new devices from being seen. EDIT: I just confirmed the and device files are appearing and disappearing in the environment that Steam runs in, so the FHS is actually properly creating those devices. The only difference I can see is that they are owned by in the FHS environment (versus in the normal environment). I can still properly access both. I did see : However, that would imply this is not NixOS specific and instead is default Steam behavior. No indication of how to change that default behavior though, so I can't find a way to confirm it.
This seems related:
Just as an datapoint: The Steam Controller is actually one that does not exhibit this issue for me, at least not when wirelessly connected with the Dongle that came with it. If I connect it via cable then it is the same as usual, only recognized when restarting steam. Also if connected via dongle and I replug the dongle, the controller only gets recognized when restarting steam. But if the dongle stays put and I shutdown the controller (by holding the Steam button for a few seconds) and start it again it works just fine with steam running. I guess it might be similar to the controller described in
I was surprised as well, and a little bit of digging reveals that SDL2 being inside flatpak and disables the unreliable udev-based discovery. And disabling it manually ! I opened to fix this.
Can confirm that it fixed the issue for me. Good job in discovering this
This is resolved for me now as well. Thank you all! :heart:

Related discussion:
text: export TZ="$new_TZ" fi fi <ins> # udev event notifications don't work reliably inside containers. # SDL2 already tries to automatically detect flatpak and pressure-vessel # and falls back to inotify-based discovery [1]. We make SDL2 do the # same by telling it explicitly. # # [1] <https://github.com/libsdl-org/SDL/commit/8e2746cfb6e1f1a1da5088241a1440fd2535e321> export SDL_JOYSTICK_DISABLE_UDEV=1 </ins> '' + extraProfile; runScript = writeScript "steam-wrapper.sh" ''