Open Frederick888 opened 2 years ago
Sorry forgot to provide those info
I'm using X11/KDE on latest Arch Linux (regular kernel).
I can't reproduce the problem in my environment. I applied your patch, tried starting xremap with a mouse enabled while moving it, and tried starting xremap while pressing Enter forever. But none of them kept printing the logs you added.
Looking at https://bugs.freedesktop.org/show_bug.cgi?id=101796, it feels like this kind of thing is a problem that needs to be fixed on the driver's side, not xremap's, especially when you're using the bleeding-edge version on Arch Linux.
Because I cannot reproduce this issue on my end, there's no way to fix it for me. Could you provide a virtual machine (e.g. VirtualBox) and the minimum steps to reproduce the problem on it? If it's too hard or even it doesn't reproduce the issue in my environment, I need you to file a pull request yourself.
Same bug here.
xremap 0.7.8
X11
Linux 6.0.1-arch2-1 #1 SMP PREEMPT_DYNAMIC Thu, 13 Oct 2022 18:58:49 +0000 x86_64 GNU/Linux
Steps to reproduce
Start xremap with Ctrl key on terminal: Ctrl+Enter
Release Ctrl
key
Now you have Ctrl
on every key press:
Press again Ctrl
to release the Ctrl
. Everything is fine now:
Same bug for the Shift key. Probably Alt key too and other keys etc.
Steps to reproduce
xremap path/to/config
Ctrl+z
------------------------------------------------------------------------------
Selected keyboards automatically since --device options weren't specified:
------------------------------------------------------------------------------
/dev/input/event2 : <Insert the keyboard here>
------------------------------------------------------------------------------
^Z
zsh: suspended xremap Documents/xremap.yml
[USER@HOSTNAME ~]$ ^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z <IT DOESN'T STOP>
Ctrl+c
Can also confirm this issue exists. I experienced it once when accidentally pressing the windows key while starting xremap, and another time when accidentally pressing the up arrow key.
This causes xremap to be unusable for me until it is fixed, as I run xremap periodically via a cronjob and hence can not guarantee that I am not holding down a key while it starts (I probably am).
Thanks for all the reports.
Now, I've learned from a friend that xremap could check which keys are currently pressed when xremap starts if you check the output of ioctl with that device and EVIOCGKEY
. We need to integrate that evdev interface to fix the problem. At the moment I don't have the bandwidth to immediately write a patch myself, especially when I don't have this issue (I just automatically start xremap on boot, and I don't need to restart it), but I would merge a pull request to fix it if filed.
xremap
version: 0.7.6Command line:
xremap --ignore='Yubico YubiKey OTP+FIDO+CCID' --mouse --watch=device "$HOME/.config/xremap/config.yml"
Config:
I added below logs:
Regular startup (if I start typing or moving mouse after
xremap
starts):Log if I keep a key pressed down when
xremap
starts (and I can see the key keeps repeating later even after I've released the key):Log if I keep moving my mouse when
xremap
starts (the event isa 'force feedback status', which isn't even supported by my mousean LED event. and CPU usage ofxremap
immediately shoots up to 100% in this case, freezing all my keyboards and mouse. I have to re-connect devices to regain control.):