GNOME Bugzilla – Bug 90996
keyboard repeat rate option breaks input in nasty ways
Last modified: 2004-12-22 21:47:04 UTC
Hi, http://bugs.debian.org/156611 When the GNOME Control Center's Desktop Preferences:Keyboard property sheet's "Keyboard repeats when key is held down" option is turned on, certain keys will repeat in an undesired manner. An example: I have, in Sawfish, "alt-F3" bound to toggling maximized window, and "F3" bound to switching to workspace 3. Whenever I try to hit alt-f3 to maximize a window, I get the following: * Window maximizes * Window promptly unmaximizes * I'm switched to workspace 3 as though the F3 key was hit three times or more. This happens every time. I have experienced similar issues with F9-F12, by themselves, though not as frequently. Likewise with Ctrl-W, which is where the "grave" justification comes from. Turning off the option immediately makes this go away. However, it also will make ALL keyboard repeats go away, even if I try to use kbdrate. This does not occur anywhere else in the system. If I start a new X server without any GNOME 2 near it, this will not occur.
Sounds like you have your repeat rate dialed up too high. Change that rather than turning it off entirely.
It is a joke ? Tell me why I can break my keaboard with the control center ? This should never happens even if an user do a wtrong choice. This was working fine in Gnome 1.4 why this doesn't work in Gnome 2 ?
Its not broken just fast. Some people may like it that fast. Adjust the delay and you'll be fine xset -q will show you the details
xset q ? How ? Are you serious ? How can you tell to an user, "open gnome-terminal an type xset q" to see your setup ? Why I can't see in the control-center all the details provided by xset q ? Please fix this bug.
You can adjust it with control center, indeed you need to adjust it with control center. Using xset to override control center will cause confusion. I was suggesting xset to _see_ the value because that will show a concrete number whereas the control center only has a slider. This is not a bug, but there is nothing we can do about it. You dialed the speed up very high. The system clamps the delay and the rate to sane levels but at the bounds they are ultra fast and ultra slow. That is the nature of bounds. Use the slider in the keyboard capplet to change the delay.
Hi. I'm the one who reported the original Debian bug, in case you're wondering. I'm convinced that this *is* a bug. Really. If the rate is anything less than 1000, this will occur. This does not occur this way in ANY other system I have worked with - sawfish 1.0 by itself, sawfish 1.1 by itself, windowmaker, icewm, GNOME 1.4, GNOME 1.2, the Linux console, et cetera et cetera. It occurs ONLY in GNOME 2.0. And even with the rate at 1000, this will occur occasionally if the system is busy.
There is something odd going on there. Any delay (I assume you mean delay not rate) less than 1000 causes you to send multiple events before you can release ?? 1000 is in milliseconds. You need to have the key depressed for at least 1 second before it will begin to repeat. My standard setting is 500ms 50ms (wait 1/2 a sec before repeating then repeat 20x per second). If you use the keyboard capplet to put both the delay and the rate sliders in the middle of their ranges then run xset -q in a terminal what does it say ? I see Keyboard Control: auto repeat: on key click percent: 0 LED mask: 00000000 auto repeat delay: 500 repeat rate: 50 The default delay is (coincidentally) 500. With a minimum of 50. I just tried to work at 50 and it was indeed uncomfortable, but not impossible. A user could bring up the capplet to slow things down or even type (carefully) for xset. For 2.0.2 I'll bump it to 100 just in case, but there is definitely something else at work here.
Blah, christian can you forward that response to the originator ? They aren't CCed on this
Hrmmmm... When I was getting this I had control-center version 2.0.0, which didn't have a slider - it had a dropdown box with "Very Fast", "Fast", "Medium", "Slow", etc. Or at least the version I had did. Well, in any case, now with control-center 2.0.1, I can't seem to reproduce this bug anymore.
Joanne you are lucky. I can reproduce this bug if the rate or delay value aren't a multiple of ten. Of course this never happens whith xset because user always use multiple of ten. I think you need to check that for 2.0.2
Aren't a multiple of 10 ? I presume this was with 2.0.1 and the sliders not 2.0.0 and the option menu. Does this happen with xset also ? What does xset say about the settings when the keyboard is confused ?
(sorry for taking so long; I'm not always online that often) I've so far gotten the same sudden lack of reproducability even if the rate isn't a multiple of 10. I'm pretty sure of this because I tried seeing if there were differences between entering it in via xset, via gconf-editor, and via the control panel sliders, and in the latter case I never got the numbers exact - I ended up with 659 instead of the intended 660 :) So... I dunno. I kinda sorta stopped using GNOME 2+Sawfish as my primary desktop literally just last weekend, so if it *is* still there but just not showing up for my bug hunts, I don't know it.
With 2.0.1 and the same problem arise with xset. $ xset q Keyboard Control: auto repeat: on key click percent: 0 LED mask: 00000000 auto repeat delay: 266 repeat rate: 38
If xset can screw things then there is a pretty clear indication that this is an X server issue. Just in case this comes up again can you supply your server specs ?
Xfree 4.1.0 ATI 3D Rage Pro But others people had the same problem: See thread called Keys are interpreted several times http://lists.eazel.com/pipermail/sawfish/2002-August/thread.html
That makes it sound like a sawfish issue. I take it this did not happen in terminals too.
I don't believe it to be Sawfish-only only because whenever I would start up Sawfish without the GNOME 2 stuff, this bug could not be reproduced then. At one point I started up two otherwise identical X servers side by side - one with GNOME 2 and Sawfish, one with just Sawfish. The bug was easily reproducable in the GNOME 2-running X server, and not reproducable at all in the Sawfish one. (I still can't reproduce it now, by the way, though I've tried several times.)
Same here. I've never noticed this bug with sawfish 2 and the G1 panel. This only happens since I've installed the G2 panel.
Hi, since about two days I notice severe keyboard repetition problems in Gnome2 (running bleeding edge Debian/x86). This seems to be especially bad with combined keys (e.g. ctrl-PgUp) (but see below for another theory). Easy way to reproduce: start gnome-terminal, resize it to full-screen, open a few tabs (ctrl-shift-t), then scroll through them with ctrl-PgUp/ctrl-PgDn). I never can just jump to the very next tab - I always end 2 or three tabs away. It somehow seems to be related to the "switching speed": the problem goes away if I make the gnome-terminal smaller because the redraw of the next terminal takes less time. Please also remember that this is not a gnome-terminal problem but a general problem (similar e.g. in xemacs21-gnome, does not happen in xemacs21 (without gnome)). I haven't changed my keyboard settings for ages, and the fact that this is redraw speed related makes it virtually impossible to find a "good" setting (i.e. with my gnome-terminal at 1600x1280, I would have to set the delay to more than 1 second, which is of course not acceptable). Regarding the "it's bad with combined keys" theory: it might be that it only appears to be related to combined keys because these are used for "big & slow redraw" ops (i.e. inserting "normal" chars in a gnome-terminal don't trigger this because they don't cause a context switch/redraw event). I'll try to investigate this tomorrow by changing by "prev/next tab" hotkeys in gnome-terminal to "a/b". --nk
I get this with debian/sid occasionally in the gnome-terminal. I'll hit ctl-shift-t for a new tab, gnome-terminal will turn grey for about 3 seconds (strange since I have an althon 2000+), and then I'll have about 8 new tabs. It seems that there is a race condition somewhere. A similar bug is reproduced as such. Hold down ctl-shift-t in the terminal, and let go when it turns grey. on my system, there is no way to let it autorepeat 2 times, or 5 times, or 8 times, I'm getting 30 some tabs. Keyboard Control: auto repeat: on key click percent: 10 LED mask: 00000000 auto repeat delay: 500 repeat rate: 30 xfree86 4.2.0+r200 dri snapshots.
Those xset values look fine. Its unlikely to be a problem with the X server, that looks nice and recent. Lets see of the gnome-terminal folk have seen anything like this.
Hi, please note that this is most likely *not* caused by gnome-terminal but by some underlying common library: I get exactly the same effect when switching workspaces in sawfish using ctrl-left/ctrl-right: I can't just jump to the next workspace (of my 4), but always end on either the leftmost or the rightmost one.
This is a duplicate of bug 86853. Can somebody with the proper bugzilla permissions mark this bug as duplicate?
What code does sawfish share with gnome-terminal ? *** This bug has been marked as a duplicate of 86853 ***
This bug has nothing to do with sawfish. I can't reproduce this bug with sawfish 2 and GNOME 1 BTW this bug isn't related to Xfree, I use Xfree 4.1.0 We have all the same bug. Keys are repeated 3 times in all case.
If it is not X and not control-center there is not much left other than keyhandliung in sawfish or gnome-terminal.
Not in sawfish. as I said before I've never seen this bug with sawfish and the GNOME 1 components. The first time I've seen this bug, is when I've installed the GNOME 2 components. Then this bug is surely somewhere in a GNOME 2 libraries.
By definition the bug is somewhere, saying 'the gnome libraries' does not narrow it down. You have seen it with a gnome2 version of sawfish ? in which case it may be a problem in the port or in some code in gnome2 shared with other apps that have reported this problem. Given that you can replicate it can you work up some backtraces in sawfish of where the events are coming from ?
I need to ask to john Harper for that
My theory, as before, is that it's lurking somewhere in gnome-settings-daemon, or possibly somewhere in the Accessibility settings or somesuch similar. Whether that even makes any sense at all is not something I'm prepared to judge, tho; I do more with XHTML and Perl rather than C and GTK+. :)
The repeat settings use the same mechanism as xset. About the only thing I can think of that would be related to the settings daemon would be that you enabled the ctrl-key locates the mouse option in the mouse capplet. However, that is a stab in the dark.
Am I to understand from the discussion that we've decide it's not a gnome-terminal bug?
I have no idea. Its fairly clear that it is not in the settings daemon, but it is unclear what shared code there is between the terminal and sawfish that would cause this for some X servers.
There is no freaking way this is a gnome-terminal bug. ;-)
I've seen this problem since installing Red Hat Linux 8.0 on this workstation. When load is high, key-combos get sent rapidly. The problem has affected at least sawfish (alt+tab causes windows to swap around, ctrl+shift+left or right jumps through to the last workspace in that direction) and Evolution (Ctrl+d deleted a long sequence of messages). I *think* I also saw single characters repeated in a GTK+2 text editing widget, but don't recall what program I was using at the time. In any case, having seen the problem affect a GTK+-1.2 app while using GNOME2, I'm not above suspecting the X server.
2 months of diagnosis, a thread this long, and no-one added the GNOME2 keyword? /me slaps everybody about a bit with a large trout ;-)
I've submitted this bug to Red Hat, and it's being tracked here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76959 As far as I can tell, it is in no way related to GNOME 2. I can reproduce the same problem with KDE 3. I can even get unwanted key repeats in Emacs under KDE. Jody, regarding comment on 8/18: According to xset man page, "bumping up" the repeat rate to 100 will increate they keys per second, not the delay between repeats. Are you sure that's what you want to do?
You're correct I misspoke. I had been working with the mousekeys repeat rate in the accessx capplet which is implemented differently in X.
The original reporter did say several times that they could only reproduce this under GNOME2. However, Gordon, you say in your RH bug report that you can reproduce under KDE if you change the repeat settings. It would be nice if someone else could confirm this (Joanne?), because if it's not GNOME we can close it. I'm afraid this doesn't actually solve the problem, but if it's an XFree or kernel issue no-one here it going to be able to solve it anyway.
Well, I *do* have it reproducing again under GNOME/Sawfish (it'd briefly gone away, seemingly). Now, alt-F3 doesn't appear to trigger it, but F10 (which I use to pop up a Vim window) Will do it - but only if I've switched desktops beforehand with one of F1-F4 (desktops 1-4), and even then only intermittently. I still haven't tried it with GNOME/Metacity. I'm honestly not sure where I could reproduce it now there - not that it might not be present, but that I don't know any keyboard shortcuts related to Metacity, and this has only happened consistently with windowmanager shortcuts for me. :) This also still doesn't show up for me anywhere else that I've tried. In the next VT over from where I'm reproducing this bug, I have my (now usual) IceWM session running just fine, and I can't get the bug to show up there at all. Getting KDE3 is likely to be an adventure and a half but I'll give it a try and report what I see...
*** Bug 100951 has been marked as a duplicate of this bug. ***
This definitely seems like a bug in XFree86 or the Linux kernel, but I'm not sure which (Mike Harris thinks it's the kernel). Are any users on the CC list using an OS other than Linux? If so, it would be very useful to try and reproduce the problem by running glforestfire full screen on one or more desktops, and then typing into an application (GNOME or not, both would be most useful, I'd think). If anyone can reproduce this on a non-Linux OS, then it'd probably point to a bug in XFree86. In either case, this bug can probably be closed, since I can reproduce the problem here in both kate and emacs.
Gordon: do you mean you have this reproducable in kate and emacs when you are _not_ running GNOME?
Yes, I pointed out on 2002-11-02 that I can reproduce the problem in Emacs under KDE 3.
Closing this bug then, since it seems to be in XFree86 or Linux.