-
Notifications
You must be signed in to change notification settings - Fork 173
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
key-mapper freezes external usb mouse and keyboard #140
Comments
All issues for which key-mapper somehow magically won't work in an environment are pretty much unsolvable for me, I don't even know how to debug X/Gnome or where to start. Sorry |
What does key-mapper do when connecting a new input device (like keyboard or mouse)? I do see several key-mapper-* processes and it seems that at some time there is a race condition or a service just hangs - then my input devices hang too and I need to kill all key-mapper services. I could try to debug that further but would need to understand the dependencies better. |
here is some info on how it works: https://github.com/sezanzeb/key-mapper/blob/main/readme/development.md#how-it-works |
https://github.com/sezanzeb/key-mapper/tree/main/keymapper/injection |
I do see three Why is key-mapper-service started by default with |
The third process is possibly the SharedDict from https://github.com/sezanzeb/key-mapper/blob/main/keymapper/injection/macros.py#L53 which is used for macros to set and read variables globally across injection processes |
And the second? First is for injections in internal keyboard. |
One service that listens on DBus and starts injections (the main service process), one SharedDict and one Injection |
How can I disable all the logging? |
debuglogs are not hardcoded anymore since b1b88a0 as for info logs like |
excellent! Thx! The only thing I am still seeing in syslog, is hundreds of
gnome-shell posts this with key-mapper being active and every time injecting a key. It is quite annoying as the syslog gets flooded with every single pressed mapped key. Any idea how to get rid of that? There are already bug reports opened without any solutions though. |
Issue happend today again. After connecting external Logitech mouse and keyboard to notebook external devices wouldn't work. Killed all key-mapper-* instances and external devices started to work again. There is no injection for the external devices, only the internal keyboard, still key-mapper seems to freeze some times. Is there any way to gracefully shut down key-mapper when connecting new input devices and start again? Could though do some udev rule but maybe it's easier to be done by key-mapper itself. |
no, I don't know anything about gnome internals, I don't even use gnome, I'm on xfce4 and X11. Maybe you should actually try if it works better in xfce4, it has generally been much more stable than gnome for me and also has a good reputation for being stable and efficient. It looks ugly out of the box, but can be themed. However, xfce4 doesn't run on wayland, if that should be important to your for any reason. https://xubuntu.org/
unplugging the device that is being injected for and plugging it back in will stop injections for that particular device, does that work for you? |
That's unfortunately not an option.
No, unplugging doesn't help. Key-mapper-* processes seem to freeze. I need to kill them all, then immediately mouse/keyboard start working again, then I restart key-mapper and everything including key injection works again. |
The next time stuff freezes up please run It should output something like:
then select the "key-mapper ... forwarded" device and hit keys that are not mapped. Are events appearing? |
Since you already pointed out
it cannot be that key-mapper is frozen. If that still holds true, then I expect events to pop up in evtest. Which would mean the environment (gnome, etc) freezes, not key-mapper. You can also run |
So, it just now happened. External input devices are frozen. evtest shows events for both the internal keyboard (with keys being injected) and the external one (without any injection).
But still, external keyboard and mouse do not work.
Need to kill the key-mapper-* processes to get external keyboard and mouse working again. |
so key-mapper is not frozen, it writes events into an uinput like it is supposed to do. I don't know why it is required to kill the key-mapper-* processes. What does |
|
Similar issues for me intermittently when using a USB KVM switch and disconnecting/connecting input devices. Log messages when this happens:
Need to test again on 1.3.0. |
Doesn't happen if I remove the udev rule for autoload and manually trigger autoload once a few seconds after connecting the device. |
Does it work though if you added some delay in the udev rule? |
@spi43984 Not sure how to do this correctly, the udev rules are supposed to run quickly. (and it looks like the current issue might be that they're hanging for ages from the log?) Start a shell script which then runs input-remappper-control in the background after a delay, and immediately exits so it doesn't delay udev stuff? |
Instead of modifying the udev rule, you could also try to add a |
is this still an issue? |
I haven't seen any freezes for quite some time now. The only thing I see are the hundreds of warnings flooding my log:
|
I've been using key-mapper 0.8.0 (on Ubuntu 20.04) to remap keys on an internal notebook keyboard (to swap pos1/end to f11/f12 and back) and (XF86Calculater to control_l+xf86calculator) on an external usb Logitech Craft keyboard (which is connected through an usb hub connectd to a Thunderbolt hub).
Most times this setup works smoothly. But recently when connecting the notebook to the Thunderbolt hub both the external usb keyboard and mouse stop working in gnome. Both mouse and keyboard still work in text console (e.g. ctrl-alt-f3) though. After killing all key-mapper* processes mouse and keyboard start working again. Just disconnecting the Thunderbolt connection doesn't solve the issue.
Updated today to key-mapper version 1.0.0 to see if it helps solving the issue.
If issue still persists with version 1.0.0 I was thinking to change udev rules to reload key-mapper completely.
The text was updated successfully, but these errors were encountered: