Conversation
Patches to the build scripts to use new dependencies and to use evdev instead of joydev on linux which involved updates to several files, assisted by Cursor Composer AI. Tested working on CachyOS 03/07/2026 I was able to make and install over the original version I was testing, and the evdev patch has updated: joydev is deprecated and calls are not supported. evdev code switching resulted in restoring proper function for analog inputs/axises/joysticks, and support for any other modern controller features afforded by evdev over joydev. GIMX appears to be abandoned, but I'll make an effort to merge, however I may take this over and just keep it alive and working with the features it has now.
forked smaller modules associated with the project that required updates also.
Updating syscalls on linux to use evdev instead of joydev, tested changes working with multiple devices connected at once and correct device identifications as expected
1. Phase 1: js-based discovery Scans /dev/input/js* (js0, js1, js2, …). For each jsX, resolves the event device via /sys/class/input/jsX/device/. Uses is_event_in_device so both DT_DIR and DT_LNK are accepted. Adds devices in the same order as jstest. Each js* maps to the main controller interface, not motion sensors. 2. Phase 2: event-first fallback Scans /dev/input/event* for devices with EV_ABS. Skips event devices already added in phase 1. Covers devices without js* (e.g. some wheels). 3. Helper functions open_evdev(js_name) – resolves event device from sysfs, with O_RDONLY fallback on EACCES. add_joystick_device() – shared device-add logic. mark_event_added() – records which event devices were added to avoid duplicates. 4. Event number limit Event device numbers up to 511 are supported (e.g. event256, event257).
|
If this doesn't work for one distro but does for another, then I don't mind maintaining a branch for evdev systems. Sorry I also didn't see any signs of life and thought you had left this behind. I'm very open to trying to contribute healthily towards just testing and adapting feature support for Linux. But this should be a complete working patch to replace joydev now and seamlessly integrate evdev without breaking anything only improving it. Specifically on modern Linux kernels. Joydev calls might be there still, but they don't work the way it used to anymore, evdev is the standard. Idk why it is it just is. |
|
It's correct that I no longer keep this project active. Nonetheless from time to time I have a look at the merge requests pushed here. It's interesting to see how people extend the code base on their side. I just compiled the code base with a newer gcc (12.2) and I fixed and pushed the compilation errors in the master branch. I do not observe issues using jstest-gtk with an old rumblepad 2 and a dualshock 4 v1 (with no calibration at all). Did you try using the calibration in jstest-gtk? Switching to evdev is likely to break compatibility with existing configurations, and it would require a lot of testing. I am unlikely to integrate these changes due to a lack of time. |
|
Hey matlo, I really appreciate the work you already put in to make this, and before AI was around I think too. You're correct that this breaks configurations, I have to make all of mine from scratch now, but I download the ones you've got so far and I use it as a base to simply change mappings. To be clear its not a calibration issue, it's a mapping issue and I suspect the kernel is to blame somehow but Idk. 6.19.6-2-cachyos is my uname -r. Just out of curiosity what are you on? For me the only issue is that jstest is identifying axes incorrectly, and for whatever reason, even if I update the mappings on jstest (which aren't on reboot) it's not respected by any applications making joydev calls, so I honestly have no idea why the kernel behaves like that but it is what it is. I understand. Fortunately it's not a heavy change, and I can always rebase if you ever update the core GIMX, and I can maintain this myself as a fork, or a separate branch in your project, I think honestly that would be best to have an evdev version separate because the linux ecosystem is a big place and I'm sure there's still lots of systems out there without broken joydev calls, but this adds compatibility for those like me at least. I appreciate you taking a look at this. If you don't mind I'll keep the pull request open as a link to my project for people who might find it useful. I'm going to be testing keyboard and mouse stuff very thoroughly, and maybe some racing wheel stuff and see what I can do about new versions of configs with evdev mappings if you think that is useful to provide with a future pull request and would like to see that. I'm going to put in the work so up to you how much you wanna be involved or anything. |
Added warning about GIMX fork and evdev support issues.
3 locations updated joypad, mkb, and ginput.h device max limit from 256 to 1024,, because evdev device event IDs often bump up higher than necessary for whatever reason and quickly populate ranges higher than 256.
2 participants
resolves dependencies on modern linux systems, updates code to use evdev calls and functions instead of joydev, which is not properly supported on Linux, it "works" but fails to provide accurate analog axis inputs, after thoroughly testing with DS3, DS4, Switch Pro, sunshine emulated DS5 and Xbox One, wireless and wired arrangements, all had same analog axis issues - axis inputs not respected, absolute inputs to the top left repeat sporatically sent to the destination console instead.
This patch works with evdev calls, and supports the larger numbering sequence evdev uses for input* files. I have tested and was able to detect at least 3 different controllers (ds3 wired, ds4 bluetooth, and sunshine emulated DS5) as input devices on linux and map all axis with correct and expected behaviors.
My first submission lacked a patch to accommodate the larger number sequencing so that's why it stopped detecting extra controllers beyond the first one. I also didn't understand submodule semantics on github. I think now I got it, and I'm submitting this on all the submodules.
Please consider, review, test on a modern linux system. This is I know working on CachyOS for me really well, and seems to have all the expected features working as intended again from what I've seen so far.
It is worth noting that I believe, and I think testing will prove, that evdev is generally superior to joydev, far more feature rich, more accurate device input type detection, special button support, rumble support. It is better at handling axis, identifying analog sticks from pressure triggers, rudders, etc, and ensuring their correct mappings.
If you are on a modern linux kernel and you run jtest-gtk you should see how bad the mappings are and why joydev isn't used now.
See this picture. This is the result of default configuration of a controller on new Kernel behavior, on the left is joydev results, on the right is evdev. See evdev has it all right from the beginning and every other app on my computer sees it this way. Note ABS_Z and the activated button, is me holding L2 axis trigger, joydev thinks it's my analog stick cause it doesn't have labels for anything, but even if I remap it there on jstest, it's not really fixing my input issue with analog sticks (especially Lstick) - I don't think it even does anything to remap them like they just don't apply. Those remappings cannot persist on reboot even if they did work.