Wireless Nintendo GameCube Controller for Switch not recognized

[Apocalypse_555]

Hello,

I have an issue with the Wireless Nintendo GameCube Controller for Switch that is very similar to the Switch Controller Pro ("almost the same"). Both are done for the Switch, it should be alike.

My question here is, does someone successfully played with a Wireless Nintendo Switch Controller in Steam ?

Even a Switch Crontroller Pro could be interesting feedback. But I precise it have to be wireless. I know some people successfully used a Switch Crontroller Pro with USB but it's not what I'm looking for because my controller cannot be plugged (Bluetooth only).

My controller is very well recognized in Manjaro. I think the udev rules are ok because I install a special package for it (game-devices-udev) and some rules seems to be present on my system.

Any feedback or help is welcome :)

Regards,

[Marlock]

maybe SC Controller can also do the trick...

[Apocalypse_555]

Początkowo opublikowane przez (LINUX) Hot Sick:

Which controller? You mentioned 3 different ones. The gamepad is recognized and connecting via Bluetooth, but not recognized by Steam? Could you be more specific, please?

When I tell "Wireless Nintendo GameCube Controller for Switch", I'm talking about that : https://www.amazon.com/PowerA-Wireless-Controller-Nintendo-Switch-GameCube/dp/B07GXLBCC3

And for the "Switch Controller Pro" : https://www.amazon.com/Nintendo-Switch-Pro-Controller/dp/B01NAWKYZ0

"Wireless Nintendo Switch Controller" are both of them : any Wireless Nintendo Controller used for a Switch.

About my system, yes the controller is very well connected on my Manjaro Linux because I can play other game (non-Steam) with it. But in Steam, it's not recognized / detected.

[Apocalypse_555]

Początkowo opublikowane przez (LINUX) Hot Sick:

Again, it's ambiguous which controller you mean when you say 'my controller'.

My bad, I didn't get what was ambiguous XD
So I use the GameCube Controller but I was asking any information abouts the Nintendo Controller for Switch. I was trying to get any feedbacks about similar working controllers.

Początkowo opublikowane przez (LINUX) Hot Sick:

As you may have noticed from the previous posts, Steam implements it's own overlapping controller support layer, rather than allow the host OS to do its ♥♥♥♥♥♥♥ job...


According to this[github.com] Steam tries to hijack the hidraw node from the hid-nintendo driver module and re-implement its own driver on top of the kernel.... which, ofc, breaks it. So yeah, another epic fail at Valve for input abstraction.

Yeah I noticed and I didn't know that. It's very interresting but also, quite worrying that Steam re-invent the wheel again and again. A very curious and questionable choice :(

But thoses kind of information are exactly what I was looking for ... so, thanks :)

Początkowo opublikowane przez (LINUX) Hot Sick:

This is from the Arch wiki:

Using hid-nintendo with Steam Games

The hid-nintendo driver currently conflicts with steam using hidraw to implement its own pro controller driver. If you wish to use the Steam implementation, the hid-nintendo driver can be blacklisted. Alternatively if you want to use hid-nintendo with a Steam game directly, Steam can be started without access to hidraw using firejail:

$ firejail --noprofile --blacklist=/sys/class/hidraw/ steam

Might give that a try and see if one of those methods work

Thanks I will. I already read part of that wiki but apparently I missed some usefull info.
Thanks for the explanations, I will keep you updated.

PS : I know it's kind of off-topic but it means the udev are bypassed right ? If Steam go directly speak to the kernel, it bypass any driver or generic library to abstract devices right ?

[Marlock]

steam-input is a package maintained by steam devs that provides udev rules for some devices, so it's unlikely they completely ignore udev...

also a while ago I had an issue on steam with a controller because microsoft kbd+mouse combo didn't present properly to the OS and changing udev rules fixed it (after I figured why the set of udev rules didn't work on my first try):
https://github.com/denilsonsa/udev-joystick-blacklist/issues/30


until now i believe their rework may be the result of ignorance but also the combined factor that they had to avoid creating a new virtual remapped device and letting the original device still appear for games as duplicate inputs, hence the highjacking... does that make some sense?

they do provide a toggle for their implementation vs. letting the game interact directly with some controllers, which is sometimes enough to escape some of the issues in their implementation


i'm personally a bit bitter that they chose the whole controller support to be a closed source secret sauce, although it obviously is one major distinguishing feature if St3am vs. other game stores so I can see why it made sense to them... it's still a shame they kept it this way instead of opensourcing it and letting us work for free on making it better

also they could instead have contributed to the libretro controller support stack and/or to sdl2 and/or joined forces with SC Controller into bringibg a system-wide solution into maturity