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
Keyboard/mouse not working after reboot on arch based distros #197
Comments
Are you able to reproduce the problem by running the service manually?
then run Once the problem is reproduced please share the logs. If you want to avoid sharing everything you typed in here, you can remove all lines saying |
The mouse you are trying to map is the "Logitech M585/M590", right? And it seems to be a bluetooth mouse? |
The output of
|
yes, and yes. It don't think it matters tho because it works fine with key-mapper when I use it on ubuntu based distros
It doesn't seem to work. After reboot systemctl status shows disabled but Mouse KB still stop working. (Seems like the problem isn't with key-mapper but something else?) xinput output seems interesting. Mouse disappears from the output when it stops working, reappears when when it starts working again but the keyboard disappears as it stops working (had to use onscreen keyboard to use the terminal) When mouse stops working after reboot:
Note that the keyboard is listed and working at this point in time, but the mouse and touchpad are not. ( After couple of minutes mouse and touchpad start working again, but keyboard stops working and disappears from xinput output:
|
Another thing I noticed is that during installation I get this in between the logs:
After installation completes running
At this point key-mapper along with mouse and keyboard all work fine, until I reboot after which the issue happens. That error seems useful. |
Running
Did a quick google search and fixed it by installing After a reboot mouse, touchpad, touchscreen and pen were not working (key-mapper was disabled in systemctl). Ran the command and got the following:
When the mouse started working and keyboard stopped working, the following lines appeared in the teminal:
Waited for another half hour, nothing else got logged |
I just added
You can verify if it is really stopped by checking Note, that the user interface starts a service process if it is not found running |
After disabling the service and reboot, output of While the mouse remains non fuctional the output of
Once the mouse and other input devices start working and keyboard stops working the output of the same is:
Also this issue seems random. Sometimes after reboot all devices works as expected and nothing goes wrong :/ |
If the command doesn't exit right away it probably means it wasn't running before
This is caused by key-mappers udev rule https://github.com/sezanzeb/key-mapper/blob/clean-history-main/data/key-mapper.rules i.e. something is causing your devices to disconnect and reconnect or something
I just pushed changes to main that avoid this problem when the gui connects to the service, or when it is run via sudo on its own |
So
did I get that right? Are you still having issues if you run |
running
I am not sure what do you mean by that. Autoload is still working. |
probably because of https://github.com/sezanzeb/key-mapper/blob/clean-history-main/data/key-mapper-autoload.desktop, which triggers autoloading on login, I forgot about that one. If you unplug your device and plug it back in, the preset won't be applied though. Having udev rules seemed to be required to make it work with bluetooth devices in at least one case. |
yeah presets aren't applied after replugging the device. I can live with that tho, I dont usually disconnect my mouse. Any clue why is this only happening on arch based distros? I have been using key-mapper on many debian/ubuntu based distros and it has been worked flawlessly on the same system. |
no idea unfortunately. Maybe you could try to compare/upgrade kernel, systemd and libevdev versions |
I'm also on Manjaro KDE, and it displays a bit different symptoms for me. Fairly often after a reboot, sound would be disabled for a couple of minutes (the speaker icon in the task panel is crossed out), then it is enabled by itself displaying the name of the sound card briefly, and at the same moment, an error like this appears in the logs:
Sometimes this doesn't happen and it seems fine. It's completely random. Likewise for the remapped buttons, most of the time they do work regardless of whether this error appears, but sometimes they do stop (either after a reboot, or after this error appears, I think) and I need to open the key-mapper menu and re-apply the preset. For now, I've tried to apply the fix mentioned here with renaming udev rules file to .old, and so far I'm not seeing this error after 3 reboots. |
I just added timeouts to the key-mapper-control calls that are much shorter than the udev timeout. Does that improve anything for you? |
I've reinstalled the AUR package, and likewise, not seeing this error so far after 3 reboots. I'll see how it goes and report back if it happens again. Thanks. |
Well, it seems this has started again, after working for a couple of days without errors. Here's the first one, from yesterday:
And two from today. Strangely the 'spawned process' line referring specifically to key-mapper is not present in the 1st one:
There was no problem with the mapped buttons regardless of these errors, at least today (wasn't able to check yesterday). For now, I will probably try that udev renaming fix again and run it like that for a while, to try and see if there's something else there at play. |
Since it is still timing out the timeout is apparently not happening when communicating with the service, but maybe rather when connecting to it. Apparently I don't know when I'll be able to test and push a change (I'm not at home right now and am super busy), but if you have time maybe you'll find out that using |
I added that edit to daemon.py (in two places as there was one more similar line below). Unfortunately, it didn't help, I'm still getting that error at random. Additionally, I got the following error once after a power loss. The mapped keys didn't work at that time.
|
Thanks for trying! what does In order to debug this we would have to find the place where it hangs until udev times out. I'm not sure how to proceed |
Okay, this error wasn't showing itself for some time, but today's one seemed somewhat 'big' so here's the report. Upon booting at first, the sound icon was crossed out as usual in these cases. At this time there was nothing of interest yet in the journal (
After a couple of minutes, sound came back on, and status of
At the same time, a whole lot of errors appeared in the log:
Afterwards, trying
Mapped keys still did NOT work. At last, I had to open the key-mapper window and apply the preset again. The keys started working again, and key-mapper log became this:
Other than that, I had boots with everything working normally, as well as boots with only the 'worker killed' error messages in the log (no specific references to key-mapper, as stated above). I've found that in the latter case, the mapped keys were working normally as well. |
so if you do that with the udev rule in place, does autoloading work after plugging in the mouse? |
Please install the backage from the AUR again and try to reboot. Debug logs for the udev rule are now written to |
From today (the keys did work in the end):
|
Hey, thanks for trying. It keeps 1000 lines now instead of only 200 and logs if the command finished. Can you please reinstall from the latest source and try to reproduce the problem again? I'll work on avoiding starting the SharedDict if it is not needed |
That was really easy actually, the log output should be cleaner now. There is also a very slim chance that the SharedDict might have caused the trouble because of all the multiprocessing and ipc stuff. |
Device info is now lazy-loaded. This keeps the log shorter and avoids more unnecessary potential for bugs for key-mapper-control. I'm really looking forward to knowing how all of that affects the issue If you still have problems, |
I can still see many errors in /var/log/key-mapper and /var/log/key-mapper-control but everything works as expected now. Autoload works and all input devices are working fine after reboot! |
Nice, can you please post those errors anyway? |
/var/log/key-mapper
/var/log/key-mapper-control |
This is usually happening before a user logged in. udev tells the service about an input device at boot time, but the service doesn't know yet where to look for a configuration. Maybe I can avoid those dbus calls alltogether somehow by checking if any user is logged in first via https://stackoverflow.com/a/14319024/4417769 or something Of course doing that would also avoid the original issue completely, but making key-mapper-control calls more stable and easier to debug didn't hurt as well. I'll push more changes maybe tomorrow |
Pushed final changes. If you still have more problems feel free to comment here, I'll close it for now |
Installed key-mapper-git from AUR. After setting it up and rebooting the mouse doesn't work. It starts working after couple of minutes but then the keyboard stops working. Uninstalling the package fixes the issue.
Both manjaro and endeavouros show this behavior. I am using KDE.
Attaching a journalctl log if that helps...
eos-log-tool.log
The text was updated successfully, but these errors were encountered: