[Bug 60226] New: Wine XInput: XInputGetState returns 0 buttons for connected Bluetooth Xbox One controller
http://bugs.winehq.org/show_bug.cgi?id=60226 Bug ID: 60226 Summary: Wine XInput: XInputGetState returns 0 buttons for connected Bluetooth Xbox One controller Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: xinput Assignee: wine-bugs@list.winehq.org Reporter: lifeartas1@gmail.com Target Milestone: --- Distribution: --- Created attachment 81926 --> http://bugs.winehq.org/attachment.cgi?id=81926 Complete Wine XInput probe output and stderr (wine-staging 11.13) plus evdev monitor capture of the connected Bluetooth Xbox One controller On a clean Wine prefix (default layout, no DLL overrides, no third-party DLLs), a standalone Windows XInput probe polling XInputGetState(0) reports the controller as CONNECTED (result == ERROR_SUCCESS) but the button/trigger/thumb-stick state is permanently zero — buttons=0x0000, rt=0, lt=0, lx=0, ly=0 — even while the physical buttons and D-pad are pressed. The kernel-level input IS delivered to the controller's evdev node (a monitor captures button/axis events), so the break is in Wine's XInput backend: it enumerates the controller but never maps incoming HID/evdev input into the XINPUT_STATE it returns. Environment: - Nobara Linux 44 (KDE Plasma), x86_64 - Kernel: 7.1.4-200.nobara.fc44.x86_64 - Wine: 11.13 (Staging), package wine-staging-11.13-1.x86_64 - Controller: Microsoft Xbox Wireless Controller (Bluetooth), VID 045e PID 0b13, fw 0522 - Driver: xpadneo (hid-xpadneo) Repro: 1. Connect an Xbox One Wireless Controller over Bluetooth (xpadneo). 2. Create a clean prefix: WINEPREFIX=/tmp/wine-clean wineboot -i 3. Run a minimal XInput probe (loop XInputGetState(0) ~800x over 8s) under it while pressing A / D-pad. 4. Observed: t=0 result=0 packet=1 buttons=0x0000, then done — no button changes ever. Expected: XInputGetState(0) returns the pressed button bits when physical buttons are pressed, matching Windows. Actual: returns result=0 (connected) but buttons=0x0000 permanently, while the same presses produce valid events at the kernel evdev layer. Attached: complete probe output + wine stderr + evdev monitor capture. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60226 --- Comment #1 from lifeartas1@gmail.com --- Confirmed real-world impact + working workaround, and where the fix belongs. This Wine XInput bug (enumerate-connected-but-never-map-input) is the root cause of a shipped-game failure: Kingdom Come: Deliverance II 1.5.6 (Bluetooth Xbox) never receives input on Linux. The game's xinput0 stays connected: 0 despite Wine XInput reporting the controller connected; the permanently-zero button state means the game sees no input and never connects the pad. Reproduces across Proton Experimental, GE-Proton, and Wine Staging 11.13, with real Bluetooth Xbox (xpadneo) and synthetic uinput devices — so it is Wine XInput, not any single game. Workaround (bypasses XInput): present the Xbox as a native DualSense and use the game's separate, working Sony HID (scepad0) path: InputPlumber ds5 UHID target + DisableHidraw=0 in the prefix. KCD2 then logs m_ControllerType: DualSense and input works. Details on Proton issue 8727. Suggested fix location: the fault is in Wine's XInput backend not feeding HID/evdev events into the returned XINPUT_STATE. Relevant code: dlls/xinput1_3/xinput_main.c / dlls/xinput1_3/xinput_hid.c and the bus enumeration in dlls/winebus.sys (unixlib.c) plus dlls/hidclass.sys. The controller IS enumerated (XInputGetState returns SUCCESS, packet increments) but XINPUT_STATE.Gamepad is never populated from the device's incoming HID/evdev reports. A dev would need to verify the HID report path from winebus.sys → xinput_hid.c for a Bluetooth (xpadneo, hid_xpadneo) device — the SDL path works but the native HID/evdev mapping into XINPUT_STATE does not. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60226 --- Comment #2 from Ken Sharp <imwellcushtymelike@gmail.com> --- This may already be fixed in the latest release. https://gitlab.winehq.org/wine/wine/-/wikis/Download -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60226 lifeartas1@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |fe9533f9 --- Comment #3 from lifeartas1@gmail.com --- Verified fixed. Standalone XInput probe (XInputGetState(0) loop, same binary, same Bluetooth Xbox 045e:0b13, fresh prefix, DisableHidraw=0): 11.13: connected, axes update, but Gamepad.wButtons stays 0x0000 → bug reproduced. 11.16: connected, Gamepad.wButtons updates correctly (0x0002 D-pad, 0x1000 A) → fixed. The fix is in winebus.sys, not xinput. Candidate commit fe9533f9 "winebus: Fix initial axis values for evdev gamepads" (lands in 11.15, 2026-08-08). No dlls/xinput1_3 changes in 11.13..11.16. Resolving FIXED. Note: only reaches games once a Proton build rebases onto Wine ≥ 11.15; the original shipped-game case (KCD2) still needs that rebase to re-validate in-game. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60226 --- Comment #4 from lifeartas1@gmail.com --- (In reply to Ken Sharp from comment #2)
This may already be fixed in the latest release. https://gitlab.winehq.org/wine/wine/-/wikis/Download
Thank you! :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla