Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with the extra trigger axes and the SDL_Joystick API #385

Closed
9 of 41 tasks
orbea opened this issue Sep 3, 2022 · 9 comments
Closed
9 of 41 tasks

Issues with the extra trigger axes and the SDL_Joystick API #385

orbea opened this issue Sep 3, 2022 · 9 comments

Comments

@orbea
Copy link

orbea commented Sep 3, 2022

Version of xpadneo

kakra/linux#15

Controller Model

  • Xbox One S controller
  • Xbox Elite 2 controller
  • Xbox Series X|S controller
  • Other: 8bitdo SN30 Pro+

Connection mode

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

Installed Software

N/A

  • Anti-Micro (may affect button mappings)
  • OpenRGB (may mess up mappings and rumble stability)
  • Steam Input (enabled by default via Steam Desktop client)
  • Steam Link (usually via Raspberry Pi or other micro computers)
  • devices with QMK firmware (may affect udev rules, similar to OpenRGB)
  • netstick (shares input devices via network similar to Steam Link)
  • xboxdrv (user-space gamepad driver)
  • xone (kernel-space gamepad driver using the Xbox dongle or USB)
  • xow (alternative driver using the Xbox dongle)

Protocol Information

Please help us identify at which layer the problem can be found if you want
to report mapping errors or if the controller fails to be detected:

  • Steam Proton games are having issues
  • Steam Linux-native games are having issues
    • I don't use Steam or did not try
  • games running through Lutris, wine and/or Bottles are having issues
    • I don't use Lutris, Bottles, wine or did not try
  • Linux-native games are having issues
    • I don't use native games or did not try
  • Other software is having issues (describe software and issues below)
  • Running evtest is showing issues (describe the issues below)
    • Keep in mind that BTN_NORTH and BTN_WEST are intentionally swapped
  • Running jstest is showing issues (describe the issues below)
    • I don't have this tool or don't know how to use it
  • Running gamepad-tool is showing issues (post console output below)
    • I don't have this tool

Please describe how it is failing below in the next sections.

Severity / Impact

  • I've read the docs and the bug reporting instructions
  • I've applied the latest firmware update to the controller
  • I've tried disabling or running without above mentioned software
  • 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

In some SDL2 and maybe other programs with their own input config they will erroneously configure the extra rudder (?) axes instead of the axes for the trigger.

For example L2 will activate axes 2+ and axes 6- while R2 has axes 5+ and 6+ where SDL2 will see the extra axes 6 events before the real L2/R2 events for axes 2 and 5. This then will cause runtime issues for the game.

Steps to Reproduce

For example this can be reproduced with the jgrf frontend (https://gitlab.com/jgemu/jgrf) which requires the jg headers (https://gitlab.com/jgemu/jg) and the mednafen core (https://gitlab.com/jgemu/mednafen) which supports L2 and R2 input with any playstation 1 games. This gentoo overlay (https://0xacab.org/orbea/jgemu) may speed up the process.

  1. Load any PSX games: jollygood /path/to/file.cue
  2. Press shift+1 to configure the first input device.
  3. View the generated config in ~/.config/jollygood/input_psx.ini.

Note that jgrf has added a hack to avoid this issue, but there is probably a better way.

https://gitlab.com/jgemu/jgrf/-/commit/bb349aa2eb532b57524e8a374515b9ef8172aa72

Expected Behavior

Would it be possible to switch the order of events so that SDL2 will see axes 2 and 5 before axes 6? Or is there a good reason this can't be done? If so are there any suggested ways for the program to avoid this issue? In these cases the program needs the SDL_Joystick API and the SDL_GameController API is not appropriate.

Screenshots / GIFs / Videos

jstest (No input)
xpad

jstest (L2 held down)
xpad-l2-down

jstest (L2 released)
xpad-l2-up

jstest (R2 held down)
xpad-r2-down

jstest (R2 released)
xpad-r2-up

System Information

$ uname -a
Linux gentoo 5.15.64-x86_64 #1 SMP PREEMPT Thu Sep 1 15:17:19 PDT 2022 x86_64 Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz GenuineIntel GNU/Linux
# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
00000000: 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff  .............0.1..'.
00000014: ff 00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 33 09 34 15 00  .....u.........3.4..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 01 09 32 15 00 26 ff  '......u.......2..&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09  ...u.....%.u........
00000050: 35 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  5..&....u.....%.u...
00000064: 81 03 05 01 09 39 15 01 25 08 35 00 46 3b 01 66 14 00 75 04  .....9..%.5.F;.f..u.
00000078: 95 01 81 42 75 04 95 01 15 00 25 00 35 00 45 00 65 00 81 03  ...Bu.....%.5.E.e...
0000008c: 05 09 19 01 29 0a 15 00 25 01 75 01 95 0a 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 06 95 01 81 03 05 01 09 80 85 02 a1 00 09 85 15 00 25 01  u.................%.
000000b4: 95 01 75 01 81 02 15 00 25 00 75 07 95 01 81 03 c0 05 0f 09  ..u.....%.u.........
000000c8: 21 85 03 a1 02 09 97 15 00 25 01 75 04 95 01 91 02 15 00 25  !........%.u.......%
000000dc: 00 75 04 95 01 91 03 09 70 15 00 25 64 75 08 95 04 91 02 09  .u......p..%du......
000000f0: 50 66 01 10 55 0e 15 00 26 ff 00 75 08 95 01 91 02 09 a7 15  Pf..U...&..u........
00000104: 00 26 ff 00 75 08 95 01 91 02 65 00 55 00 09 7c 15 00 26 ff  .&..u.....e.U..|..&.
00000118: 00 75 08 95 01 91 02 c0 85 04 05 06 09 20 15 00 26 ff 00 75  .u........... ..&..u
0000012c: 08 95 01 81 02 c0                                            ......
3445511648 1458

Controller and Bluetooth Information

xpadneo-btmon.txt
xpadneo-dmesg.txt
xpadneo-lsusb.txt

Additional Context

N/A

@orbea
Copy link
Author

orbea commented Sep 3, 2022

The jgemu developer made a simple test program that better shows this.

test.c.txt

Build with: gcc $(pkg-config --cflags --libs sdl2) test.c

And this reveals that the above is slightly wrong, L2 always (?) has the event for axis 2 first while R2 has axis 6.

L2

$ ./a.out 
Joystick Connected: Xbox One S Controller
	Instance ID: 0, Player: 0
Ports: 1 0 0 0

Axis 2
Axis 2
Axis 6
Axis 6
Axis 2
Axis 6
Axis 2
Axis 6
Axis 2
Axis 6
Axis 2
Axis 6

R2

$ ./a.out 
Joystick Connected: Xbox One S Controller
	Instance ID: 0, Player: 0
Ports: 1 0 0 0

Axis 6
Axis 6
Axis 5
Axis 5
Axis 6
Axis 5
Axis 6
Axis 5
Axis 6
Axis 5
Axis 6
Axis 5

This order seems pretty consistent, but I am not sure if it is always so?

@kakra
Copy link
Collaborator

kakra commented Sep 5, 2022

The joydev devices always order axes by their event number - which is wrong for HID controllers as it doesn't match the original expectation of joydev (I'd say, that's a flaw internally in the kernel input layers). You can use jscal to re-order the axes but that confuses programs that already fix the broken behavior internally. OTOH, joydev is an old API and should not be used any longer.

I'll probably remove the extra trigger axis with the next update, or at least change its behavior to either only send the non-combined values, or the combined value - but not both.

@orbea
Copy link
Author

orbea commented Sep 5, 2022

I'll probably remove the extra trigger axis with the next update, or at least change its behavior to either only send the non-combined values, or the combined value - but not both.

Maybe an option could be added to enable the double axis which would be disabled by default in case someone really needs that? I'm not sure if that is worthwhile.

kakra added a commit to kakra/xpadneo that referenced this issue Sep 15, 2022
Switching to PID 0x028E seems to successfully evade the mappings in
Proton, and thus probably SDL.

Proton seems to do the same for Steam virtual controllers, and it
seems to also fix gamepad handling in Chrome.

Maybe-fixes: atar-axis#379
Maybe-affects: atar-axis#385
Maybe-affects: ValveSoftware/steam-for-linux#8463 (comment)
See-also: atar-axis#283
See-also: ValveSoftware/wine@7ea1cc2
Fixes: atar-axis#373
Signed-off-by: Kai Krakow <kai@kaishome.de>
kakra added a commit to kakra/xpadneo that referenced this issue Sep 15, 2022
Switching to PID 0x028E seems to successfully evade the mappings in
Proton, and thus probably SDL.

Proton seems to do the same for Steam virtual controllers, and it
seems to also fix gamepad handling in Chrome.

Maybe-fixes: atar-axis#379
Maybe-affects: atar-axis#385
Maybe-affects: ValveSoftware/steam-for-linux#8463 (comment)
See-also: atar-axis#283
See-also: ValveSoftware/wine@7ea1cc2
Fixes: atar-axis#373
Signed-off-by: Kai Krakow <kai@kaishome.de>
@kakra
Copy link
Collaborator

kakra commented Sep 15, 2022

@orbea Can you retry with latest master?

@kakra kakra added this to To do in Compatibility and Compliance via automation Sep 17, 2022
@kakra kakra added the 0 | type: bug Something isn't working label Sep 17, 2022
@kakra kakra added this to the v0.10 milestone Sep 17, 2022
kakra added a commit that referenced this issue Sep 17, 2022
Switching to PID 0x028E seems to successfully evade the mappings in
Proton, and thus probably SDL.

Proton seems to do the same for Steam virtual controllers, and it
seems to also fix gamepad handling in Chrome.

Maybe-fixes: #379
Maybe-affects: #385
Maybe-affects: ValveSoftware/steam-for-linux#8463 (comment)
See-also: #283
See-also: ValveSoftware/wine@7ea1cc2
Fixes: #373
Signed-off-by: Kai Krakow <kai@kaishome.de>
@orbea
Copy link
Author

orbea commented Sep 17, 2022

@kakra Given that I have xpadneo built into the kernel I am not sure the best route to updating it?

@kakra
Copy link
Collaborator

kakra commented Sep 17, 2022

If you've built it into the kernel as a module, you can just re-install from this git repo. I'm doing it the same way, haven't updated my kernel patch yet.

You can run make -C hid-xpadneo reinstall from the repository root, should work out-of-the-box with Gentoo. It will also do the module reloading. Run as user, it will automatically ask for sudo permissions.

@orbea
Copy link
Author

orbea commented Sep 17, 2022

That was easier than I imagined...

However I see no difference in behavior?

This is with commit 48f4b11 and I built it following the generic build instructions.

cd hid-xpadneo && make modules && sudo make modules_install

I explicitly unloaded the xpadneo module with rmmod and manually removed the old module to make sure it is the new module installed.

@kakra
Copy link
Collaborator

kakra commented Sep 17, 2022

However I see no difference in behavior?

Okay, I was hoping the PID change may change how SDL behaves for you. So I still need to fix the axis thing. BTW: I updated my previous commit with instructions how I reinstall the module during development.

@kakra
Copy link
Collaborator

kakra commented Jun 17, 2023

@orbea Could you check if this is still an issue with the latest versions of SDL2 and xpadneo? If you cannot use SDL2 release candidates, you'd have to wait for SDL2 2.28.

@kakra kakra closed this as completed in 2e3b406 Feb 13, 2024
Compatibility and Compliance automation moved this from To do to Done Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants