Some wine games does not detect my Xbox Wireless Controller

[bassdr]

Version of xpadneo

x11-misc/xpadneo-0.8.3 (on Gentoo in my personal overlay)

Severity / Impact

• I've read the docs and the bug reporting instructions
• It does not work at all
• It used to work in a previous version
• It mostly works but sometimes it doesn't
• I found a work-around
• I probably didn't figure it all out but it's too early to give up
• I don't know how to ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the bug

My Xbox Wireless Controller works in retroarch (udev input driver), but when I try to play some old Ubisoft games under wine, the controller is not detected at all. I know wine detects the controller because UPlay (Ubisoft's game launcher) detects it and let me launch a game by pressing "A", but when the game actually launches, it does not detect any button when I use the game's input configuration.

I don't know how to configure it so it mimics a pad that the game I am playing understands.

Steps to Reproduce

• Open UPlay through wine.
• Open Rayman Origins, Rayman Legends, or Assassin's Creed
• Go to the configure menu
• Press a button on the XBox Wireless Controller to set one of the game's input

Expected behavior

Button is mapped to the game's input.

Screenshots/Gifs

N/A

System information

# uname -a
Linux gentoo-tv 5.4.66-gentoo-x86_64 #1 SMP Wed Oct 7 00:28:29 EDT 2020 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
00000000: 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff  .............0.1..'.
00000014: ff 00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 33 09 34 15 00  .....u.........3.4..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 01 09 32 15 00 26 ff  '......u.......2..&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09  ...u.....%.u........
00000050: 35 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  5..&....u.....%.u...
00000064: 81 03 05 01 09 39 15 01 25 08 35 00 46 3b 01 66 14 00 75 04  .....9..%.5.F;.f..u.
00000078: 95 01 81 42 75 04 95 01 15 00 25 00 35 00 45 00 65 00 81 03  ...Bu.....%.5.E.e...
0000008c: 05 09 19 01 29 0b 15 00 25 01 75 01 95 0b 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 01 95 05 81 03 05 0c 0a 24 02 15 00 25 01 95 01 75 01 81  u........$...%...u..
000000b4: 02 15 00 25 00 75 07 95 01 81 03 05 0c 09 01 85 02 a1 01 05  ...%.u..............
000000c8: 0c 0a 23 02 15 00 25 01 95 01 75 01 81 02 15 00 25 00 75 07  ..#...%...u.....%.u.
000000dc: 95 01 81 03 c0 05 0f 09 21 85 03 a1 02 09 97 15 00 25 01 75  ........!........%.u
000000f0: 04 95 01 91 02 15 00 25 00 75 04 95 01 91 03 09 70 15 00 25  .......%.u......p..%
00000104: 64 75 08 95 04 91 02 09 50 66 01 10 55 0e 15 00 26 ff 00 75  du......Pf..U...&..u
00000118: 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08 95 01 91 02 65 00  .........&..u.....e.
0000012c: 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91 02 c0 85 04 05 06  U..|..&..u..........
00000140: 09 20 15 00 26 ff 00 75 08 95 01 81 02 c0                    . ..&..u......
3869637708 1558

Controller and Bluetooth information

xpadneo-btmon.txt

xpadneo-dmesg.txt

xpadneo-lsusb.txt

Additional context

# wine --version
wine-5.19 (Staging)

I have sdl use flag on

I tried with both SDL_JOYSTICK_HIDAPI=0 set or not, same behavior.

[kakra]

I think older Ubisoft titles used a different joystick driver in Windows. I'm seeing odd behavior of the axes with older Ubisoft titles when running in Proton, and I believe Proton has some code in place to pass the Xinput mode controllers over to the old joystick interface of Windows. Maybe we need to rename the device so older games can properly detect is as a controller? I've seen xow renaming the controller to "Xbox360 controller" or something to make it visible to some games. But I'd not be very happy with such a hack, the Wine code itself should do that, otherwise Linux user space will only see that generic name, no matter which model is connected.

[kakra]

I don't have this file...

This is usually the result of missing binding of the driver. The file should be there no matter the kernel options. I'm using Gentoo here, too. It works for me, tho I manually placed the udev files and used make -C hid-xpadneo reinstall to install the driver (it will automatically run sudo during the actual install, no need to run make itself with sudo).

From your dmesg it looks like the driver was bound correctly. Did you run xxd before or after that?

[bassdr]

Thanks for your help!

From your dmesg it looks like the driver was bound correctly. Did you run xxd before or after that?

I think you are right, the gamepad probably un-bounded while I was trying to install this xxd... I am not using vim so I did not have it installed...
The description has been updated.

I think older Ubisoft titles used a different joystick driver in Windows.

Would it help if I boot windows and install the same games there to check if/how it's detected? Haven't tried.

Maybe we need to rename the device so older games can properly detect is as a controller? I've seen xow renaming the controller to "Xbox360 controller" or something to make it visible to some games. But I'd not be very happy with such a hack, the Wine code itself should do that

I tried xow too but it does not work for me. The device did not pair at all. I did not have a bluetooth dongle with this controller. I am using an usb bluetooth adapter.

I'd be curious to try renaming the device to see if it does the trick... I just don't know how to do that and if it's hard to do. And yes I could check on wine side... If you have any test to try in mind.

[kakra]

If you want to try things, there's this code which constructs a battery name from the device name and the Bluetooth MAC:

	xdata->battery.name =
	    kasprintf(GFP_KERNEL, "%s [%s]", xdata->idev->name, xdata->idev->uniq);

I'm not sure if one could just replace idev->name to rename the device... If you aren't that brave, you should try that in qemu as it may crash your kernel hard when playing around with internal allocations, causing FS corruptions in the worst case. You could also look at the xpad source and see if it does things differently. The xow source should reveal the name that actually should be used for compatibility.

Also, you could look at how Proton does things differently than Wine, it probably has to do with winejoystick or dinput. I think Proton has patches that use SDL for those instead of the Linux /dev/js* devices. It probably also has patches that rename the device to something which is compatible to what games expect. All I can say is that AC:Black Flag and AC:Unity properly detect my controller with xpadneo, however, the axes are broken in a weird way - like I have to hold a trigger half way to get the sticks work properly. All modern games use xinput, and from the bugs observed in those two games, they either use dinput or have some weird implementation for xinput. At least, dinput doesn't have analog trigger support as far as I know, so it makes sense that the game confuses the triggers with axes, and holding them half way actually centers the input.

[bassdr]

So for what it worth I did more testing.

• First of all the issue is not the same between all games. Assassin's Creed does detect the controller, but the analog axis have an offset. If I hold the axis halfway right-down, it's "centered"...
• About Rayman Origins, if I plug in the controller, it's working! So I guess xpad is doing something about it?
• In retroarch, I realized that the displayed name for the controller is not the same using sdl driver or udev. Since wine uses sdl I think this is important?
  • Wireless udev: "Xbox Wireless Controller"
  • Wireless sdl: "8Bitdo SF30 Pro"
  • Wired sdl/udev: "Microsoft X-Box One S pad"

Any hint about why 8Bitdo??

[kakra]

That's probably a bug in SDL, or there's an override set somewhere. 8BitDo are compatible gamepads that show the same pid/vid but have a different wireless MAC OUI. So either something is broken in SDL how it tells 8BitDo and genuine MS from each other, or there's an override in one of the many storage locations SDL provides for that. It may even be different when you run from within Steam (vs a non-Steam SDL game) because the Steam client provides its own SDL controller db.

[kakra]

I think the problem is that plain Wine does not have the SDL/xinput fixes of Proton which support any gamepad as a xinput compatible gamepad.

[kakra]

We probably cannot do anything to fix this, it needs to be fixed at the level of Wine/Proton/SDL2.

I've found one cause of it for games that only look at the first controller and the system may present a different gaming input first, and reported it here: ValveSoftware/Proton#4579

The other thing is that some games expect the controller to have a particular name or VID/PID - and we can't fix that at the driver level - this needs to be worked around in user space. Thus, I'm closing this report.