linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Daniel J Blueman <daniel@quora.org>
Cc: linux-input@vger.kernel.org, linux-usb@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: USB keyboard occasional key stuck
Date: Mon, 17 Feb 2014 21:11:51 +0100	[thread overview]
Message-ID: <20140217211151.02f8afbe@neptune.home> (raw)
In-Reply-To: <CAMVG2ss9nA4zcOT3c47EwEMrR7Z_gAQU-HTYGjdWcdYzihSnbg@mail.gmail.com>

On Mon, 17 February 2014 Daniel J Blueman <daniel@quora.org> wrote:
> Across 5+ years of kernels, I've been seeing occasional (1-2 times per
> day) key-stuck issues where eg a fn+delete combo repeats delete until
> I press delete again. I've seen this happen with fn+ctrl+left, leaving
> left held and likewise with right.
> 
> This has occurred on Apple laptops, external USB keyboards and Dell
> laptops, so seems like a linux USB input issue, as I haven't seen
> occur on Windows or MacOS on the same hardware.
> 
> It seems a good move for me to rebuild and run a kernel with some USB
> HID instrumentation to locate this issue over time. Without apriori
> knowledge of the linux USB input stack, what is a good initial
> approach?

I've seen some similar behavior on servers connected to a KVM switch
(USB keyboard/mouse) where without apparent reason the ENTER key became
pressed and did continuously send repeat events.

Physically touching the KVM keyboard or unbinding&rebinding the HID
keyboard solved the issue (on a console that triggers a busy loop of
agettys on active vt).

I've been tempted to attribute it to the KVM switch doing something
when switching to another server via key-press (yes, some co-worker
as at the KVM terminal when the getty load started).

On the other hand, some other co-worker had "dead keyboard" issues
though only under X, things still worked at console level, for quite
some time now. Annoying but not regular enough to look further into it.


If you want to look at what happens for you, monitoring the USB activity
for your keyboard (in combination with output from event device) might
be the most useful way (it would also catch details on when the USB
side goes into power-saving, if at all).

Bruno

  reply	other threads:[~2014-02-17 20:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-17 13:23 USB keyboard occasional key stuck Daniel J Blueman
2014-02-17 20:11 ` Bruno Prémont [this message]
2014-02-18  2:08 ` Clinton Sprain
     [not found]   ` <5302C0B2.9010506-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-18  2:21     ` Peter Stuge
2014-02-18  3:36       ` Daniel J Blueman
2014-02-21  3:44       ` Daniel J Blueman
2014-02-25 13:51 ` Oliver Neukum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140217211151.02f8afbe@neptune.home \
    --to=bonbons@linux-vserver.org \
    --cc=daniel@quora.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).