ValveSoftware
Add detection of upcoming hid-nintendo joy-con/pro controller kernel driver
Your system information
- Steam client version (build number or date): Nov. 5, 2019
- Distribution (e.g. Ubuntu): Arch
- Opted into Steam client beta?: Yes
- Have you checked for system updates?: Yes
Please describe your issue in as much detail as possible:
The hid-nintendo kernel driver (for nintendo switch pro controllers and joy-cons) is currently in review in the linux-input mailing list with the possibility of being merged in the 5.8 merge window. Right now, steam uses hidraw to implement its own userspace driver (which I believe currently actually has a bit more functionality than the kernel driver, since it has gyro support). This leads to Steam fighting with the kernel over control of the device, and it leads to spastic behavior.
The kernel driver sets the most significant bit of the evdev's version number to allow userspace applications (e.g. sdl2, steam, etc.) to discern hid-nintendo from the default hid device. It would be nice if Steam could choose not to use hidraw when it sees that hid-nintendo is in use to avoid the conflict. As a work around I've been running steam with firejail to restrict its access to hidraw.
I am open to other suggestions for what I can do in the kernel driver to facilitate it and Steam playing nicely.
Thanks!
Steps for reproducing this issue:
- Load the hid-nintendo kernel module
- Plug in nintendo switch pro controller
- Watch steam and the kernel fight each other over the controller
Anyone know the status of this kernel driver? I haven't been able to find any activity on it since last October.
@ZLima12 Here is my latest submission to the mailing list: https://www.spinics.net/lists/linux-input/msg65088.html
There are some changes to the driver I still need to make (mostly involving the accel/gyro support).
Hi, the driver has been accepted for Linux 5.10 and it would be nice to at least make sure that the Steam implementation doesn't conflict with the hid-nintendo module.
Linux kernel 5.10 (just now installed it on my system) is out and this is still not fixed. Please please please, valve, can you get steam to detect the switch pro controller without conflicts with the kernel driver. I don't know that much about programming but considering all other fantastic things you've achieved for linux gaming, surely this little tiny issue can not be that complicated? Many thanks.
Perhaps the steam client can run modinfo hid-nintendo. This command will produce a non-zero exit status if the module can't be found. If it does this, the steam client may use it's own driver. Otherwise, the kernel driver should be loaded automatically when a controller is connected.
Whatever is implemented will ultimately be temporary since 5.10 is the new LTS kernel.
@clarfonthey unfortunately, hid-nintendo didn't make it into 5.10. So anyone on LTS is not going to have it.
Oh. :(
Well, either way, I do think that this would be appropriate to implement. If anything, Steam should be compatible with the module.
Absolutely. I've been using hid-nintendo for a month or two now and it works great. Plug and play for a lot of (most?) games, particularly those that use SDL. Don't have any complaints about it. Having the Steam client use it when available would by far be the preferred behavior.
I have problems getting a pro controller to work and I am not sure where I should report my problem. What's the current status of hid-nintendo? Is it in the kernel by now? Is what I experience a result of the conflict?
I am on Arch Linux, generally latest versions of everything and running Steam in the "native" version.
The following is what jstest-gtk shows me for the controller with Steam's "Switch Pro Configuration Support" option unselected.
https://user-images.githubusercontent.com/931051/115167915-7fe46300-a0b9-11eb-86a1-8dbe7d45df8e.mp4
The only thing that is responsive here is axis two, although that should have been axis 1.
After enabling Switch pro con support in the settings, jstest-gtk shows me an additional fake(?) xbox 360 controller shows no inputs in "Properties". However, the right analog stick is translated to mouse movement and the left stick is translated to arrow keys.
Ori and the Blind Forest just works, but Trine 2 seemingly picks up the erratic garbage inputs and automatically selects items on the menu, after which it eventually cycles the "escape" menu in-game until I unplug it.
The launcher itself is also quite irritated by it.
https://user-images.githubusercontent.com/931051/115168193-5aa42480-a0ba-11eb-9667-994d23d25d40.mp4
Steam Input implementation interfering with native Switch Pro Controller driver
Issue transferred from https://github.com/ValveSoftware/steam-for-linux/issues/7786. @clarfonthey posted on 2021-05-07T02:43:21:
Your system information
- Steam client version (build number or date): Apr 27, 2021 at 23:10:40 (package version 1619570428)
- Distribution (e.g. Ubuntu): Arch Linux
- Opted into Steam client beta?: Yes
- Have you checked for system updates?: Yes
Please describe your issue in as much detail as possible:
I use the native hid-nintendo driver to get my Switch Pro controller working outside of steam. (see: #6651)
Right now, the built-in Steam Input driver interferes with the native driver in frustrating ways. In order to get things to work with the native driver, I have to use the suggested workaround of running Steam in firejail (usr/bin/firejail --noprofile --blacklist=/sys/class/hidraw/ /usr/bin/steam-runtime) which completely overrides any Steam Input settings, but lets me use my controller in games with minimal issues. If I open steam without firejail, Steam Input works, but the controller is interpreted as a mouse and keyboard in other apps while Steam is open, and I can't natively use the controller outside of steam.
I'm making a new issue because despite several requests in the other ticket (#6651) this is still an issue affecting users, and I would prefer to be able to launch steam without having to look up a firejail command just to make things work with my controller.
At minimum, Steam for Linux should detect if the hid-nintendo driver is present and use that instead of its own driver if available, so that Steam Input can still work as expected. Otherwise, the default implementation is fine.
I would like to say that the Nintendo Switch Pro Controller via Bluetooth doesn't work in some games with the hid-nintendo driver, but they work using Steam driver.
For example, No Man's Sky (using Proton) doesn't detects my controller if I use the firejail ... --blacklist=/sys/class/hidraw/ ... trick, so I need to use the Steam driver.
(However, I need to disable rumble in order to use the controller more than several minutes into the game before disconnecting.)
FWIW I also have the same problem with Blue Fire -- I had to use the Steam Input version of the driver when the hid-nintendo one usually works. I haven't ever encountered this issue in a native game, though, and it is likely an issue in Proton that affects a few games. Properly supporting hid-nintendo would be the proper fix for this IMHO, and not a reason to continue the existing behaviour.
The best fix, I think, should be to let the user choose the driver he/she wants to use in every case.
Uh, no… drivers aren't supposed to work that way. You use the proper driver for hardware, end of story; the only reason why steam should make up its own driver for Switch Pro controllers is if the system doesn't support it. There's still the option to enable or disable Steam Play for a controller, but that doesn't actually change the drivers, just how their inputs are processed in the game.
There's a reason we're not seeing action on this. Because of the fact that hid-nintendo has not been accepted into the mainline kernel yet, we shouldn't be expecting any updates in this issue from Valve.
Yes, dkms-hid-nintendo is wondeful, quite stable, and it works really really well. But it's not included by default in any distro kernels, and is a userspace-breaking change, which should not be taken lightly by Valve.
For now I've added a workaround for this problem to the joycond daemon. See the arch wiki for an explanation.
Can't believe it's been two years already since I started following this, and finally it's in. Would love to see Steam support it natively now.
Connecting a Switch Pro Controller to Steam on Linux could be a lot easier if this was supported :+1:
So Steam Input's implementation of the Pro controller driver simply just breaks now with the mainline kernel. Random disconnects. You either need to disable to kernel driver or disable config support in Steam to get the controller to function properly. Please adapt your implementation to work with 5.16.
Something new about fixing conflict between kernel driver and steam driver ?
We're in a transtionary period between distros using the old hidraw method to access switch controllers, and the new method inside the kernel that happened with 5.16's hid-nintendo.
Valve, being on kernel 5.13 right now, will need roughly six to twelve months before this situation is really resolved. This is not a small change, and has multiple points of pain right now in regards to useability. For instance, all third-party switch controllers seem to have problems with hid-nintendo.
This one will take patience, though I'm sure patches are welcome.
I don't know if Valve intends to support kernel modules.
hid-playstation (introduced in Linux 5.12) for example should be enabled on SteamOS, but it's not.
https://github.com/ValveSoftware/SteamOS/issues/746
This is still not fixed by the latest Steam Beta (which claims to add support for other Switch related controllers).
It's not a good thing that the option Switch Pro Configuration Support still has a lie in its description: "Note: This setting must be disabled for Switch Pro Controllers to work in games not launched through Steam while Steam is running".
It seems that the issue has been fixed: I played the entirety of Aperture Desk Job with no issue, and I can use the controller outside Steam even when Switch Pro Configuration Support is active.
Tested through USB. Didn't use joycond. My user is in the input group.
EDIT: Nevermind about working outside Steam, it depends on the game.