Possible duplicate controller detection with evdev and rawhid

Tested with Proton Experimental on 2021-03-29

Taken from the original report for Cyberpunk:

@ivyl

Creating HID device for xbox controllers on Linux side may indeed be the problem here. Winebus.sys is responsible for controllers. bus_udev.c picks up everything (-ish) with rawhid that we can access. bus_sdl.c uses SDL to pick up everything else and creates a faux HID/xinput devices on the Wine/Windows side.

Actually, ALL Bluetooth-connected Xbox controllers are HID devices. But what's new in xpadneo is that there's now a udev rule in master which allows access to the rawhid device for the current seat user. So if winebus.sys picks up /dev/hidraw*, and SDL picks up /dev/input/event*, we are seeing two devices which are actually the same hardware.

If button mapping for the rawhid device is wrong, we need to fix this: The winebus.sys driver seems to make wrong assumptions about what the HID descriptor tells it: xpadneo shows 12 buttons in the HID descriptor (10 default buttons + Guide + Share). But it seems to expect a sparse map of 15 bits for 11 or 12 buttons. It's difficult to make such assumptions because we have at least two Xbox Controller models with conflicting bit positions for a button. Could you point me to the code that interprets the hidraw reports for Xbox controllers? I'd like to look at whether we could fix that properly at the xpadneo level, or if we need to improve the wine code. Wine seems to be the only user of rawhid so far, it seems. So it's a good opportunity to get that right now.

This worked as xbox controllers are not HID devices and xpad wasn't trying to provide that faux HID. Looks like that is changing with xpadneo (is this going to be upstreamed?) and the assumptions may need to get revised.

This is a udev thing, not a xpadneo thing. Actually, different input devices allow seat user access to their rawhid device. (https://github.com/atar-axis/xpadneo/commit/eee6d5b8f6ca9b022267cadd2c477e2a0d9660e3)

Duplicate devices would need to be filtered by looking at the udev parent device path: If it is the same, you are looking at the same hardware to rawhid and evdev.

Are you using the current master of xpadneo or do you have some custom patches applied?

I'm using my patch queue in https://github.com/atar-axis/xpadneo/compare/master...kakra:queue/for-0.10 - but for the hidraw case it's identical with current master. Since I'm maintaining and programming that driver, I'm using master + some patches in testing (queue).

There's currently no plan to upstream the driver in its current form but we may try to port fixes over to the kernel. There's a sister project xone (from the xow author) which makes similar efforts but that's not a HID device. It instead works on creating a GIP bus in the kernel for GIP devices (controllers, headsets etc).

Originally posted by @kakra in https://github.com/ValveSoftware/Proton/issues/4450#issuecomment-810146893

Start by reading bus_udev.c and bus_sdl.c to trace how rawhid and evdev devices are discovered, then follow the winebus.sys handling of HID reports. Compare the udev parent device paths for both discovery paths and determine how duplicate hardware should be filtered. Done means the duplicate-controller case is addressed without breaking distinct devices.