https://bugs.kde.org/show_bug.cgi?id=525664
Bug ID: 525664
Summary: KWin GameController plugin misinterprets alternate
Bluetooth gamepad axis layouts
Classification: Plasma
Product: kwin
Version First 6.6.6
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: input
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
DESCRIPTION
KWin's GameController plugin appears to assume a fixed evdev axis layout for
gamepads.
My EasySMX X20 works correctly over USB, but over Bluetooth the desktop
controller-as-pointer/keyboard behavior is incorrect even though the controller
itself is detected and all controls work correctly in System Settings -> Game
Controller.
Over Bluetooth the controller is exposed as:
Xbox Wireless Controller
VID:PID 045e:02fd
The raw evdev axis layout is:
ABS_X / ABS_Y = left stick
ABS_Z / ABS_RZ = right stick
ABS_BRAKE / ABS_GAS = analog triggers
ABS_HAT0X / HAT0Y = D-pad
There are no ABS_RX / ABS_RY axes.
KWin's controller plugin appears to expect:
ABS_X / ABS_Y = stick/pointer
ABS_RX / ABS_RY = stick/pointer
ABS_Z / ABS_RZ = trigger mouse buttons
As a result, the Bluetooth right stick is interpreted as trigger input, while
the actual triggers on ABS_BRAKE / ABS_GAS are not handled as mouse buttons.
USB mode works correctly.
STEPS TO REPRODUCE
1. Connect an Xbox-compatible Bluetooth controller whose evdev layout uses
ABS_Z / ABS_RZ for the right stick and ABS_BRAKE / ABS_GAS for triggers.
2. Enable KWin's controller-as-pointer/keyboard functionality.
3. Use the controller on the Plasma Wayland desktop.
OBSERVED RESULT
The controller is correctly detected and works in the Game Controller test
page, but desktop input is incorrect.
Pointer movement partially works, but right-stick and trigger behavior is wrong
because KWin interprets the reported axes using a different assumed layout.
EXPECTED RESULT
KWin should correctly handle valid alternate evdev gamepad layouts instead of
assuming ABS_RX/ABS_RY are always the right stick and ABS_Z/ABS_RZ are always
triggers.
Ideally the mapping should be derived from the device's actual capabilities or
controller mapping so this works for Xbox-compatible Bluetooth controllers
generally.
SOFTWARE/OS VERSIONS
Operating System: Ubuntu 26.04 Resolute / Armbian unofficial 26.11.0-trunk
Kernel: 7.2.5-edge-rockchip64
Architecture: arm64
KDE Plasma Version: 6.6.6
KWin Version: 6.6.6
Session: Wayland
ADDITIONAL INFORMATION
Controller:
EasySMX X20 in Xbox Bluetooth mode
Bluetooth device:
Xbox Wireless Controller
VID:PID 045e:02fd
The KDE Game Controller test page sees the controller inputs correctly.
Raw evtest output confirms:
- ABS_X / ABS_Y
- ABS_Z / ABS_RZ
- ABS_BRAKE / ABS_GAS
- ABS_HAT0X / ABS_HAT0Y
USB connection of the same controller works correctly with KWin's
controller-as-pointer behavior.
Suggested broader fix:
Rather than hard-coding raw evdev axis/button codes directly to desktop
actions, the GameController plugin could first normalize each physical device
into a logical controller layout.
That normalized layer would identify:
- left/right stick axes
- left/right trigger axes
- d-pad
- face buttons
- shoulders
- start/select/guide
Where possible, the mapping should come from an existing standardized
controller mapping source/API rather than maintaining KWin-specific device
quirks.
As a practical fallback, KWin could infer mappings from the evdev capabilities
exposed by the device.
For example:
- if ABS_RX/ABS_RY are present, use them as the right stick and ABS_Z/ABS_RZ as
triggers
- if ABS_RX/ABS_RY are absent but ABS_Z/ABS_RZ and ABS_BRAKE/ABS_GAS are
present, use ABS_Z/ABS_RZ as the right stick and ABS_BRAKE/ABS_GAS as triggers
The same idea could apply to button normalization before mapping buttons to
desktop actions.
This would avoid per-device VID:PID special cases and should improve
compatibility across a wider range of USB and Bluetooth gamepads, including
third-party Xbox-compatible controllers.
--
You are receiving this mail because:
You are watching all bug changes.
