FS#76626 - [linux] Fix hid-nintendo LED handling for third-party Switch controllers

Attached to Project: Arch Linux
Opened by Maciej Mućka (DilithiumNitrate) - Saturday, 19 November 2022, 15:30 GMT
Last edited by Toolybird (Toolybird) - Monday, 12 December 2022, 02:47 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
As it is, the hid-nintendo driver in the Arch Linux kernel does not merge a 6.1-rc1 patch that makes connecting many third-party Switch controllers, such as the 8BitDo SN30 Pro+ in Switch mode (which is its only mode that exposes motion controls), possible. This patch has commit hash 8b30fb40f8f2c5e56b7af553a398340f92d17aae, and is present in the master branch of https://github.com/archlinux/linux and in mainline 6.1-rc1 but not in any of the Arch repo's 6.0.x tags. When a third-party Switch controller that does not support home LED control is connected, hid-nintendo's behavior without this change is to report the probe as failed, thus not connecting the controller. With this patch, a warning is emitted and the home LED is deregistered but the controller works.

Additional info:
* package versions: up to and including 6.0.7 known to be affected. 6.0.8 and 6.0.9 untested because since 6.0.7 I've been using a custom config that has the patch, but said patch is not present in their version tags in the source repo as mentioned above.
* log files: attached is a journalctl snippet from unpatched 6.0.7 containing the kernel output from connecting an 8BitDo SN30 Pro+ (firmware 5.0.4) in Switch mode.

Steps to reproduce:
Connect an 8BitDo SN30 Pro+ in Switch mode, preferably with firmware 5.0.4 (or another third-party Nintendo Switch controller, though some probably won't exhibit this issue), over USB, without blacklisting hid-nintendo.
   hid-nintendo-dmesg.txt (1.9 KiB)
This task depends upon

Closed by  Toolybird (Toolybird)
Monday, 12 December 2022, 02:47 GMT
Reason for closing:  Fixed
Additional comments about closing:  linux 6.1.arch1-1
Comment by Toolybird (Toolybird) - Saturday, 19 November 2022, 22:30 GMT
The fix is known, it will appear in 6.1, you've already patched your own kernel. I suspect this kind of backport request for uncommon hardware is a bit of a nuisance for the Arch maintainer (but I could be wrong).
Comment by Maciej Mućka (DilithiumNitrate) - Sunday, 20 November 2022, 18:44 GMT
My primary reason for submitting this at all is because this wouldn't be the first uncommon hardware patch merged ahead of stable mainline releases. While the example I'm bringing up is probably a more common piece of hardware than the 8BitDo SN30 Pro+, I haven't seen that many people talk about this either, and it's probably rare even within the affected range of hardware – a 6.0-rc4 patch to hid-asus, "HID: asus: ROG NKey: Ignore portion of 0x5a report" (1c0cc9d11c665020cbeb80e660fb8929164407f4 in mainline, 2b32e820ccf5a0385e46d1c038b321aba9a5ec2d in Arch kernel 5.19.x), fixes keyboard backlight level control (Fn+F2, Fn+F3) in some Asus laptops' built-in keyboards, including mine, and was merged into Arch's kernel in 5.19.7. This is why I hoped that this hid-nintendo patch could be merged in 6.0.x. Also on my laptop I use a separate Linux kernel config, linux-g14 (https://gitlab.com/dragonn/linux-g14/-/tree/6.0, not to be confused with the AUR package), with a set of platform-specific patches most of which are irrelevant for my desktop, thus if I had to keep compiling a custom config, I'd have to compile it twice to use it on my laptop.
Comment by Maciej Mućka (DilithiumNitrate) - Monday, 12 December 2022, 01:31 GMT
This has been slept on for so long that kernel package version 6.1-arch1 is already out (in the testing repo and ASP trunk), which contains the patch requested. Maybe it's worth closing this.

Loading...