Closed bassdr closed 3 years ago
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.
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?
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.
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.
So for what it worth I did more testing.
Any hint about why 8Bitdo??
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.
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.
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: https://github.com/ValveSoftware/Proton/issues/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.
Version of xpadneo
x11-misc/xpadneo-0.8.3 (on Gentoo in my personal overlay)
Severity / Impact
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
Expected behavior
Button is mapped to the game's input.
Screenshots/Gifs
N/A
System information
Controller and Bluetooth information
xpadneo-btmon.txt
xpadneo-dmesg.txt
xpadneo-lsusb.txt
Additional context
I have
sdl
use flag onI tried with both
SDL_JOYSTICK_HIDAPI=0
set or not, same behavior.