Mouse mode doesn't move the cursor

[JonisK]

Version of xpadneo

git master at commit cf392a7

Controller Model

• Xbox One S controller
• Xbox Elite 2 controller
• Xbox Series S controller
• Xbox Series X controller
• Other:

Connection mode

• Bluetooth connection
• Xbox Dongle connection (not yet supported)
• USB cable (not yet supported)

Installed Software

• Steam Input (enabled by default via Steam Desktop client)
• Steam Link (usually via Raspberry Pi or other micro computers)
• xow (alternative driver using the Xbox dongle)
• Anti-Micro (may affect button mappings)
• netstick (shares input devices via network similar to Steam Link)
• xboxdrv (user-space gamepad driver)
• AntiMicroX

Severity / Impact

• I've read the docs and the bug reporting instructions
• I've applied the latest firmware update to the controller
• It does not work at all
• It used to work in a previous version
• It mostly works but sometimes it doesn't
• I found a work-around
• I probably didn't figure it all out but it's too early to give up
• I don't know how to ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the Bug

When activating mouse mode by simultaneously pressing the Xbox and Select button, I cannot move my cursor or click buttons. The dmesg log indicates that mouse mode has been activated though:

[ 2389.685259] xpadneo 0005:045E:0B13.0007: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x02E0)
[ 2389.685268] xpadneo 0005:045E:0B13.0007: working around wrong SDL2 mappings (changed version from 0x00000501 to 0x00000903)
[ 2389.685272] xpadneo 0005:045E:0B13.0007: report descriptor size: 283 bytes
[ 2389.685275] xpadneo 0005:045E:0B13.0007: fixing up Rx axis
[ 2389.685277] xpadneo 0005:045E:0B13.0007: fixing up Ry axis
[ 2389.685279] xpadneo 0005:045E:0B13.0007: fixing up Z axis
[ 2389.685281] xpadneo 0005:045E:0B13.0007: fixing up Rz axis
[ 2389.685282] xpadneo 0005:045E:0B13.0007: fixing up button mapping
[ 2389.685618] xpadneo 0005:045E:0B13.0007: gamepad detected
[ 2389.685620] xpadneo 0005:045E:0B13.0007: enabling compliance with Linux Gamepad Specification
[ 2389.685684] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.0007/input/input23
[ 2389.685957] xpadneo 0005:045E:0B13.0007: input,hidraw3: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on 14:f6:d8:41:ba:30
[ 2389.686029] input: Xbox Wireless Controller Consumer Control as /devices/virtual/misc/uhid/0005:045E:0B13.0007/input/input24
[ 2389.686089] xpadneo 0005:045E:0B13.0007: consumer control added
[ 2389.686095] xpadneo 0005:045E:0B13.0007: controller quirks: 0x00000050
[ 2389.686097] xpadneo xpadneo_welcome_rumble start
[ 2390.668646] xpadneo xpadneo_welcome_rumble took 980ms
[ 2390.668654] xpadneo 0005:045E:0B13.0007: Xbox Wireless Controller [44:16:22:70:c4:fc] connected
[ 2405.209875] xpadneo 0005:045E:0B13.0007: mouse mode enabled

Mouse mode works though when I re-install from @kakra's branch in pull request #282

As a gamepad, the controller works fine with xpadneo. Thanks a lot btw for this cool piece of software!

Steps to Reproduce

1. Connect controller
2. Press Xbox+Select
3. Move left stick

Expected Behavior

While in mouse mode, I expect the left stick to move the mouse cursor and A or LT to emulate a mouse click.

Screenshots / GIFs / Videos

System Information

• Ubuntu 21.10 x86 64bit
• Intel AX200 WiFi+BT card

# uname -a
Linux ubuntu-desktop 5.13.0-23-generic #23-Ubuntu SMP Fri Nov 26 11:41:15 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
xxd: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:0B13.0074/report_descriptor: Permission denied
4294967295 0

Controller and Bluetooth Information

xpadneo-btmon.txt

xpadneo-lsusb.txt
xpadneo-dmesg.txt

Additional Context

[kakra]

Only the mode switching has been implemented in master yet. The mouse movements itself still live in a branch:
https://github.com/kakra/xpadneo/commits/queue/reimplement-mouse-mode

