Sometimes partial unresponsiveness of keyboard

Ubuntu
1

Hi all, :wave:

I´ve been experiencing some weird behaviour keyboard-wise as of late. :slightly_frowning_face:

The keyboard I´m using generally works fine.

xinput --list says it´s a “Lenovo Lenovo Black Silk USB Keyboard”.
Normally it´s very responsive and each keystroke is answered by the respective output.

Yet - sometimes - I notice a keystroke produces no output at all; it seems the keyboard has gone unresponsive.
But just for one hit on (any) key. The next, let´s say, 5 or 6 hits work well again, when possibly the proceeding hit fails. :neutral_face:

So: unresponsiveness isn´t a general pattern; just now and then a keystroke fails.

Hmm, I was wondering what brought that about, especially in view of the fact I´ve been using the keyboard for e.g. one or two hours without fail. And suddenly the partial unresponsiveness occurs. :thinking:

Thinking about it when it last happened I noticed that xscreensaver kicked in as I left the room for about half an hour.
Moving the mouse got the system running as per normal again but it´s exactly then when the phenomenon of the partial unresponsiveness made itself observable.

So I rebooted the system and everything worked fine again.

I´m not completely sure but it seems that the state the system was in (is it suspend?) might be to blame :question:

What I tried to solve the problem without having to reboot was this:

xinput disable 'Lenovo Lenovo Black Silk USB Keyboard' && sleep 10 && xinput enable 'Lenovo Lenovo Black Silk USB Keyboard'

(from: mouse - Is there a way to "restart" the touchpad driver? - Ask Ubuntu )

The command itself worked but it had no effect at all. The partial unresponsiveness remained, so I had to reboot. :frowning_face:

Does anyone know something about that phenomenon?
Any advice is highly appreciated.

Many greetings.
Rosika :slightly_smiling_face:

2

I almost never use any sleep/hibernation on any of my systems, so I have little personal experience with that feature.
However, whenever I saw people speak about this, it seemed to always cause a multitude of different and weird issues. That’s why I would indeed not exclude the possibility at all, that these two things are related. I think, your assessment is correct; both things are likely connected.

That said, I have no really good idea what exactly might be at fault. Usually, people aren’t able to use their mouse or keyboard anymore, after waking up, at all, anymore, which usually means it is related to driver issues. Perhaps that could be the case here, as well. Nevertheless, that’s all I can guess. :woman_shrugging:

I think, to really be able to debug such issue one would need to understand how exactly hibernation/sleep works on a hardware level and on OS (Linux) level. Then, one would need to check these elements on the specific system at hand and compare what changed before letting it go to sleep and after waking it up.
This would be a very reliable way of finding the root cause and perhaps be able to fix it, yet it would be extremely tiresome and I imagine it being very complicated, especially since it’s hard to miss stuff, as well.

Most people swallow this black pill and just do the beginner’s Linux magic trick #1: Reboot.
When talking about sleep and hibernation, people usually just stop using those two and just keep using actual clean shutdown and bootup cycles.

As far as I know, all popular end-consumer operatings systems have occasional trouble with sleep and hibernation modes. Whether it’s Linux, Windows or Mac, all these can cause issues, when using sleep/hibernation, eventually, for some people.

1 Like
3

Hi @Akito, :wave:

how kind of you to reply. Thanks a lot. :hearts:

Neither do I - theoretically. Yet Lubuntu 20.04 came with it enabled by default, and I never changed the settings.
I.e. the screensaver kicks in after 10 minutes of inactivity.

So - provided I´m right in assuming that the phenomenon described has something to do with it - the easiest thing to do would be to disable xscreensaver. :slightly_smiling_face:

Yes I noticed those statements as well during my research on the web.

It´s really weird that in my case the keyboard seems to be just partially unresponsive. :thinking:

Never mind, I thought I might ask around a bit here but - as you said - hibernation/sleep or some such things might very well be the culprit here, so I think I´ll de-activate the screensaver.

I see. Well, that´s good to know :smiley:

Thanks, Akito for the additional info, which is very informative indeed.
I see it´s really not easy to find the root cause of what´s going on and that´s certainly something for the experts (rather than me).

Curious though that I didn´t seem to run into this kind of problem from the beginning.
I´ve been using Lubuntu 20.04 for quite a while now and it seems that I´ve been experiencing the keyboard issue only recently…
… that is to say after one of latest (kernel) upgrades :question:

But that is a mere assumption and I may very well be wrong here… :blush:

Thanks again so much and many greetings.
Rosika :slightly_smiling_face:

4

Logic has great appeal for me. If a keyboard is PARTIALLY disabled, it’s not logical that its signals are affected by anything but its own hardware. I’m pretty sure I’d try a different keyboard before looking elsewhere. My son just rejected a new keyboard that was partially disabled–he got a warranty replacement.

5

@berninghausen:

Hi Bill, :wave:

thanks for your additional comments.

You´re certainly right with what you are saying.
However I might have not found the correct words for describing the phenomenon in question.

The phrase “partially unresponsive” was meant to denote the state of some (or rather any) keys not being responsive.
But: all this at unpredictable intervals. Most times the keys work - sometimes they fail. :slightly_frowning_face:

Never mind; I think I got it sorted out.

What I did was: de-activate the screensaver. And since then I´ve never encountered any sort of unresponsiveness (keyboard-wise) any more. :smiley:

Thanks again for your input.

Many greetings
Rosika :slightly_smiling_face:

1 Like
6

Rosika, I apologize if I fell into the mansplaining trap. There just seemed to be a logical path not being followed. The cause-effect relationship between the screensaver and the keyboard, while clearly the problem, fails the logic test completely.

Cheers
Bill

1 Like
7

A Wifi keyboard will exhibit this erratic behaviour if its wifi communication with the dongle is not strong.
Try moving the keyboard or dongle
Also there seems to be some link between the keyboard function and the cursor position. Sometimes when some activity in a window is finished, the cursor does not drop back to its original window, so no window is active, and the keyboard will not communicate.
Neville

1 Like
8

Hi all, :wave:

@berninghausen:

Dear Bill,

No need to apologize. It didn´t seem like mansplaining to me at all.
In fact I´m very glad and thankful for any input from experts like you. :+1:

And you´re so right in following the logical path.
I´ll always strive to bring in logics to any problem-solving method but in this this case:

I totally agree with you.

Thanks so much again.
Many greetings ffrom Rosika :slightly_smiling_face:

@nevj:

Hi Neville,

I see. Good to know.

I once was in the habit of using a WIFI keyboard but now I employ the
Lenovo Lenovo Black Silk USB Keyboard which came with my PC when I purchased it.
The keyboard is connected via USB cable.

Well, I keep learning something new on a daily basis as it seems. Thanks a lot for letting me know. :+1:
That´s new to me indeed.

I´ll keep that in mind if the phenomenon should ever occur again.

But as I de-activated the screensaver things look pretty good so far.
I´ll keep my fingers crossed. :blush:

Thanks again and many greeting.
Rosika :slightly_smiling_face:

9

Hold on a minute, Rosika. I’m just old. Doesn’t make me an expert!

1 Like
10

Hi Bill, :wave:

You´re too modest, Bill. :blush:

From all of your input in this forum (not just this topic here) I think I may safely state you´re an expert indeed, especially in comparison to my modest Linux knowledge. :+1:

Thanks so much for your continual help. :heart:

Many greetings
Rosika :slightly_smiling_face:

11

After 52 years, my wife has convinced me that I’m not an expert. On the other hand, I’m allowed to cultivate cordial friends and that’s important to me.

2 Likes
12

Hi all once again, :wave:

I was of the opinion my original problem was solved by disabling xscreensaver (see post #5).
That I did last November and until now it seems it has worked.
But - believe it or not - this weird “partial unresponsiveness” of the keyboard kicked in again the other day.
After all that time… :angry:

Hmm, that got me wondering. :thinking:

I was of the opinion that xscreensaver was to blame for that.
So I looked up if any process related to that programme was still running … despite the fact that I disabled xscreensaver in the first place.

And indeed:

ps aux | grep xscreensaver
rosika      1466  0.0  0.1  16568  4876 ?        S    12:21   0:01 /usr/bin/xscreensaver -no-splash

was active. :frowning:

I put forward a respective question about that one to the kind folks at Lubuntu:
https://discourse.lubuntu.me/t/question-regarding-xscreensaver-process/2998 .

and Lubuntu Member guiverc pointed out:

Yes it’s safe to kill the process; however that doesn’t mean it doesn’t have consequences.

If you lock your system (with it killed), you’ll get an error message instead of the intended lock procedure… ie.

An error occurred starting screensaver. Action ‘activate’ failed.
Ensure you have xscreensaver installed and running.

as xscreensaver performs the LOCK function. The initial login/greeter is performed by the DM (display manager) but it doesn’t handle the locked session.

So I´ve learnt something new there. :blush:

I´m not so sure now whether I should or should not kill that process.
Especially in view of the fact that this one might be responsible for the “problem” is nothing but a mere guess.

BUT:

At least I´ve found some kind of workaround to get responsiveness of the keyboard back without having to reboot the system:

The command lsusb -t gave me the opportunity to locate the device:

So for my keyboard [Lenovo Lenovo Black Silk USB Keyboard] it is:
1-1.2.4.1.1

Then - to disable and after that re-enable power to that device - :

echo '1-1.2.4.1.1' | sudo tee /sys/bus/usb/drivers/usb/unbind; and sleep 4; and echo '1-1.2.4.1.1' | sudo tee /sys/bus/usb/drivers/usb/bind

(syntax is for fish-shell; for bash: replace “; and” with “&&”)

This one pointed me in the right direction :smiley: :

I´m still not sure what triggered the “partial unresponsiveness” (xscreensaver or not?) but
the above command got the responsiveness back again without having to reboot. :wink:

I thought I´d share my findings … in case anyone else might find it useful for whatever reason.

Many greetings.
Rosika :slightly_smiling_face:

13

This happens (symptom: bizarre typematic delays when typing in any app, but especially terminal windows) to me sometimes on this piece of crap Lenovo E495 laptop running Ubuntu 20.04… Nearly every time it happens, I take a look at my process tree and there’s a bunch of Resilio Sync processes running and a bunch of ZFS de/encrypt writes happening…

Summary - I attribute this to my stupidity in trying to use ZFS encryption… This laptop is running an AMD Ryzen 5 and 16 GB DDR4 and 1 TB NVMe SSD.

I also - for comparison - have a Dell Latitude E7250, circa 2014/15, with dual core (HT) i7 and 16 GB DDR3 and 512 GB M2 SATA SSD, with my root disk EXT4 encrypted with Ubuntu’s “default” encryption, and it NEVER happens…

Summary - ZFS is not yet mature enough in Linux land to run as my daily driver.

Also - I’ve been using ZFS for 10+ years now, I love it, I run it on my FreeNAS without problem… But it doesn’t cut the mustard for a desktop system, if using encryption…

Note : I’m typing this on the same system right now - it’s not happening… but when I’m ready to wipe this system (I don’t need it all the time) I’ll be going for EXT4 encryption, not ZFS…

1 Like
14

Hi Dan, :wave:

thanks a lot for this additional input of yours.

Kind of a relief I´m not alone with this kind of “experience” :blush: .

But at least you´ve come up with a good explanation for that behaviour.

Good to know. Certainly others can benefit from your findings here. :+1:

That´s a great tip. Thanks. I´ll try to remember that …
Odd that it never occurred to me to do so. :blush:

Many greetings from Rosika :slightly_smiling_face: