Bug 1251384 - Logitech K800 Wireless Keyboard input goes crazy
Logitech K800 Wireless Keyboard input goes crazy
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
23
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-07 03:44 EDT by 3ndymion
Modified: 2016-04-05 08:52 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Fedora 23 KDE 5
Last Closed: 2015-11-23 12:17:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A pic showing the problem in action, as well as a method to see how long it takes. (818.50 KB, image/png)
2015-08-07 03:44 EDT, 3ndymion
no flags Details
Another pic showing the problem in action. (843.02 KB, image/png)
2015-08-07 03:48 EDT, 3ndymion
no flags Details
Output results from evemu-record (33.34 KB, text/plain)
2015-08-15 06:21 EDT, 3ndymion
no flags Details
Another evemu-record capture (15.33 KB, text/plain)
2015-09-16 02:52 EDT, 3ndymion
no flags Details

  None (edit)
Description 3ndymion 2015-08-07 03:44:05 EDT
Created attachment 1060253 [details]
A pic showing the problem in action, as well as a method to see how long it takes.

Description of problem:
After around 5 minutes of not being touched, the keyboard goes into a sleep state.  This is normal operation, & you can see this by looking at the battery widget on the desktop.  The battery symbol for the keyboard will have a red "X" over it.

However, as soon as it goes into sleep mode, the input goes crazy.  It gets stuck in an infinite loop, like if you're holding down some keys non-stop.  This causes programs that have focus to seize, crash, or just not work.  If you keep focus on Konsole when the bug happens, you can see it with your own eyes.  The problem will stop once you press a key to wake the keyboard up, but will happen every time it enters its sleep state.

If anyone else has been experiencing this, here is a way that you can see it for sure.  Open up Konsole (terminal) & type in this command:

date; count=0; while true; do echo -en "\rSeconds passed: ${count}"; count=$(( count + 1 )); sleep 1; done

Press enter & let it sit there.  Once the keyboard goes to sleep, you will see the input going crazy, & how long it took too.  Press Control-C to stop the timer.  I attached a picture of this so you can see.

I realized this problem after Bug 1229016 was fixed.  I do not remember having this problem before that.  It is happening a lot, & is very annoying.  Rebooting usually makes the problem go away, most of the time.

Version-Release number of selected component (if applicable):


How reproducible:
50% chance the bug will be active whenever I turn on the computer.  I actually do not know a way to reproduce it manually.  It happens totally by chance, & is very frustrating.

Steps to Reproduce:
1. Log into OS.
2. Wait for wireless keyboard to go into its sleep state.
3.

Actual results:
Input gets stuck in an infinite loop when the keyboard goes into its sleep state.

Expected results:
Keyboard should go into its sleep state with no problems.

Additional info:
Comment 1 3ndymion 2015-08-07 03:48:10 EDT
Created attachment 1060255 [details]
Another pic showing the problem in action.
Comment 2 Peter Hutterer 2015-08-10 02:54:45 EDT
does this happen on the tty as well, or just in X?

do you see events coming out of the kernel when this happens? run evemu-record against the device file and that should tell you
Comment 3 3ndymion 2015-08-11 07:11:24 EDT
(In reply to Peter Hutterer from comment #2)
> does this happen on the tty as well, or just in X?
> 
> do you see events coming out of the kernel when this happens? run
> evemu-record against the device file and that should tell you

Hi, & thanks for looking at this.  I found that evemu program you mentioned, & now I'll figure out how to use it.  It may take me some time, but I'll do my best to catch this & get some results.  I haven't checked it in the tty yet, but I'll look into that as well next time it appears.
Comment 4 Peter Hutterer 2015-08-12 00:18:42 EDT
http://www.freedesktop.org/wiki/Evemu/ has instructions
Comment 5 3ndymion 2015-08-15 06:17:35 EDT
OK, I've only seen the bug active once in the past couple of days so far.  I managed to get some info, but I'm afraid it doesn't really show much of anything useful.

1st, here is what I did.  I logged in to a tty & got the record command ready.  Then, I switched back over to KDE, or X, & waited to see the input start going crazy in Konsole.  After a few minutes, it started, & I immediately switched over to the tty.  The bug carries over to the tty.  Input was going crazy just the same.  I managed to run the record command to get, what looks to me, like useless info.  I'll attach it here.

As for the bug, I can see that it carries over to the tty once it starts, but I do not know yet if it actually starts in the tty as well.  I did notice that, while the bug is active, pressing keys on the laptop's native keyboard does not stop it at all.  The only way to stop it is by pressing any key on the wireless keyboard, thereby waking it up.  I'll try to find out more next time I see it.  If there's anything more I can do, please let me know what I can do to help.  Thanks.
Comment 6 3ndymion 2015-08-15 06:21:31 EDT
Created attachment 1063250 [details]
Output results from evemu-record

This is the output from evemu-record.  Basically, it just shows the 5 key being pressed repeatedly.
Comment 7 Peter Hutterer 2015-08-18 18:09:16 EDT
what you see here is a kernel key repeat event (value is 2). We discard those in libinput and don't pass it on, but that means the X server only sees the press and then a long pause with no key release. That causes it to generate key repeats in the XKB layer of the server (that's the normal way of generating key repeats).

The underlying problem is that the key is never released which is why the kernel keeps sending the repeat event. so this is definitely a kernel driver issue.
Comment 8 3ndymion 2015-08-21 20:31:27 EDT
Well, that's interesting to know.  Thanks again for looking into this.  I haven't been able to catch the problem active in quite a few days now to try anything else, but I'll report back if I do.
Comment 9 3ndymion 2015-09-16 02:52:53 EDT
Created attachment 1073905 [details]
Another evemu-record capture

After all this time, I finally caught the bug active again.  This time, I switched over to the tty & let it sit there.  After a few minutes, the bug started in the tty.  This is the output from evemu-record in the tty.  I cut out a lot of the lines in the middle since they were all the same.
Comment 10 Justin M. Forbes 2015-10-20 15:30:07 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.
Comment 11 Fedora Kernel Team 2015-11-23 12:17:24 EST
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Comment 12 Danilo Câmara 2016-03-31 13:32:00 EDT
I'm experiencing this problem from some time, maybe from the same time as this bug was reported. It still happens in Fedora 23, Linux 4.4.6-300.fc23.x86_64 (GNOME 3.18.2)
Comment 13 luX0r.reload 2016-04-02 13:07:37 EDT
(In reply to Danilo Câmara from comment #12)
> I'm experiencing this problem from some time, maybe from the same time as
> this bug was reported. It still happens in Fedora 23, Linux
> 4.4.6-300.fc23.x86_64 (GNOME 3.18.2)

I'm experiencing this bug too. Fedora 23 Kernel 4.4.6-300.fc23.x86_64 and GNOME Shell 3.18.4. In terminal and in Sublime Text the 5 key being pressed repeatedly after some minutes with no actions
Comment 14 3ndymion 2016-04-03 04:02:55 EDT
(In reply to Danilo Câmara from comment #12)
> I'm experiencing this problem from some time, maybe from the same time as
> this bug was reported. It still happens in Fedora 23, Linux
> 4.4.6-300.fc23.x86_64 (GNOME 3.18.2)

(In reply to luX0r.reload from comment #13)
> (In reply to Danilo Câmara from comment #12)
> > I'm experiencing this problem from some time, maybe from the same time as
> > this bug was reported. It still happens in Fedora 23, Linux
> > 4.4.6-300.fc23.x86_64 (GNOME 3.18.2)
> 
> I'm experiencing this bug too. Fedora 23 Kernel 4.4.6-300.fc23.x86_64 and
> GNOME Shell 3.18.4. In terminal and in Sublime Text the 5 key being pressed
> repeatedly after some minutes with no actions

Hey guys.  I have still seen this bug active as well, although for me, it is very rare now.  It's very hard for me to catch it, but, it does indeed still exist.  I am on Fedora 23 KDE kernel 4.4.6-300.fc23.x86_64.

Would you guys be able to get some more info with the evemu program described above???  I'm not the one who fixes the bugs, but it would probably be helpful for whoever does.  The more info they can get, the better.  Thanks.
Comment 15 luX0r.reload 2016-04-03 05:17:03 EDT
(In reply to 3ndymion from comment #14)
> (In reply to Danilo Câmara from comment #12)
> > I'm experiencing this problem from some time, maybe from the same time as
> > this bug was reported. It still happens in Fedora 23, Linux
> > 4.4.6-300.fc23.x86_64 (GNOME 3.18.2)
> 
> (In reply to luX0r.reload from comment #13)
> > (In reply to Danilo Câmara from comment #12)
> > > I'm experiencing this problem from some time, maybe from the same time as
> > > this bug was reported. It still happens in Fedora 23, Linux
> > > 4.4.6-300.fc23.x86_64 (GNOME 3.18.2)
> > 
> > I'm experiencing this bug too. Fedora 23 Kernel 4.4.6-300.fc23.x86_64 and
> > GNOME Shell 3.18.4. In terminal and in Sublime Text the 5 key being pressed
> > repeatedly after some minutes with no actions
> 
> Hey guys.  I have still seen this bug active as well, although for me, it is
> very rare now.  It's very hard for me to catch it, but, it does indeed still
> exist.  I am on Fedora 23 KDE kernel 4.4.6-300.fc23.x86_64.
> 
> Would you guys be able to get some more info with the evemu program
> described above???  I'm not the one who fixes the bugs, but it would
> probably be helpful for whoever does.  The more info they can get, the
> better.  Thanks.
Nice! What I can do with evemu program? Launch it terminal and let it running?
To investigate I think can be useful know other wireless input devices are in the system. I've the logitech K800 keyboard and a logitech G700 mouse...
Comment 16 Peter Hutterer 2016-04-04 16:54:00 EDT
benjamin pushed evemu 2.4 out into the repos. that version has autoresume, run it with:

    cd some-dir-for-log-files
    evemu-record --autorestart 10 /dev/input/eventX k800.evemu

this will create a (timestamped) new file after 10s of inactivity. So you can leave it running in the background and once the bug manifests, you wait >10s (typing nothing), cancel evemu and look at the most recent files, those should have all the spurious events.
Comment 17 3ndymion 2016-04-05 07:58:58 EDT
Hi again.  Try playing around with the evemu command 1st so you can get accustomed to it & see how it works.  It gives you a choice of all the different input devices seen on your computer.  Find which one in the list is your Logitech keyboard, & that is the one that you should record.  When it is running, you can see output on the screen every time you press buttons on the input device you chose.  The record option simply copies all of that into a text file of your choice.

I haven't tried the new 2.4 version of evemu, but I can tell you about how I was able to record.  I have the Logitech K800 wireless keyboard & Logitech Anywhere MX wireless mouse, although the mouse doesn't matter.  In my case, the bug would take about 5 minutes of inactivity to appear.  When it does start happening, the bug will stop if you press any key on the wireless keyboard.  So how are you supposed to record then???  Since I work on my laptop, I used the laptop's own keyboard to type.  That way, I can type while the bug is still going.  So if you have a desktop computer, perhaps you can plug in an old wired keyboard & use that at the same time.

Also, I typed the command before I started waiting for the bug to appear.  That way, I can simply press up (to bring up the last command) & Enter real quick to start recording.  Please check the posts above for more details as well.

With the new version, you can probably avoid all that by doing what Mr. Peter Hutterer mentioned.

INTERESTING NOTE:  I think I may have seen this in Windows 7 as well.  It was long ago, & I don't quite remember, but I have a memory of seeing a whole bunch of 6's on the screen after turning off the screen saver.  In Windows, my laptop would many times spike to 100% sometime after the screen saver comes on (after about 5 minutes or more).  I always thought it might be some kind of spyware that wakes up when the screen saver comes on, but it may very well have been this problem all along.

Recently, I've been using Windows 7 a lot again for some music stuff I've been doing, so I'm constantly looking out for this.  If this happens in Windows as well, then it may very well be some kind of Logitech firmware issue.  If I can catch it, then I'll definitely report it here, just to let everyone know.

Does anyone know if this problem occurs with non-Logitech wireless devices???
Comment 18 luX0r.reload 2016-04-05 08:52:28 EDT
(In reply to 3ndymion from comment #17)
> Hi again.  Try playing around with the evemu command 1st so you can get
> accustomed to it & see how it works.  It gives you a choice of all the
> different input devices seen on your computer.  Find which one in the list
> is your Logitech keyboard, & that is the one that you should record.  When
> it is running, you can see output on the screen every time you press buttons
> on the input device you chose.  The record option simply copies all of that
> into a text file of your choice.
> 
> I haven't tried the new 2.4 version of evemu, but I can tell you about how I
> was able to record.  I have the Logitech K800 wireless keyboard & Logitech
> Anywhere MX wireless mouse, although the mouse doesn't matter.  In my case,
> the bug would take about 5 minutes of inactivity to appear.  When it does
> start happening, the bug will stop if you press any key on the wireless
> keyboard.  So how are you supposed to record then???  Since I work on my
> laptop, I used the laptop's own keyboard to type.  That way, I can type
> while the bug is still going.  So if you have a desktop computer, perhaps
> you can plug in an old wired keyboard & use that at the same time.
> 
> Also, I typed the command before I started waiting for the bug to appear. 
> That way, I can simply press up (to bring up the last command) & Enter real
> quick to start recording.  Please check the posts above for more details as
> well.
> 
> With the new version, you can probably avoid all that by doing what Mr.
> Peter Hutterer mentioned.
> 
> INTERESTING NOTE:  I think I may have seen this in Windows 7 as well.  It
> was long ago, & I don't quite remember, but I have a memory of seeing a
> whole bunch of 6's on the screen after turning off the screen saver.  In
> Windows, my laptop would many times spike to 100% sometime after the screen
> saver comes on (after about 5 minutes or more).  I always thought it might
> be some kind of spyware that wakes up when the screen saver comes on, but it
> may very well have been this problem all along.
> 
> Recently, I've been using Windows 7 a lot again for some music stuff I've
> been doing, so I'm constantly looking out for this.  If this happens in
> Windows as well, then it may very well be some kind of Logitech firmware
> issue.  If I can catch it, then I'll definitely report it here, just to let
> everyone know.
> 
> Does anyone know if this problem occurs with non-Logitech wireless devices???

With Windows 7/8 and Elementary OS luna I never see this bug.

Note You need to log in before you can comment on or make changes to this bug.