Seems like https://github.com/wine-mirror/wine/commit/33756286efb9e6b58831b01b9f2ef4d7992a967a cause the problem

Same thing affecting Rocket league with slightly different consequences for me.

System

• Fedora Linux 44 KDE Plasma, Wayland
• Kernel: 7.1.3-200.fc44.x86_64
• GPU: NVIDIA RTX 5090, driver 595.80
• Steam public client build: 1782866176
• Proton Experimental: experimental-11.0-20260713 (config_info: 11.0-100)
• Rocket League Steam BuildID: 23771930
• DualSense over USB: 054c:0ce6
• Steam Input explicitly disabled for Rocket League

The controller had consistently worked through Rocket League's native DirectInput path with PlayStation icons showing up in game before the issue occured.

While it worked perfectly before I first replugged the controller, after I did suddenly it showed Xbox icons in game.
Since then the native PlayStation controller was not recognized until I replugged it again which is where it would start showing the Xbox icons.
This sequence happened every game launch since the issue first occurred.

The reason for the issue:

1. The controller initially enters Proton through native HID/DirectInput showing PlayStation icons.
2. Replugging while Rocket League is running makes Winebus' SDL path recreate the same controller as an XInput gamepad.
3. Wine persists that synthetic device under WINEXINPUT and rthe registry.
4. Wine commit 33756286 (https://github.com/ValveSoftware/wine/commit/33756286efb9e6b58831b01b9f2ef4d7992a967a) changed Win32_PnPEntity from enumerating only present devices to walking every device record in the prefix registry.
5. The stale IG_00 XInput identity remains visible on later launches so this issue does not fix itself.

Game logs:

[0015.15] Log: Found controller by Product Guid
[0017.99] Log: Assigning DI controller to 0
after replugging:
[3850.37] Log: Detected new XInput controller 0
[3850.37] Log: Unassigning DI controller 0 in favor of XInput controller
[3852.90] Log: Assigning XInput controller to 0

The hotfix that worked for me:

1. Close Steam and delete the corresponding registry entries/trees, in my case HKLM\System\CurrentControlSet\Enum\WINEBUS\VID_054C&PID_0CE6
HKLM\System\CurrentControlSet\Enum\WINEXINPUT\VID_054C&PID_0CE6&IG_00
HKLM\System\CurrentControlSet\Enum\WINEXINPUT\VID_054C&PID_0CE6&XI_00
HKLM\System\CurrentControlSet\Enum\HID\VID_054C&PID_0CE6&IG_00
   you may need to delete the entries in DeviceClasses under their GUID aswell
   you can use protontricks for this: (protontricks -c 'wine reg delete "HKLM\System\CurrentControlSet\Enum\WINEXINPUT\VID_054C&PID_0CE6&IG_00" /f' 252950) 252950 for RocketLeague. Run this for the other trees aswell
2. Refrain from ever replugging the controller while the game is running.

We independently hit the same wall from the other direction while making a virtual DS4 natively detectable in Detroit: Become Human (its libScePad.dll implements the mirror-image of this algorithm: WMI Win32_PnPEntity scan requiring IG_ in DeviceID + VID/PID match before the game enables its PS4 pad path). Decoding both sides produced findings that complement this report:

Why the Proton 10 wbemprox.dll substitution "fixes" it: P11's winexinput lifts the WINEXINPUT\VID_xxxx&PID_xxxx&IG_xx identities into the Enum tree that Win32_PnPEntity serves; P10 didn't expose them, so the dedup algorithm found nothing to reject. The dedup itself is game-side and follows the documented Microsoft algorithm — the regression is the visibility of the twin identities.

Structural detail from the winexinput source (dlls/winexinput.sys/main.c, create_child_pdos + internal_ioctl): each gamepad FDO gets two child PDOs —

• gamepad child (...&IG_00, is_gamepad=TRUE): answers IOCTL_HID_GET_* from an in-tree synthetic XInput report descriptor (by design, for XInput translation), never the real device descriptor;
• xinput child (...&XI_00, is_gamepad=FALSE): passthrough to the bus parent — the real descriptor.

So games that probe the HID interface behind the IG_ identity get the synthetic descriptor, not the controller's real one — which is a second, independent way native Sony detection breaks beyond the WMI dedup (libScePad-style games reject the synthetic caps before ever reading reports).

A workaround we validated end-to-end (shipped as data hex-patches in proton-ds, a DS4-emulation stack): neutralizing the winexinput device-interface GUID (GUID_DEVINTERFACE_WINEXINPUT in hidclass.sys) makes the XI-side interface invisible to XInput/DInput/SDL enumeration simultaneously — for a game that must NOT see the twin, that removes the false-positive side of this class of problems with zero per-game config. (The inverse case — games that require the IG_ identity to exist — we solve by swapping which child carries the real descriptor.)

Happy to test any candidate fix against both game classes (IG_-rejecting: this report's HSR case; IG_-requiring: Detroit/libScePad-style) — they form a neat inverted test pair for whatever exposure/dedup policy lands.