-
Notifications
You must be signed in to change notification settings - Fork 111
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
Comments
The jgemu developer made a simple test program that better shows this. Build with: And this reveals that the above is slightly wrong, L2
R2
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 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. |
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>
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>
@orbea Can you retry with latest master? |
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>
@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 |
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.
I explicitly unloaded the xpadneo module with |
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
kakra/linux#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)
jstest (L2 held down)
jstest (L2 released)
jstest (R2 held down)
jstest (R2 released)
System Information
Controller and Bluetooth Information
xpadneo-btmon.txt
xpadneo-dmesg.txt
xpadneo-lsusb.txt
Additional Context
N/A
The text was updated successfully, but these errors were encountered: