All of lore.kernel.org
 help / color / mirror / Atom feed
From: "K.R. Foley" <kr@cybsft.com>
To: mr.fred.smoothie@pobox.com
Cc: Ingo Molnar <mingo@elte.hu>, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Date: Fri, 08 Jul 2005 15:35:39 -0500	[thread overview]
Message-ID: <42CEE39B.3050803@cybsft.com> (raw)
In-Reply-To: <161717d505070812385dea6099@mail.gmail.com>

Dave Neuer wrote:
> On 7/8/05, Ingo Molnar <mingo@elte.hu> wrote:
> 
>>* K.R. Foley <kr@cybsft.com> wrote:
>>
>>
>>>Ingo,
>>>
>>>I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when
>>>running the RT patches.
> 
> 
> <snip>
> 
>>>2.6.12 doesn't seem to have the
>>>problem at all, only when running the RT patches. It SEEMS to have
>>>gotten worse lately.
> 
> 
> <snip>
> 
>>>Adjusting the delay in the keyboard repeat seems to help. Any ideas?
>>
>>hm. Would be nice to somehow find a condition that triggers it.
> 
> 
> FWIW, I've had this problem from time to time on my Compaq Presario
> x1010us laptop (which also uses the ICH-4 chipset) with several kernel
> versions between 2.6.7 and 2.6.12, and I have _not_ been running the
> RT patches (though I plan to start soon).
> 
> It seems to only happen when the laptop has been running for a while.
> Also, X has been running each time. When it occurs, the stuck key
> events follow the mouse focus from window to window, and in the few
> cases where I'm able to either switch out of X to a different VT or
> kill X, the keyboard is still "wedged" -- if I recall correctly,
> switching VTs results in no keyboard events reaching that VT (as if X
> is still consuming them). Can't remember what happens when I've
> successfully killed X.

I have seen this happen once or twice, but this behaves more like the 
keyboard really is stuck. The situation I am having is very brief 
repeats of a key rather than just sticking forever. FWIW, when I have 
seen the above situation it behaved just as you described with the stuck 
key following the focus.

> 
> Again, happens uncommonly enough that I haven't put much effort into
> debugging it.
> 
> Anyway, unless it's a similar but unlrelated bug, it's not _caused_ by RT.
> 
> Dave
> 


-- 
    kr

  reply	other threads:[~2005-07-08 20:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-08 18:36 Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems K.R. Foley
2005-07-08 19:13 ` Ingo Molnar
2005-07-08 19:35   ` Doug Maxey
2005-07-08 20:03     ` Ingo Molnar
2005-07-08 20:27     ` K.R. Foley
2005-07-08 19:38   ` Dave Neuer
2005-07-08 20:35     ` K.R. Foley [this message]
2005-07-08 20:20   ` K.R. Foley
2005-07-09 18:31   ` Peter Zijlstra

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=42CEE39B.3050803@cybsft.com \
    --to=kr@cybsft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mr.fred.smoothie@pobox.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.