Input Remapper causing stuttering in video games
Posted by Racke7@reddit | linux | View on Reddit | 12 comments
Realized today that Input-Remapper, which I've been using to put keyboard-inputs (Alt and Shift) on my mouse-buttons, is causing games to lag and stutter when I press those mouse-buttons.
I'm not entirely sure why this is, and I would like to either fix it somehow, or switch to a program where this isn't a problem.
One thing I'm wondering about is if it's related to it having to go through Wine, and if it's possible to then bypass Input-Remapper in some type of launch-argument (like a more complex version of launching it with a specific keyboard-layout).
AutoModerator@reddit
This submission has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
natermer@reddit
It is likely just a bug in input-remapper or maybe a issue on how you are configuring things.
You can try out tools like 'evtest' and 'xev' to see what is actually going on.
The first thing I'd look for is to make sure that alt on the mouse behaves the same as if you pressed alt on the keyboard. My first guess is that it is setting alt repeating, like if you were to hold down a normal key and let it repeat. And the games don't know how to deal with that.
Racke7@reddit (OP)
Sounds somewhat plausible, but I can't actually check that with evtest, since Input-Remapper "captures" the mouse, so evtest just... refuses to try to interpret it.
Not sure how else I'm supposed to write it though, because currently it's just set as:
KEY_LEFTSHIFTBut you're right, when I do it with a button for "scrolling", it'll constantly update (down/up) when you hold in the button. Unlike how switching the mouse-buttons around in
xinputwill make the scroll happen only a single time per button-press. So definitely very plausible.natermer@reddit
the way these things work is by create a virtual /dev/input/* device that is the one that ends up getting used by your display manager/X11 server.
so just running evtest without arguments should show you what device is being created by input-mapper. And you should be able to run evtest against that one.
I don't use input-remapper, but i use houmain/keymapper and it works on the same principals and I was able to use evtest against that.
Racke7@reddit (OP)
Ah, the output was in the virtual keyboard, not the virtual mouse. Makes sense.
But actually no. It presses down when I press down, and then just holds it like that, no new inputs. Then releases it when I release it. No multi-pressing involved.
So the reason for why it lags so bad when it's pressed down multiple times (as in, writing "sSsSsS" in a notepad for testing-purposes) isn't that.
natermer@reddit
Ah that is too bad.
FattyDrake@reddit
What brand/model mouse? Sometimes there's specific libraries/drivers/apps for them (like OpenRazer for their peripherals.) might be worth searching for if it's a popular brand.
ipsirc@reddit
average python performance...
Racke7@reddit (OP)
Yeah, I ended up finding a very easy test for my problem in the process of getting this installed to try it out.
Open a text document, and then press the mouse-button for
shiftand a number that gets replaced by it. Then just spam-press both buttons. If you do this on the keyboard, it'll give you some semi-random results.If you do this with Input-Remapper (or Makima, I'm sorry to say) it'll lag to shit and force you to wait for the result to appear for up to a second or two.
So, from further testing, it's not the game in specific, but very much something in how these programs approach "replace mouse-input". Which is... not giving me a lot of hope for finding a solution.
Ok_Instruction_3789@reddit
wish there were better alternatives to remapping mouse button keys on multi button mice. Its 2025 already how is there nothing out of the box.
Every once in awhile i run into issues with input-remapper either not firing or something else. hopefully its a simple fix.
ipsirc@reddit
maybe udev? https://bbs.archlinux.org/viewtopic.php?id=260824
natermer@reddit
Unless you are able to somehow configure the firmware on the mice directly the best thing you can do is intercept it at the input layer and deal with it in software. Which is what software like input-remapper does.
Being able to configure the firmware on the mice usually requires a special software and/or drivers, which kinda requires the manufacturer to write a utility to make it work on Linux. Unless there is some sort of generic interface to configure these devices, which I don't think exists.
The best approach for dealing with customizing inputs is to use something with open source firmware support you can program it to do whatever you want.
Like with Ploopy mice and trackballs.