https://bugs.winehq.org/show_bug.cgi?id=51878
Bug ID: 51878 Summary: Gamepad / adapter not detected without legacy joystick backends. Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: escomk3@hotmail.com Distribution: ---
Created attachment 70806 --> https://bugs.winehq.org/attachment.cgi?id=70806 Output from 'joy.cpl' and 'evtest' (+plugplay,+hid,+hidp,+hid_report,+dinput).
After adfee25b45a [1], a DualShock 2 PlayStation gamepad via a USB adapter no longer works in FINAL FANTASY XI Online, or in the Wine 'joy.cpl' test program.
A little bit of background: this gamepad previously didn't work in things like Steam, which was most likely due to permissions (user not part of the input group for example), but I never did anything about that since I only use the gamepad via Wine, and it worked. With this change in Wine, it looks like it might no longer be possible to avoid additional configuration and/or dependencies, and I've tested various methods of making it work.
While it now works in the native Linux build of Steam, it still doesn't work with the game, or with 'joy.cpl'.
The output is more or less the same for the game and 'joy.cpl': when I press the ANALOG button to enable the analog mode, I can see
0074:trace:hid_report:process_device_event Received action 650 wine: Unhandled page fault on read access to 0000000000000000 at address 00000001C9232342 (thread 0074), starting debugger... 0070:err:wineusb:event_thread_proc Error handling events: System call interrupted (perhaps due to signal) 0070:err:wineusb:event_thread_proc Error handling events: System call interrupted (perhaps due to signal)
but the application itself does not actually crash (looks like it's 'winedevice.exe' in the background).
If I press a different button, there's
0074:trace:hid_report:process_device_event Received action 651 0074:warn:plugplay:bus_main_thread L"SDL" bus wait returned status 0xc0000005
and nothing else after that no matter what I press until I restart the process.
The gamepad/adapter is detected as follows:
usb 3-2: new low-speed USB device number 7 using xhci_hcd usb 3-2: New USB device found, idVendor=0810, idProduct=0001, bcdDevice= 1.06 usb 3-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0 usb 3-2: Product: Twin USB Joystick input: Twin USB Joystick as /devices/pci0000:00/0000:00:07.1/0000:0c:00.3/usb3/3-2/3-2:1.0/0003:0810:0001.0009/input/input24 input: Twin USB Joystick as /devices/pci0000:00/0000:00:07.1/0000:0c:00.3/usb3/3-2/3-2:1.0/0003:0810:0001.0009/input/input25 pantherlord 0003:0810:0001.0009: input,hidraw4: USB HID v1.10 Joystick [Twin USB Joystick] on usb-0000:0c:00.3-2/input0
It's possible I'm still missing something I did not need with the legacy backend(s).
Some things that I've tried:
- Add the user to the input group. - Added sdl, udev, and usb support to the Wine build.
1. https://source.winehq.org/git/wine.git/commit/adfee25b45af8160848f94fdb24279...
https://bugs.winehq.org/show_bug.cgi?id=51878
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- Is that systemd or just elogind ?
Though in both cases devices should be handled correctly by udev - they should get uaccess tag, which would make tinkering with groups unnecessary...
https://bugs.winehq.org/show_bug.cgi?id=51878
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #2 from Rémi Bernon rbernon@codeweavers.com --- Thanks for the report!
The "wine: Unhandled page fault on read access to 0000000000000000 at address 00000001C9232342 (thread 0074), starting debugger..." message is a bit worrying and probably the cause of the issue.
From the log I see that the device is detected as two different SDL joysticks,
but both with the same descriptor: "desc {vid 0810, pid 0001, version 0110, input -1, uid 00000000, is_gamepad 1}, unix_device 00007FEDA80273B0" with index 0 and 1.
That may be the cause of the later crash when the axis is moved.
Could you try disabling SDL in the registry and see if it makes any difference? You can do that by adding a "Enable SDL" option set to 0 in regedit, under the key mentioned in https://wiki.winehq.org/Useful_Registry_Keys
https://bugs.winehq.org/show_bug.cgi?id=51878
Chiitoo escomk3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Gentoo
--- Comment #3 from Chiitoo escomk3@hotmail.com --- This is a rather simple Gentoo Linux install without systemd or elogind, with eudev in place of udev.
If need be, in due time I should be able to test the thing on another machine, with a set-up that might be a touch more common to see if it works anywhere at all.
Yes, disabling (or building without) SDL support does get rid of the related messages and the crash (only nothing happens then).
Indeed, just the adapter alone (it's a no-name one with only "PIII CONVERTER Model:A01" written on it), without any gamepad connected to it is detected as two for some reason that I never really tried to figure out. Through 'evtest' they seem identical, but only one of them responds with what the gamepad is doing (maybe one is for DualShock 2, the other one for 3 or something... Steam does claim it is a PlayStation 3 controller, but perhaps that's just because it assumes a PlayStation 2 one can't be connected to a PC... or something).
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=51878
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- ...perhaps 'udevadm info' on both of those nodes would offer some hints...
https://bugs.winehq.org/show_bug.cgi?id=51878
--- Comment #5 from Chiitoo escomk3@hotmail.com --- Created attachment 70831 --> https://bugs.winehq.org/attachment.cgi?id=70831 Output and 'diff' of 'udevadm info -a' on js0 and js1.
They're pretty similar what comes to 'udevadm info', too, which is a bit unfortunate. I was playing with it the other day, trying to write an udev rule so as to change the group permissions so that only one of the "devices" is seen by applications (js0 and its event node).
While that does work, at least when testing with Steam, the rule part isn't exactly persistent since the only few unique identifiers tend to change when the device is re-initialised...
In any case, perhaps somewhat interestingly, at commit 7011685e1e70 (before the removal of the legacy backends), when I give the user permission (via groups for example) to the event node as well, then I'll have an additional device available (Twin USB Joystic (event) in addition to the two Twin USB Joystic (js)). This also works with FFXI (though I had to re-calibrate the right analog stick for some reason, and in joy.cpl it spins the wrong way around, up is left, down is right, left is up, and right is down).
Why it doesn't work after the removal is still a bit of a mystery.
Also still not sure why it works in Steam. If I remember right-like, they use SDL for those bits. Will try to find some other things to test with.
https://bugs.winehq.org/show_bug.cgi?id=51878
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
https://bugs.winehq.org/show_bug.cgi?id=51878
Chiitoo escomk3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #6 from Chiitoo escomk3@hotmail.com --- Hm, in short: it works in a clean prefix.
Usually that's one of the first things I try, but maybe I forgot I had not yet done that this time.
Interestingly, the adapter-gamepad combo is now detected as an xinput device, and appears in the middle box of joy.cpl. That's different. If I use 'Override' to move the device to the upper area, it still works in joy.cpl, but not in FFXI. The game does have an option to enable xinput however.
Building with, and enabling 'sdl' is enough (that is, no 'udev' or 'usb'), but I couldn't find a way to make it work without sdl yet. It does seem to be possible though, since I can do it on a Debian test install (if I disable SDL via the registry, the device will show up in the upper area again, though curiously the name will be just 'Twin' instead of 'Twin USB Adapter').
Speaking of the Debian test install, the permissions there seem to be granted via ACL, which I do not use, so that probably explains that part.
So, I guess this can go resolved as invalid, though it's unfortunate that a prefix can break like this. It's probably not worth the effort to find out what causes it, unless it becomes a bigger problem (at least I couldn't re-produce it by simply creating a prefix using a build of Wine with the legacy backends still there, and then running a build without with it).
Again, thank you!
https://bugs.winehq.org/show_bug.cgi?id=51878
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl ---
the permissions there seem to be granted via ACL, which I do not use
:snort: ...and just how did you think handling of uaccess tag was implemented ?
https://bugs.winehq.org/show_bug.cgi?id=51878
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Status|RESOLVED |CLOSED
--- Comment #8 from André H. nerv@dawncrow.de --- closing invalid
-
WineHQ Bugzilla