PowerA Wireless GameCube Controller is not detected by Steam for Linux

[SynthRose]

Your system information

• Steam client version (build number or date): Nov 14, 2019 at 18:30
• Distribution (e.g. Ubuntu): Debian Bullseye; also confirmed on Ubuntu 19.10
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

I connected a PowerA Wireless GameCube Controller (this thing), a third-party variant of the Nintendo Switch Pro Controller, to my Linux machine through Bluetooth. It pairs successfully, appearing as "Lic Pro Controller" to the system. However, Steam does not detect the controller, and thus cannot remap or calibrate it. I found this occurs on both my desktop (running Debian Bullseye) and my laptop (running Ubuntu 19.10). The standard Nintendo Switch Pro Controller does work. This controller does work on Steam for Windows, at least on the Ubuntu machine (I don't have a convenient way of testing it on my Debian machine at the moment). I do not have the wired version of this controller, so unfortunately I cannot test its compatibility with Steam for Linux.

In addition to working on Windows, Steam purports to support this controller, so I believe this to be a bug rather than a feature request. In November 2018, this controller was mentioned as to-be-supported in this Steam Discussion, and support was subsequently added to the Steam Beta in December 2018 with this update.

So far, Steam has been a godsend for controller support on Linux (even for non-Steam games), and I'm extremely grateful for all the functionality it provides that would otherwise require hours of configuration. But it seems like the combination of this relatively obscure (though supported) hardware with the Linux version of the Steam client swept through the cracks!

Steps for reproducing this issue:

1. Using Bluetooth, connect a PowerA Wireless GameCube Controller to a machine running Steam for Linux.
2. Steam fails to detect the controller.

[SynthRose]

After some investigation, I found that the vendor and product ID reported for this controller are both zero (from /proc/bus/input/devices):

I: Bus=0005 Vendor=0000 Product=0000 Version=0001
N: Name="Lic Pro Controller"
P: Phys=7c:5c:f8:2e:65:3e
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/bluetooth/hci0/hci0:256/0005:0000:0000.000A/input/input36
U: Uniq=00:0b:e4:81:f0:0d
H: Handlers=event27 js1 
B: PROP=0
B: EV=10001b
B: KEY=ffff000000000000 0 0 0 0
B: ABS=3001b
B: MSC=10

In contrast, for the regular Pro Controller, which does work, the vendor and product IDs are indeed set to nonzero values:

I: Bus=0005 Vendor=057e Product=2009 Version=0001
N: Name="Pro Controller"
P: Phys=7c:5c:f8:2e:65:3e
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/bluetooth/hci0/hci0:512/0005:057E:2009.000B/input/input37
U: Uniq=dc:68:eb:3a:e8:56
H: Handlers=event28 js2 
B: PROP=0
B: EV=10001b
B: KEY=ffff000000000000 0 0 0 0
B: ABS=3001b
B: MSC=10

The Steam Controller Database lists controllers by vendor and product ID, so if Steam is using this information to identify controllers, it would make sense that the controller fails to be detected. I'm not sure how Steam identifies controllers, so this information may not be helpful, but I hope it's at least of some use.

[Lorithemouse]

I am having the same issue but with a wired version of the controller (This one) jstest is able to see the controller as well as dolphin. Linux Identifies it as Js0 under dev/imput though.

[SynthRose]

I am having the same issue but with a wired version of the controller (This one) jstest is able to see the controller as well as dolphin. Linux Identifies it as Js0 under dev/imput though.

I believe the js number is assigned based on the order devices are connected, so the first device connected is js0, then js1, etc. So it shouldn't be expected that the IDs are consistent across systems, or even across sessions on the same system. I've also had luck with Dolphin, but Dolphin also has probably the best input configuration options of any software I've seen (it really is a gold standard), so it would be nice to be able to use Steam for software with less versatile controller support.

[Lorithemouse]

Yea I was mostly just commenting because while we have effectively the same controller I wanted to make note that this was also a problem with the wired version. This bug really messes with me because I only have the one controller and I really wanna play crawl.

[leocura]

This happens with (I guess) most of PowerA controllers. I'm using a wired NS Pro Bulbasaur edition joypad and I'm facing the very same.

Is there a way to trick udev into reading it as a generic joypad? Or even forcing it to read a dumped vendorid from an official controller? Considering it's from udev rules that steam finds its devices.

[human9]

I believe it's just a weird permissions issue. You can solve it with the following udev rule: KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0660", TAG+="uaccess" I put that in /lib/udev/rules.d/70-powera-steam.rules. Reload udev rules and reconnect. Now, steam should see it as a pro controller and you can configure it as such :) I use Arch (btw) but things are probably the same on other distros.

Update edit: While this is letting it work fine in big picture and also for controlling the desktop, it's actually not working in-game. Hollow Knight actually crashes with the controller connected. So, maybe not that simple? Would be good to know if others have the same issue.

Final update I promise: Some games do actually work, but only if you go into steam settings and disable switch pro configuration support... Hollow Knight still won't work though :(

[leocura]

That did the trick! Thanks a lot!

On Thu, 26 Dec 2019 at 13:25, human9 notifications@github.com wrote:

I believe it's just a weird permissions issue. You can solve it with the following udev rule (make sure your user is in the "input" group): KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="input" I put that in /lib/udev/rules.d/70-powera-steam.rules. Reload udev rules and reconnect. Now, steam should see it as a pro controller and you can configure it as such :) I use Arch (btw) but things are probably the same on other distros.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/steam-for-linux/issues/6694?email_source=notifications&email_token=AIZY6U5W3R37FD36SFFH4FDQ2TLIFA5CNFSM4JODOAH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHVYXTY#issuecomment-569084879, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIZY6U2EROZUTWU6WCHJWNDQ2TLIFANCNFSM4JODOAHQ .

[kisak-valve]

Hello, is anyone still experiencing this issue on an up to date system? https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules#L50-L55 might have covered these controllers.

[kisak-valve]

Closing as outdated.