Red Hat Bugzilla – Bug 66520
keys auto=repeat randomly
Last modified: 2008-08-01 12:22:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726
Description of problem:
Installed Red-Hat 7.3 on Toshiba Satellite Pro (6100). Keys will
auto-repeat randomly. Can cut off control panel auto=repeat. (eg. key
will not repeat if held down, but keys still repeat randomly while typing
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.open terminal window
2.start typing a string like "the quick brown fox jumped over the lazy dog."
Actual Results: thee quick broown fox jumpeed over the lazy dog
Tried to set rate vie "kbdrate -r 5 -d 1000" but no effect.
I'm seeing similar behavior, though it didn't happen to me under 7.3.
I upgraded to 8.0 and now I get sporadic repetition of keys - not all the time
but every once in a while I type something like "hello" and get
"heeeeeeeeeeeeeeeeeello" back. This just started after the 7.3 -> 8.0 upgrade,
so there are a lot of changes in there (though my 7.3 installation was kept
up2date prior to the switch).
I've seen this problem, too. I'm running Redhat 8.0, upgraded from 7.3.
I see this a lot too, with RedHat 8.0, up2date as of 14-Jan-2003. galeon and
acroread seem to be particular susceptible to it. galeon becomes especially
susceptible to it when it gets really busy. For instance, in a galeon session
with a dozen tabs open and several of them still transfering information, typing
into one of the tabs (with complete info), frequently will result in character
repetition. Or using the arrows or page up/down keys will result in wild,
out-of-control scrolling taking you way beyond where you wanted to go. The wild
scrolling is the usual misbehavior in acroread, too.
I noticed that since RedHat 8.0 the keyrepeat delays and repeat rate can be set
to a much larger degree. This means they are no longer done with the keyboard
controller chip (which is limited to a miminum 250ms delay and 30keys/sec
Does anyone know where/how this new "software keyrepeat" is implemented? Is it
part of the X server?
It's done in software that explains why it hangs sometimes (due to task
scheduling etc). Not sure if there can be a perfect fix (other than a realtime
Anyway, enough educated guesses...
I also see this bug in GNOME. I can hardly type a sentance without experiencing
this bug, however a quick ALT-F1 to get to console mode and I never experience
this. Windows 2000 and XP on the same system don't experience this.
My platform is the same as the original bug reporter, a Toshiba Satelite Pro
Same problem here, mainly experienced in Mozilla but also in other applications.
Whenever I want to create a new tab using Ctrl-T I usually create two or three
tabs, and when I switch to another tab I often jump two tabs at a time. Doesn't
matter how far I increase the keyboard repetition delay, and I never experienced
this before upgrading from 7.3 to 8.0.
Same here, though with some other info that may be helpful (I hope). Using
XFree86-4.3.0-2.1 with nvidia drivers and self-compiled kernel 2.4.21-pre5-ac3.
(I know, non-standard, but in case this report helps.)
I, too, see this most commonly with mozilla. Using alt-n to open a new window
will result in around ten new windows. Typing a URL in the location bar will
often result in repeated characters.
I run fvwm2, not gnome or kde. I have several virtual desktops that I move
between with control-arrow keys, and I've noticed that things usually work fine
when I'm moving to a desktop with few windows on it. When I try to move to the
desktop with mozilla, it almost always moves me several desktops at a time
(sometimes for several seconds, like "desktop roulette"). It may actually be
specific to mozilla, because after some testing, moving to a desktop with lots
of windows seems to work okay, too.
On the other hand, I have seen the problem happen occasionally in xterms not on
my mozilla desktop.
I nominate this as one of the most obnoxious bugs! :)
Some additional info, sigh.... Sorry about the extra post.
Other than the occasional repeated keys, everything with the keyboard seems to
be working as normal. The repeat rate is fine.
I didn't experience this problem until a round of upgrades recently (about two
weeks ago) that included XFree86 and the kernel. I was using Phoebe 8.0.94
XFree86 rpms and non-Red Hat kernels to 2.4.20 quite happily.
More info and a possible fix.... Some time ago, I started renicing my X server
to -10 or so for supposedly better graphics response. Putting it back to zero
has fixed this for me. I guess the X server doesn't appreciate getting such a
high priority for some reason.
Some good news perhaps. I was experiencing this problem on my Toshiba Satellite
Pro 6100 with RedHat 8.0. I have just upgraded to RedHat 9.0 and it doesn't
seem to exhibit this bug.
I also upgraded to RedHat 9 recently. Shortly after that I had to move a lot of
files (perhaps a dozen gigabytes) between two drives, and while I was doing that
keys would sometimes stick for 30 or 40 repetitions until they finally got unstuck.
I had the same problem and the company where I bought the notebook
installed accessX (http://www.rehab.uiuc.edu/accessx/freewareaccessx.html).
ax bouncedelay 5
solved the problem for me.
If you are experiencing the problem reported in this bug report,
please read bug #76959 as it describes a similar problem. I have
just added a patch to XFree86 which may fix that bug report, and
it's possible it may fix this one also.
If you find that it does fix the problem, please reassign this
bug to XFree86, and close as a duplicate of bug #76959. Do the
same with any other similar bug reports you're aware of, if you
can confirm them as well.
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/