I'm not yet happy with sensitivity and still need to figure out if we can bring up an on-screen keyboard somehow. Also, I do not like that I'm starting a timer to sample the virtual mouse movement, I'd rather dynamically update the mouse axes on events from the controller but that's difficult for maintaining constant speeds, and if you hold the sticks in some place, it would generate no more events.

Maybe you didn't checkout the correct branch? Also, maybe there's a conflict with udev rules and the system doesn't properly pick it up as a mouse pointer then. But with the correct branch, it should show "mouse added" in dmesg before "mouse mode enabled":

• kakra@3d736f2#diff-6b7b5c77e7d27e92d08d75b6e453a4724b61740f8ae8de6ba8168204c4ee7932R116
• kakra@3d736f2#diff-6b7b5c77e7d27e92d08d75b6e453a4724b61740f8ae8de6ba8168204c4ee7932R146

[JonisK]

Hi,
Thanks for the quick response!
I wasn't aware that only the mouse mode but no actual mouse functionality have been merged into main yet. This explains why I need to checkout kakra:queue/reimplement-mouse-mode to get cursor movement.

Personally, I will then stick with the branch from the pull request since it is usable enough already to switch between games without getting up from the couch :)

Could you rephrase the text in the README.md? Currently it advertises the mouse mode as if it was fully functional already:

Works as a mouse if you're are in couch-mode (press Guide+Select)

Cheers

[kakra]

Could you rephrase the text in the README.md?

Good point, that shouldn't have been there yet. Probably happened during cherry-picking.

[JonisK]

Ok, that solves my issue then I guess. Thanks for the clarification!

[kakra]

Don't close it on your behalf, otherwise I'm missing that point on my agenda.

[JonisK]

kk

[Bitwolfies]

Should split it into planned features and implemented features, since its still not in mainline (didnt work for me), should also have guides for some of this stuff, no idea how to enable the "high precision mode" or the auto trigger rumble.

[kakra]

"high precision mode" disables dead zones in the Linux input layer so Proton games do not apply a second dead zone but the only dead zone (this is actually something that happens in SDL2 and wine). I've fixed the docs, also temporarily removing the line about mouse mode. Mouse mode is queued in my feature queue and scheduled for merge when or shortly after tagging v0.10.

Automatic trigger rumble rumbles the triggers based on pressure when one of the main motors rumble. This is used because the kernel does not yet support a third and fourth rumble motor (a kernel patch for that is queued).

[Bitwolfies]

Does the auto rumble interfere with games that actually natively use the rumble triggers? There's not a lot of them but they do exist.

I also assume your proton fix is automatic? I have zero idea how id toggle it if's not.

[kakra]

No, it cannot interfere... If SDL supports it for you, it does so through the hidraw interface. The kernel does not yet provide the proper interfaces. And if it does, I have to adjust xpadneo to actually make use of it. I'm probably going to look into some heuristics to detect whether a game sends trigger rumble or doesn't and automatically adjust how the driver works, so older games can still benefit from our "simulation". Also, I don't think Proton currently supports it although SDL may have the interfaces already. Take note that if it is supported, then only in hidraw mode - which xpadneo udev rules disable due to instabilities of the controller firmware resulting from SDL rumble programming and button mapping issues.

Older proton versions should adjust automatically if you enabled high precision mode via module parameters. Newer Proton versions may have a fix to ignore driver dead zones on their own given that SDL2 was patched. The issue was reported and handled here: ValveSoftware/wine#94, my patch for SDL should be upstream.

The SDL patch request was originally tracked in the SDL bugzilla and since migrated to Github, so I'm not really sure about the status: libsdl-org/SDL#3781

Enabling high precision mode works around that in any case, no matter if a patch was applied. It's meant for games that apply their own dead zone handler after the Linux input handler (many games use radial dead zones while the Linux input layer and SDL use axial dead zones which is very strange and feels laggy/non-precise when combined). Use the module parameter disable_deadzones=1 for this, it defaults to 0. It must be applied at module load time and cannot be set through /sys/module/hid_xpadneo/parameters/disable_deadzones (read-only). But you can verify it's set by looking at that file, and dmesg will actually tell you when you connect a controller.

BTW: Running modinfo hid-xpadneo will document the module parameters, the left-most value is always the default.