[Bug 59901] New: Nintendo Switch Pro Controller is forced as a DirectInput device
http://bugs.winehq.org/show_bug.cgi?id=59901 Bug ID: 59901 Summary: Nintendo Switch Pro Controller is forced as a DirectInput device Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: hibbsncc1701@gmail.com Distribution: --- The Nintendo Switch Pro Controller in USB mode (idVendor=057e, idProduct=2009, bcdDevice= 2.00) gets forced into being a DirectInput device on all subsequent prefix launches after the first one when it is plugged in. I.e. When the controller is first detected by a prefix, it's detected correctly as a xinput controller, but after that initial detection done by the prefix, all subsequent launches of that prefix force it into being a DirectInput device. xinput will report no connected controllers to apps, but the "Game Controllers" control panel applet will still show it's button presses on the xinput tab, and all others. The Joysticks tab claims it's DirectInput. Attempting to reset the pro controller back to xinput fails. (The reset button on the joysicks tab doesn't do anything.) Deleting the prefix and recreating it forces wine back into the initial detection behavior, but exiting and relaunching the prefix causes the bug to occur again. Pulling up regedit shows nothing in HKCU\Software\Wine\DirectInput or HKCU\Software\Wine\DirectInput\Joysticks. Looking under HKCU\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput shows a key with the controller's VID and PID. (Along with \calibration\0 subkeys.) Deleting the key with the controller's VID and PID, exiting and relaunching the prefix makes wine redetect the controller as xinput again, but the registry key gets recreated and the bug occurs again on subsequent prefix launches. So it appears the existence of this key overrides the xinput controller to DirectInput, but wine's Control Panel applet cannot reset it. Nor is it possible to keep it as a xinput device. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #1 from Patrick Hibbs <hibbsncc1701@gmail.com> --- This bug also affects another (third party) controller. (It really doesn't have a proper brand name, but it's an N64 to N64 / USB wireless controller with IDs: (xpad mode): idVendor=045e, idProduct=028e, bcdDevice= 5.72 Shows up as "Controller (XBox 360 For Windows)" in wine's Game Controllers applet. and (N64 Mode): idVendor=0e6f, idProduct=1113, bcdDevice= 1.00 Shows up as "SWITCH CO. LTD. Usb Controller" wine's Game Controllers applet. Both modes are affected by the bug and the same "workaround" applies. Delete the offending HKCU registry key, and the controller will be seen as an xinput device for one launch of the wine prefix. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #2 from Rafał Mużyło <galtgendo@o2.pl> --- I'm not sure which debug channel would be relevant here, but 'lsusb -v' and 'udevadm info' on the device might offer some hints on what's so special about those devices. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #3 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Patrick Hibbs from comment #0)
Deleting the prefix and recreating it forces wine back into the initial detection behavior, but exiting and relaunching the prefix causes the bug to occur again.
Seems similar to the bug for a music app that only works for initial launch but not after relaunch because registry gets updated with misordered mmdevapi audio devices. https://bugs.winehq.org/show_bug.cgi?id=59830#c6 Tests were added to MR-11083 to expose the bug that it fixes which should probably be done for this bug also so they no longer slip through cracks. Hopefully this is bug is as simple to fix as MR-11083. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #4 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Created attachment 81301 --> http://bugs.winehq.org/attachment.cgi?id=81301 lsusb -v output for Nintendo Switch Pro Controller -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #5 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Created attachment 81302 --> http://bugs.winehq.org/attachment.cgi?id=81302 udevadm info output for Nintendo Switch Pro Controller -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #6 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Created attachment 81303 --> http://bugs.winehq.org/attachment.cgi?id=81303 lsusb -v output for N64 Controller (N64 Mode) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #7 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Created attachment 81304 --> http://bugs.winehq.org/attachment.cgi?id=81304 udevadm info output for N64 Controller (N64 Mode) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #8 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Created attachment 81305 --> http://bugs.winehq.org/attachment.cgi?id=81305 lsusb -v output for N64 Controller (PC Mode) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #9 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Created attachment 81306 --> http://bugs.winehq.org/attachment.cgi?id=81306 udevadm info output for N64 Controller (PC Mode) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #10 from Patrick Hibbs <hibbsncc1701@gmail.com> --- (In reply to Rafał Mużyło from comment #2)
I'm not sure which debug channel would be relevant here, but 'lsusb -v' and 'udevadm info' on the device might offer some hints on what's so special about those devices.
I've attached the info you asked for. Hopefully it helps. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #11 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Still present in wine-11.19. Actually, it's gotten worse in 11.19, the controller no longer shows up *at all* in wine's joy.cpl. I get nothing but a blank list. Even though the host can see the controller just fine, and native apps can use it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #12 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Some new findings: Apparently wine-11.19 requires /dev/hidraw* to be accessible by the user now. Granting chmod +rw to those devices via root got wine's joy.cpl list to enumerate again. Was this an intentional change? Debian 13 doesn't currently allow non-root users to access those /dev nodes by default. This change only got the list to enumerate, however. The same bug behavior from wine-11.11 is still present in wine-11.19 once that happens. (I.e. Fixing permissions on /dev/hidraw* only got us back to the originally reported bug behavior.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 Rémi Bernon <rbernon@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com --- Comment #13 from Rémi Bernon <rbernon@codeweavers.com> --- Nothing changed regarding permissions, but the Nintendo Switch controllers preference changed to prefer hidraw over SDL/evdev since https://gitlab.winehq.org/wine/wine/-/merge_requests/11555. It shouldn't make any difference if the system isn't configured to allow access to /dev/hidraw devices (this is usually done using udev rules, installed by some distribution packages like steam), and the SDL/evdev interface should have been used instead, but there's probably a regression as you can't see any controller otherwise. You could try running a git bisect to figure where that regression came from (after restoring /dev/hidraw permission), and/or attach a log with WINEDEBUG=+hid,+pid,+timestamp when running `wine control joy.cpl` for instance. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #14 from Rémi Bernon <rbernon@codeweavers.com> --- Regarding whether the Switch controllers should appear as XInput or DInput devices, the question is also what happens on Windows. I somehow doubt that they work as XInput devices there, it's usually only the case for XBox controllers (or through hooking mods, which we should support the same). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59901 --- Comment #15 from Patrick Hibbs <hibbsncc1701@gmail.com> --- Created attachment 82292 --> http://bugs.winehq.org/attachment.cgi?id=82292 WINEDEBUG=+hid,+pid,+timestamp when running `wine control joy.cpl` Switch Pro Controller (In reply to Rémi Bernon from comment #13)
Nothing changed regarding permissions, but the Nintendo Switch controllers preference changed to prefer hidraw over SDL/evdev since https://gitlab.winehq.org/wine/wine/-/merge_requests/11555.
It shouldn't make any difference if the system isn't configured to allow access to /dev/hidraw devices (this is usually done using udev rules, installed by some distribution packages like steam), and the SDL/evdev interface should have been used instead, but there's probably a regression as you can't see any controller otherwise.
You could try running a git bisect to figure where that regression came from (after restoring /dev/hidraw permission), and/or attach a log with WINEDEBUG=+hid,+pid,+timestamp when running `wine control joy.cpl` for instance.
Attached the log. It's of creating the wine prefix with no controller connected, joy.cpl on the first prefix launch attempt after connecting the Switch Pro Controller (works correctly through this point), and joy.cpl on a subsequent prefix launch (when the bug occurs). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla