Closed orbea closed 4 months ago
The jgemu developer made a simple test program that better shows this.
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?
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.
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.
@orbea Can you retry with latest master?
@kakra Given that I have xpadneo built into the kernel I am not sure the best route to updating it?
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.
That was easier than I imagined...
However I see no difference in behavior?
This is with commit 48f4b119fdef9479d5e45056dc7a234e8959af0d 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.
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.
@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.
Version of xpadneo
https://github.com/kakra/linux/pull/15
Controller Model
Connection mode
Installed Software
N/A
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:
evtest
is showing issues (describe the issues below)BTN_NORTH
andBTN_WEST
are intentionally swappedjstest
is showing issues (describe the issues below)gamepad-tool
is showing issues (post console output below)Please describe how it is failing below in the next sections.
Severity / Impact
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- whileR2
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
andR2
input with any playstation 1 games. This gentoo overlay (https://0xacab.org/orbea/jgemu) may speed up the process.jollygood /path/to/file.cue
shift+1
to configure the first input device.~/.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 theSDL_GameController
API is not appropriate.Screenshots / GIFs / Videos
jstest (No input)![xpad](https://user-images.githubusercontent.com/4204285/188286276-4a66961b-84ed-43c2-a8a3-ce1b0fbeecac.png)
jstest (L2 held down)![xpad-l2-down](https://user-images.githubusercontent.com/4204285/188286299-e9efa60d-0685-499e-a0da-afc9d7c5927e.png)
jstest (L2 released)![xpad-l2-up](https://user-images.githubusercontent.com/4204285/188286310-6322aa2f-ff7d-4f68-a6f0-1032c3e2a5a4.png)
jstest (R2 held down)![xpad-r2-down](https://user-images.githubusercontent.com/4204285/188286316-81818465-533a-41e9-b5a7-b7900c460105.png)
jstest (R2 released)![xpad-r2-up](https://user-images.githubusercontent.com/4204285/188286329-dcea4d55-af4f-4d9d-b270-53a0c76e0ab4.png)
System Information
Controller and Bluetooth Information
xpadneo-btmon.txt xpadneo-dmesg.txt xpadneo-lsusb.txt
Additional Context
N/A