[intrepid] keyboard Repeat Keys is failing to adjust
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
X.Org X server |
Fix Released
|
Medium
|
|||
xserver-xorg-input-evdev (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Welcome. This bug was introduced with the new Xorg in the 8.10 (Intrepid Ibex) release of Ubuntu. It had 2 effects: the default keyboard repeat rate was unusably high, and there was no obvious way to change the repeat rate. There were a few hacks which could effect at least partial fixes, the discussion of which you will find below.
The bug has been fixed upstream, and, in theory, will be included in the 9.10 (Karma Koala) release of Ubuntu. The fix has also been backported to the 9.04 (Jaunty Jackalope) release of Ubuntu. It does not seem like the fix will be backported to 8.10 (Intrepid).
Thus, those affected by this bug should install 9.04.
Q.E.D.
(If there are any continued difficulties, please file a new bug report.)
================== Old bug report ==================
go to System > Preferences > Keyboard > General
The controls under Repeat Keys are failing to properly adjust the timing of how fast keys are repeated when held down.
I filed under gnome, but a person there thinks its an xorg bug in ubuntu: http://
Here is a workaround for this:
Temporarily add the following to your xorg.conf:
Section "ServerFlags"
Option "AutoAddDevices" "off"
EndSection
Restart X, and you will be able to change the settings. Once changed, you can remove those lines from your xorg.conf (which is recommended since setting AutoAddDevices to off can interfere with your keyboard)
Another (and possibly better) workaround is to set the repeat rate manually, see this comment for directions: https:/
This bug may also be related to bug 278078
Related branches
description: | updated |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#1 |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Timo Aaltonen (tjaalton) wrote : | #2 |
Looks like the evdev driver doesn't support it, not yet anyway.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Chow Loong Jin (hyperair) wrote : | #3 |
I found a workaround for this, which is to disable the AutoAddDevices server flag.
In xorg.conf,
Section "ServerFlags"
Option "AutoAddDevices" "off"
EndSection
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #4 |
hyperair's workaround worked for me.
Changed in xserver-xorg-input-evdev: | |
status: | New → Confirmed |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
jbg7474 (jbg7474) wrote : | #5 |
Are there any side effects to this workaround? It sounds like is disabling something that might be useful.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Thiago Teixeira (tvst) wrote : | #6 |
I had the same problem and the workaround also worked for me. But, like jbg7474, I'm also wondering what the "AutoAddDevices" option is disabling.
I'm on a Lenovo Thinkpad T60.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
jbg7474 (jbg7474) wrote : | #7 |
Discovered that "xinput list" is a lot smaller than it was before this workaround. But the only issue I've seen thus far is the loss of the horizontal scroll on my mouse. I think this workaround defeats some of the new hal/fdi stuff in Intrepid (but maybe that's a good thing?).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #8 |
I did some searching. It looks like that option turns off intrepid fancy new fangled keyboard and mouse driver. So, all the problems you would experience would regard either missing or incorrect functionality of your keyboard or mouse.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #9 |
"Me Too" post! I'm going to try the work-around. This is really-
It at least "seems" like this only manifested itself in the RC version. I don't recall it in the Beta or later Alpha versions (if that helps, at all).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #10 |
The "work-around", which admitted does fix the repeating-key problem, also disables any multimedia or related special keys on one's keyboard. So- no unexpectedly repeating keys, but also no volume control, mute, play/pause, or feature keys (like browser/email), which all work without it. Kind of a bad trade-off. It disables all of the "Fn" (Function) keys on my laptop's keyboard as-well.
description: | updated |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
jbg7474 (jbg7474) wrote : Re: [Bug 264196] Re: [intrepid] keyboard Repeat Keys is failing to adjust | #11 |
I should note that if you add this flag, restart X, change your keyboard settings, remove the flag, and restart X again, the keyboard settings are maintained (though you have to add the flag again to adjust them again). So at least you can keep the evdev driver and have proper repeat timing. Just can't change it without the flag.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : Re: [intrepid] keyboard Repeat Keys is failing to adjust, when AutoAddDevices is on | #12 |
thanks for the comments guys. Hopefully the description is accurate at this point.
and also:
/me crosses fingers and hopes that this bug gets some attention
description: | updated |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
hexion (hexium) wrote : | #13 |
Same here. This is really annoying.
In my case that workaround does the trick, but as someone reported lots of my keys won't work.
But here, if I remove those lines the issue will happen again no matter what I trie :(
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #14 |
Per the comments later on- disable AutoAddDevices TEMPORARILY. Adjust the key delay/repeat until it is what is desired, then re-enable AutoAddDevices. It's a PITA if it takes you awhile to tweak your keyboard repeat just-right, but it works. Once you re-enable AutoAddDevices- your multimedia, laptop function, and other special keys should work again (assuming they did to begin with). Also- remember to restart X after each step.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ryan Steele (rgsteele) wrote : | #15 |
I find that before using the workaround, setting the keyboard delay slider all the way to the right *does* increase the delay time, but not by as much as it should.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Nolan (kijiki0) wrote : | #16 |
I have an odd twist on this. For me, it seems like there are two settings.
If I set the delay to minimum, and the speed to max, I get the following behavior:
Immediately repeat is very fast, until the default (unconfigurable) delay time expires, at which point the repeat rate slows down again.
Not sure where the second, unconfigurable delay time and repeat speed settings are coming from.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
John Watson (jwatson) wrote : | #17 |
I noticed the same problem as Nolan. Further, I was able to modify my settings using the System > Preferences > Keyboard GUI until today. I tried changing the repeat rate with kbdrate and then noticed that the settings in the GUI didn't have any effect any more.
I've been tracking down keyboard repeat bugs since Friday. I wonder if this bug might be somehow related? http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
TheQuickBrownFox (theprash) wrote : | #18 |
I've got this problem too. Tried using the disable AutoAddDevices temporarily workaround and this fixed the problem but only until I restarted.
I've also noticed, that the delay slider in Keyboard Preferences does have some effect, but it is very slight. Try comparing the lowest setting with the highest. The highest will have a long delay but it's still way too short. I keep typing liiikkkke thisss when I let my guard down.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Sarath (prosarath) wrote : | #19 |
Quote: "Once changed, you can remove those lines from your xorg.conf (which is recommended since setting AutoAddDevices to off can interfere with your keyboard)"
If i remove the lines and restart X, again the keys ignore the repeat settings.
I found another way of dealing with this. In the same settings Accessibility tab, enable slow keys and set the delay to very less, It will simulate the expected experience
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #20 |
Well, it seems silly (that we have to resort to this)- but Sarath's solution works very well. Just be sure to set the delay all the way to "short".
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #21 |
One small annoyance with using the Accessibility work-around, which at this point is less of a problem for me than the insanely repeating keys I'm otherwise experiencing...
For some reason, enabling "slow keys" is disabling the repeat completely on my "down" and "left" arrow keys. It is a trade-off I'm willing to live with for now, but I hope this bug gets fixed soon.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Sarath (prosarath) wrote : | #22 |
God!
wolfwitch is right. It does take off your clothes on down and left keys. I looked up, it is another bug.
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #23 |
I've actually decided, after doing some coding this morning, that it is a trade-off I'm NOT willing to live with.
It's unfortunate that with all the advances Linux has made over the last couple of years, we now have to deal with a stupid flaky keyboard driver. Will my mouse stop working next?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
TheQuickBrownFox (theprash) wrote : | #24 |
Just confirming that I the Slow Keys workaround does the same thing for me too. With it enabled on the lowest setting typing is perfect but there is no repeat on left and down cursor keys.
I agree, wolfwitch, that it is ridiculous that these bugs exist. I hope that when they are fixed the developers don't consider that alone as some kind of triumph. They should instead examine how it was possible for the bugs to appear and get through to a final release and how that can be avoided in the future. Not to be too harsh, though. Intrepid was an excellent release for me in general but for Ubuntu to compete in the mainstream as it wishes to do it cannot afford for too many glitches of sort to appear and remain unsolved for more than a few weeks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jorge Morais (jorgemorais) wrote : | #25 |
I am also affected by this bug. I have installed Ubuntu 8.10 through the alternate CD, and afterwards installed Xubuntu-desktop. The keyboard repeat delay was too short, and I could not change it with the Xfce GUI, the Gnome GUI or with the xset command. Interestingly, typing xset q does reflect the changes made with either the GUI or with the xset r rate command, but the actual keyboard behavior is *not* affected.
I have yesterday installed Kubuntu 8.10 (through the final release alternate CD) in a friend's computer, and updated it shortly after install. Same problem there.
However, I the command kbdrate *does* work in my computer. After I type sudo kbdrate -r 25 -d 500 in an rxvt, the keyboard starts to behave (have not tested yet if the fix lasts after a reboot)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
TheQuickBrownFox (theprash) wrote : | #26 |
I thought I would give a xset a try but I don't understand the syntax. When I type xset this is how it tells me to use the parameter:
r rate [delay [rate]]
So what are you actually supposed to type to set a delay and a rate?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jorge Morais (jorgemorais) wrote : | #27 |
>I thought I would give a xset a try but I don't understand the syntax.
I think it is clear enough in the man page. The xset manpage has two paragraphs for the "r" option. The second paragraph says
If the server supports the XFree86-Misc extension, or the XKB
extension, then a parameter of ’rate’ is accepted and should be
followed by zero, one or two numeric values. The first specifies
the delay before autorepeat starts and the second specifies
the repeat rate. In the case that the server supports the XKB extension,
the delay is the number of milliseconds before autorepeat starts,
and the rate is the number of repeats per second. If the rate or delay is not given,
it will be set to the default value.
So if you want a reasonable delay of 500ms a a repeat rate of 25 characters per second, you would type
xset r rate 500 25
Typing xset q (which shows the parameters in effect) then reflects the change. I does *not*, however, make an actual difference in keyboard behavior (which is probably due to this very bug).
My workaround for this problem is adding the line
kbdrate -r 25 -d 500
to the file /etc/rc.local
This fixed the problem for me, with no visible side effects so far.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #28 |
Thank you @Jorge Peixoto de Morais Neto!
That is the best work-around so-far. It was getting to be almost impossible to work effectively because of this bug, and now I can. My keyboard acts exactly as I expect it to now, without repeating characters/spaces, and I can use my arrow keys (another bug discussed earlier).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jorge Morais (jorgemorais) wrote : | #29 |
(In reply to the immediately previous comment, https:/
You are welcome. I welcome everyone else to test this workaround, and, if you all like it better than the one involving editing xorg.conf, someone could add it to the topmost (first) post of this bug report, to help people with the same problem who browse this page (assuming it is possible to edit an already-submitted post).
And the importance of this bug should be changed from "undecided" to at least "medium" or the like (I don't know what are the selectable values), as it makes the computer use quite annoying, and I imagine would be a show-stopper for disabled people with poor hand dexterity.
description: | updated |
description: | updated |
description: | updated |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Sarath (prosarath) wrote : | #30 |
Great find! Jorge Peixoto de Morais Neto. I am setting this too. First impression: Awesome. Will post anything abnormal IF found.
Thanks again,
Sarath.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
TheQuickBrownFox (theprash) wrote : | #31 |
Okay, so I've discovered that on my laptop the in-built keyboard and the USB keyboard are behaving differently. Initially they both had the small delay problem. The xset command affects them both in the same way as the keyboard options dialog (i.e. only slightly and with the delay too small). However, the kbdrate command successfully increases the delay on the laptop keyboard but does not affect my USB keyboard.
Furthermore, if I do: "kbdrate -r 2 -d 500" then the laptop keyboard behaves as expected and has a very slow repeat rate. But if I do "kbdrate -r 2 -d 1000" and hold down a key I get a fast repeat for a second or so and then it becomes as slow as it should be. Again, kbdrate does not affect my USB keyboard.
I hope these observations help someone find the root of the problem.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ricardo Pérez López (ricardo) wrote : | #32 |
I'm the author of the bug #278078 post. Reading this current bug description & comments, I can see that both bugreports seems to be closely related.
Unfortunately, I haven't got luck with the upstream developers since I opened the bugreport in freedesktop on 2008-10-06:
https:/
The "xset r rate 500 25" workaround serves as a method to ease the reproduction of the "left, down & end keys" issue.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#33 |
*** Bug 17925 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#34 |
I come from the duplicated bug 17925. My main issue is about the left, down & end keys:
When I press & hold the "down-arrow" key, the "left-arrow" key or the "End"
key, the delay (until the key starts to repeat) is longer than the other keys in the keyboard. I need to hold these keys pressed more time in order to
get repetition.
The issue, however, don't appear when you use the down-arrow key in the keypad
(the "2" key), the left-arrow in the keypad (the "4" key) or the "End" key in
the keypad (the "1" key).
More info is at https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#35 |
(In reply to comment #2)
For me the arrow keys start working like other keys after running "xset r 113; xset r 116; xset r 2".
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ricardo Pérez López (ricardo) wrote : Re: [intrepid] keyboard Repeat Keys is failing to adjust, when AutoAddDevices is on | #36 |
I suggest to open a bugreport in upstream's X.Org freedesktop bug tracker, as I did for the (related) bug #278078.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#37 |
this is only compile-tested, not run-tested at all, but reasonably obvious, so:
http://
(should probably look better than it does, but hey, i got up at 7am today.)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#38 |
This patch indeed makes autorepeat work nicely, but for some reason either due to this patch or due to using the master branch of evdev (patch doesn't apply to 2.0.7 and I'm just about to go to bed so not enough time to test without the patch) ctrl-C seems to either crash or just restart the X server, not sure which, all I can see is that I get to log in again. Will try to investigate tomorrow.
Thank you,
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#39 |
So what happens seems to be that the key presses are sent to both X and console, so when I ctrl-C it interrupts the server and when I alt-F4 it closes a window in X but also switches to the fourth VT. But it looks like it happens even without this patch.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Manni (ubuntu-lxxi) wrote : | #40 |
I cannot offer any workarounds, but I would like to say that my problem is not that my keyboard is now too fast, but that it's way too slow for my taste. Thus the problem is that people are unable to set repeat rate and delay in either direction.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#41 |
ah yes, you need to upgrade your server when using evdev master. glad to hear the repeat issue is fixed though.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#42 |
I too am having the problems described in this bug with xorg-x11-server 1.5.3 as shipped in Fedora 10.
I haven't tried that patch as yet, but I did poke the EVIOCSREP ioctl directly through a small Perl script. It certainly fixes the autorepeat issue for most keys, but it leaves the Left, Down and End keys with no autorepeat whatsoever.
Why would these three keys be handled differently to all the others?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#43 |
(In reply to comment #8)
> I too am having the problems described in this bug with xorg-x11-server 1.5.3
> as shipped in Fedora 10.
>
> I haven't tried that patch as yet, but I did poke the EVIOCSREP ioctl directly
> through a small Perl script. It certainly fixes the autorepeat issue for most
> keys, but it leaves the Left, Down and End keys with no autorepeat whatsoever.
>
> Why would these three keys be handled differently to all the others?
At a guess, your desktop environment is clobbering them, because the keycodes for up/down/left/right as used by evdev are the same as a few special keys (e.g. print screen) in pc105.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#44 |
(In reply to comment #9)
> (In reply to comment #8)
> > I too am having the problems described in this bug with xorg-x11-server 1.5.3
> > as shipped in Fedora 10.
> >
> > I haven't tried that patch as yet, but I did poke the EVIOCSREP ioctl directly
> > through a small Perl script. It certainly fixes the autorepeat issue for most
> > keys, but it leaves the Left, Down and End keys with no autorepeat whatsoever.
> >
> > Why would these three keys be handled differently to all the others?
>
> At a guess, your desktop environment is clobbering them, because the keycodes
> for up/down/left/right as used by evdev are the same as a few special keys
> (e.g. print screen) in pc105.
>
Daniel, I can reproduce the "Left, Down and End keys" issue with my Ubuntu 8.10 whatever the desktop environment I use: GNOME, KDE or Xfce.
See my comment #4 on Launchpad bugreport #278078:
https:/
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#45 |
(In reply to comment #3)
> (In reply to comment #2)
>
> For me the arrow keys start working like other keys after running "xset r 113;
> xset r 116; xset r 2".
>
ricardo@kadath:~$ sudo xset r 113
ricardo@kadath:~$ sudo xset r 116
ricardo@kadath:~$ sudo xset r 2
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 102 (X_ChangeKeyboa
Value in failed request: 0x2
Serial number of failed request: 7
Current serial number in output stream: 9
ricardo@kadath:~$
Do you know why doesn't work with "r 2"?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#46 |
(In reply to comment #3)
> (In reply to comment #2)
>
> For me the arrow keys start working like other keys after running "xset r 113;
> xset r 116; xset r 2".
>
+1! Works for me, too! Thank you very much. Now the Left key works as expected.
Could this fix go inside the X.Org source code in order to get these keys working without the need of the above three xset commands?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#47 |
(In reply to comment #11)
> Do you know why doesn't work with "r 2"?
>
Sorry, it was actually "xset r 22", but it seems that the backspace works fine here now even without it. If you have any other keys that don't autorepeat then just use "xev" to find out the keycode and then "xset r keycode". I have no idea though what causes this issue for those keys.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#48 |
'xset r 113; xset r 115; xset r 116' fixes Left, End and Down respectively for me.
Daniel, you suggested it might be a desktop environment issue. I'm pretty sure this is not the case, since those three keys do not autorepeat if I simply start up X with 'startx /usr/bin/xterm'.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#49 |
ricardo: because the minimum keycode is 8.
michael: hmm, okay, i'll look into it; got half an idea as to what it might be. ta.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #50 |
@Ricardo Pérez López
I'm not going to file upstream till your bug is taken care of. I think your bug is more clearly an xorg bug, where as this bug might be an xorg bug, or, it might be a gnome bug. I don't really know. The gnome people speculated that it was an xorg bug, but given that a workaround is simple a command on the cli, I'm starting to think maybe its a gnome bug, and that the gnome keyboard util just doesn't know how to work with the latest xorg? Again, I really don't know.
Since there are fairly simple workarounds and no data loss, this bug is pretty low priority (according to the bug triaging rules), and any fixes may not make it into intrepid, but will go into jaunty. Thus, I'm content to wait till after your bug is fixed, and I'm also content to wait till the beta, or at least one of the later alphas, of jaunty is released before I try to do anything else in terms of reporting on this bug.
@All
If you think any of the work around directions are unclear, or there are other work arounds, I'm willing to take care of that. I'm willing to edit the original post to have more info/accuracy.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Manni (ubuntu-lxxi) wrote : | #51 |
@daniel: the AutoAddDevices-off workaround cures the keyboard speed problem. But it raises another issue for international users: the keyboard layout isn't correct at the login screen which makes it hard to login if you have a decent password.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ricardo Pérez López (ricardo) wrote : | #52 |
@Manni: about the keyboard layout when AutoAddDevices is OFF:
Try the following:
1. Click on System-
2. Select Layouts tab.
3. Change the "Keyboard model" to "Generic 105-key (Intl) PC".
4. Check that the default selected layout is OK for your country and language.
Tell us is this work.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Manni (ubuntu-lxxi) wrote : | #53 |
1-3: done. Although I'm not able to set a default layout. The radio button in the "Default" column doesn't react when I click it.
4: No. The layout still isn't correct for the login screen.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #54 |
@Manni
How about setting your system to autologin before you set AutoAddDevices to OFF (System > Administration > Login Window > Security ) That way, you will be logged in automatically, and you won't have to worry about special keys?
So, you would turn on autologin and turn off AutoAddDevices, then restart X, get logged in automatically, open System > Preferences > Keyboard, set the repeat rate to how you like it, close that window, remove the lines you added about AutoAddDevices, reset your login to be not automatic, and then again restart x. The repeat rate should stay the way you set it, and all your keys should be working. Does that work?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Manni (ubuntu-lxxi) wrote : | #55 |
@daniel
Removing the AutoAddDevices line after setting my desired keyboard repeat rate doesn't solve it for me. This will only give me a frustratingly slow keyboard. It seems that I have to keep AutoAddDevices and get myself a new password.
PS: I am able to login manually; I just have to press the "wrong" keys ;-)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Joshua Swink (yathster) wrote : | #56 |
For me (using Fluxbox), the solution is to add the following to the keyboard's InputDevice section in xorg.conf:
Option "AutoRepeat" "250 30"
Turning off AutoAddDevices is not necessary with this change.
To summarize some points:
* With or without AutoAddDevices, something is resetting the keyboard delay and rate during X startup. This is not desirable. It is a new development.
* I can override the values by manually adding the "AutoRepeat" setting to xorg.conf.
* When AutoAddDevices is enabled, using "xset r rate..." is ineffective.
* When AutoAddDevices is disabled, using "xset r rate..." does work.
I am not using Gnome or KDE - I use Fluxbox. I suspect that Gnome will reset the keyboard, so turning of "AutoAddDevices" is a sufficient solution for Gnome users. It is not a complete solution for users of Fluxbox.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ricardo Pérez López (ricardo) wrote : | #57 |
I would like to add:
In order to get the Left, Down and End keys repetition work, you can do:
$ xset r 113
$ xset r 115
$ xset r 116
See bug 278078 and https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#58 |
This was fixed in the server with the following commit:
commit bbf811514d3cdf8
Author: Sascha Hlusiak <email address hidden>
AuthorDate: Mon Dec 8 12:24:39 2008 +0100
ddxCtrls.c: XkbDDXUsesSoftR
And you need the matching evdev commit:
commit ece72ce9e97adae
Author: Sascha Hlusiak <email address hidden>
AuthorDate: Mon Dec 8 12:27:34 2008 +0100
Filter all repeated keys from kernel, because we do softrepeat in server
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#59 |
(In reply to comment #16)
> This was fixed in the server with the following commit:
>
> commit bbf811514d3cdf8
> Author: Sascha Hlusiak <email address hidden>
> AuthorDate: Mon Dec 8 12:24:39 2008 +0100
>
> ddxCtrls.c: XkbDDXUsesSoftR
>
> And you need the matching evdev commit:
> commit ece72ce9e97adae
> Author: Sascha Hlusiak <email address hidden>
> AuthorDate: Mon Dec 8 12:27:34 2008 +0100
>
> Filter all repeated keys from kernel, because we do softrepeat in server
>
Can anybody test this fix? What about the Left, Right and End keys issue?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
jbg7474 (jbg7474) wrote : | #60 |
I would also like to mention that even though the workaround works for me, when I hot dock my Dell D620, the keyboard rate gets reset to the previous default (slow repeat for me). Rebooting fixes it, but who wants to reboot to fix a keyboard repeat? Hot docking resets the repeat rate even though I do not have a keyboard plugged into my dock (only a USB mouse).
With regard to importance, which I see is still undecided, I'd like to say that this bug is very visible to users who have it. And it's aggravating because it SHOULD just work--doubly so since it worked in Hardy. It's like a stone in your shoe--yeah, it's not going to really do any damage, but you still stop walking and remove it right away because it is annoying. So I recommend an importance that will get this bug fixed relatively quickly.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#61 |
The fix does NOT resolve the Left, Down and End keys issue, as an user reported here:
https:/
He said that he need to use xset in order to get repetition with these keys. It's a workaround, but it's NOT a full fix.
I propose to reopen the bug #17925, because there's obviously not the same problem.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
mannheim (kronheim) wrote : | #62 |
This bug was (for me) fixed upstream at https:/
I applied the patch from
to the intrepid version of xserver-
I would also like to comment that neither the "xset" nor the "kbdrate" workarounds had any effect on the repeat rate on my system (a USB keyboard). I think (as others have said) that this bug should have a reasonably high priority: the inability to adjust the keyboard is a serious issue, and the workarounds only work in some cases.
(As a side issue: applying this patch to xserver-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Peter Estes (pmestes) wrote : | #63 |
Thank you for the work around, Jorge. My brother showed me how to edit the file to add your fix. My keyboard has been working flawlessly ever since.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
DickeyWang (hwang313000) wrote : | #64 |
Shouldn't this bug be marked as critical? For those who types hours a day, the repeat rate/speed is directly related to productivity, isn't it?
I've just upgraded to Intrepid for two days and I am seriously considering moving back to Hardy just because of this keyboard repeat rate issue.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #65 |
hey guys,
I believe the importance attribute is for developers who are using launchpad, not for the users. I don't think this is going to get a higher priority because this isn't an ubuntu specific bug, and possibly, Mark Shuttleworth hasn't hired any developers to focus on the xserver.
I think the best way to raise the priority of this bug would be to file it upstream at freedesktop.org.
Personally, I don't want to do that, since I don't really know much about xorg, debugging and gathering information. Frankly, I know very little in the manner of applying or testing out patches.
At the end of February, I'll probably give jaunty a whirl, see if there is any improvements.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rocko (rockorequin) wrote : | #66 |
This seems to be a problem in Jaunty too.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
George Fragos (fragos) wrote : | #67 |
I've developed more insite into this problem that may be helpful. kbdrate works but only after X is started.
The keyboard delay is much to short for me yielding frequent repeated characters. I set the keyboard rate in the Conficuration Editor to an extremely long delay which doesn't seem effective. When reseting delay and rate to 1200 and 15 in the Configuration Editor the result as indicated by kbdrate is 250ms 10.9cps which is the same as at boot.
Next I edited /etc/init.
#!/bin/sh -e
kbdrate -r 15 -d 1200
exit 0
After boot kbdrate shows:
Typematic Rate set to 10.9 cps (delay = 250 ms)
While running the rate is set properly with:
sudo kbdrate -r 15 -d 1200
Typematic Rate set to 15.0 cps (delay = 1000 ms)
The only thing that seems to work is settting kbdrate from the desktop.
Changed in xorg-server: | |
status: | Unknown → Fix Released |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #68 |
I don't know why this was set to bug #17500, an old bug. #17925 makes more sense.
Anyway, I'm testing on jaunty, and the bug persists. I'm curious, is this happening to anyone that has a simple keyboard, without special keys? I know that my usb keyboard shows up as two keyboards under lsusb. I'm not sure where laptop keyboards show up. But, I'm thinking that since these keyboards show up as two at the kernel level, maybe thats confusing Xorg somehow.
Is there anyone here using a simple keyboard that also has this issue? thus proving my theory wrong?
Changed in xorg-server: | |
status: | Fix Released → Unknown |
Changed in xorg-server: | |
status: | Unknown → Confirmed |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Hongli Lai (honglilai) wrote : | #69 |
I confirm that this bug occurs on Ubuntu 8.10 on a Dell Inspiron 6400 laptop. It has not yet been fixed in Jaunty alpha 5.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Thane (byd) wrote : | #70 |
The following worked flawlessly for me with a few speed adjustment tries. From Terminal, sudo vim /etc/rc.local (to edit the rc.local file). Added the following line before the "exit" line: kbdrate -r 12 -d 500
The 12 figure lets me read about 3 lines continuously scrolling out of about every 20 in a daily newsletter and keep up with the scroll. If you need the scroll a bit slower, try 10 instead of 12 and conversely try 14 if you need it a bit faster for your purposes.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
George Fragos (fragos) wrote : Re: [Bug 264196] Re: [intrepid] keyboard Repeat Keys is failing to adjust | #71 |
On my system setting the delay in rc.local has no effect. It only seems to
work from the desktop.
Have a nice day -- George
____________
George Fragos
<email address hidden>
http://
73 East Swift Ave.
Fresno CA 93704
On Sun, Mar 1, 2009 at 8:46 AM, Thane <email address hidden> wrote:
> The following worked flawlessly for me with a few speed adjustment tries.
> >From Terminal, sudo vim /etc/rc.local (to edit the rc.local file).
> Added the following line before the "exit" line: kbdrate -r 12 -d 500
> The 12 figure lets me read about 3 lines continuously scrolling out of
> about every 20 in a daily newsletter and keep up with the scroll. If you
> need the scroll a bit slower, try 10 instead of 12 and conversely try 14 if
> you need it a bit faster for your purposes.
>
> --
> [intrepid] keyboard Repeat Keys is failing to adjust
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Thane (byd) wrote : | #72 |
Seems odd George... Worked fine on my system. Here's my entire /etc/rc.local file
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
#The following line is for adjusting keybd repeat rate
kbdrate -r 12 -d 500
exit 0
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Reuben Thomas (rrt) wrote : | #73 |
I notice that the part of the fix for this bug in the X server has now made it into Jaunty (xserver-xorg-core 1.6.0) but the part that needs to go into evdev has not, because it's been applied to the evdev 2.2 branch, and Jaunty currently has 2.1.1.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Toby (tobygrunt) wrote : | #74 |
Reporting an additional element to repeat key/slow key bug...
On Intrepid Desktop with Multimedia keyboard.
Cursor very slow. Increase repeat key speed only helped for first inch of movement. Enabling and adjusting slow keys solved that problem, but then I couldn't scroll backwards, or enter text into boxes (e.g. mail password, etc.). Everytime I clicked the keyboard the coloured title bar flashed.
Here's what happened with the fixes:
- I have admin account and a limited permissions user account.
- Applied the fixes as admin, keyboard works again.
- Changed to user account - problem still evident.
- I changed user permissions to admin and re-applied fixes - no effect.
- I created a new limited permissions user account, and the keyboard works fine. I'm now transferring
everything to the new user account.
(I'm very grateful for the fixes. I had to apply both to get the number pad/movement keys working. I do have a mm keyboard, but am not bothered about the mm bits.)
Addendum: re importance of this bug - I find it a plague, I'm afraid. I'm a writer and constantly scroll around documents.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #75 |
Jorge,
Thanks for this workaround. The repeating key problem is driving me crazy!
Can you tell me one thing? I am a Linux newbie. I'm running Mint 6.0, which is based on Ubuntu 8.10. I see that i can edit the file /etc/rc.local with gedit, but I am afraid of screwing up my system if I don't do it exactly right. Can you tell me exactly where in rc.local to put the line:
kbdrate -r 25 -d 500
?
does it go at the end, or before the "exit 0" or where? You said that you just added the line to the file, but that is too vague for me to be able to implement your workaround.
Thanks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #76 |
uh-oh. reading all the posts, I just read that editing /etc/rc.local will fix the internal laptop keyboard but not an attached USB keyboard, which is what I mostly use! :(
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
George Fragos (fragos) wrote : | #77 |
Setting kbdrate in rc.local doesn't work with an external keyboard. The only
fix I've found is to run kbdrate after the Ubuntu GUI has fully started.
Have a nice day -- George
____________
George Fragos
<email address hidden>
http://
73 East Swift Ave.
Fresno CA 93704
On Mon, Mar 16, 2009 at 9:40 AM, Gumby <email address hidden> wrote:
> uh-oh. reading all the posts, I just read that editing /etc/rc.local
> will fix the internal laptop keyboard but not an attached USB keyboard,
> which is what I mostly use! :(
>
> --
> [intrepid] keyboard Repeat Keys is failing to adjust
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #78 |
George,
You mean issue a command every time you start the OS? Caan you tell me specificallyy what i need to do? I am a Linux newbie. I assume you mean use the Terminal. Can you tell me exactly what to type in the terminal?
As far as i'm concerned, this bug is very critical. It is so bad I've had to correct several involuntary character repeats in this single post. Iiiiiit makes me not want to use the OS, frankly. But I will if I caan fix this.
It really makes Linux look Not Ready For Prime Time, if you know what I mean. I'm amazed more people don't complain. Maybe they are just watching movies on theirr PCs, not typinggggg.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
George Fragos (fragos) wrote : | #79 |
Open a terminal window and type "sudo kbdrate -r 15 -d 1000". You'll be
asked for a password, enter your user password. This will yield a delay of 1
sec and repeat at 15 cps. You can choose different values if you wish --
these worked for me. To simplify the entry I created the following two line
shell script and placed it in /usr/local/
"kbfix."
#!/bin/bash
sudo kbdrate -r 15 -d 1000
Have a nice day -- George
____________
George Fragos
<email address hidden>
http://
73 East Swift Ave.
Fresno CA 93704
On Mon, Mar 16, 2009 at 11:20 AM, Gumby <email address hidden> wrote:
> George,
>
> You mean issue a command every time you start the OS? Caan you tell me
> specificallyy what i need to do? I am a Linux newbie. I assume you mean
> use the Terminal. Can you tell me exactly what to type in the terminal?
>
> As far as i'm concerned, this bug is very critical. It is so bad I've
> had to correct several involuntary character repeats in this single
> post. Iiiiiit makes me not want to use the OS, frankly. But I will if I
> caan fix this.
>
> It really makes Linux look Not Ready For Prime Time, if you know what I
> mean. I'm amazed more people don't complain. Maybe they are just
> watching movies on theirr PCs, not typinggggg.
>
> --
> [intrepid] keyboard Repeat Keys is failing to adjust
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #80 |
As best I can tell, this "kbdrate" command DOES NOT WORK AT ALL on my system (Intrepid, 2.6.27-11-generic).
I have a Microsoft Digital Media Pro keyboard (configured in Keyboard Preferences as a "Generic 105-key (Intl) PC" model), which I've tried connecting to my desktop both via its native USB connector and via a purple adapter to the PS/2 keyboard jack. I've tried "kbdrate -r 4 -d 750", both in /etc/rc.local and in a terminal window, but I still get a much faster keyboard autorepeat no matter what I do.
The xorg.conf workaround also DOES NOT WORK AT ALL for me.
I am most definitely not a novice, but I fully agree with "Gumby" that this is a critical bug for novices. Even if one of the workarounds we've been discussing did happen to work, it is not acceptable to expect a newbie to type a command in a terminal window (much less edit a configuration file) even ONCE -- to say nothing of doing it every time they restart or log in.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
George Fragos (fragos) wrote : | #81 |
Unfortunately this command can't be used to display the current values.
Without parameters it sets the delay to .25 sec. I only know that if I use
kbdrate as over it sets a long enough delay for the entire session.
Have a nice day -- George
____________
George Fragos
<email address hidden>
http://
73 East Swift Ave.
Fresno CA 93704
On Mon, Mar 16, 2009 at 6:41 PM, Rich Wales <email address hidden> wrote:
> As best I can tell, this "kbdrate" command DOES NOT WORK AT ALL on my
> system (Intrepid, 2.6.27-11-generic).
>
> I have a Microsoft Digital Media Pro keyboard (configured in Keyboard
> Preferences as a "Generic 105-key (Intl) PC" model), which I've tried
> connecting to my desktop both via its native USB connector and via a
> purple adapter to the PS/2 keyboard jack. I've tried "kbdrate -r 4 -d
> 750", both in /etc/rc.local and in a terminal window, but I still get a
> much faster keyboard autorepeat no matter what I do.
>
> The xorg.conf workaround also DOES NOT WORK AT ALL for me.
>
> I am most definitely not a novice, but I fully agree with "Gumby" that
> this is a critical bug for novices. Even if one of the workarounds
> we've been discussing did happen to work, it is not acceptable to expect
> a newbie to type a command in a terminal window (much less edit a
> configuration file) even ONCE -- to say nothing of doing it every time
> they restart or log in.
>
> --
> [intrepid] keyboard Repeat Keys is failing to adjust
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #82 |
I wasn't talking about trying to use the command to display current values. When I said "this 'kbdrate' command", I was referring generically to the command (with an appropriate, but unspecified argument list). And I'm not sure why "kbdrate -r 4 -d 750" works for you, because (as I said) it's not working for me.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
George Fragos (fragos) wrote : | #83 |
I can't say why it works for me and not you -- it does work for me. kbdrate
is picky about arguments. Try "man kbdrate." I've no more insight on this
issue.
Have a nice day -- George
____________
George Fragos
<email address hidden>
http://
73 East Swift Ave.
Fresno CA 93704
On Mon, Mar 16, 2009 at 7:30 PM, Rich Wales <email address hidden> wrote:
> I wasn't talking about trying to use the command to display current
> values. When I said "this 'kbdrate' command", I was referring
> generically to the command (with an appropriate, but unspecified
> argument list). And I'm not sure why "kbdrate -r 4 -d 750" works for
> you, because (as I said) it's not working for me.
>
> --
> [intrepid] keyboard Repeat Keys is failing to adjust
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #84 |
And for reasons I can't explain, when I tried "kbdrate -r 4 -d 750" again just now, it WORKED.
No idea why it worked this time, but not earlier.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #85 |
George, I entered your code in the terminal (with a change in the delay rate more to my tastes) and got this output:
sudo kbdrate -r 15 -d 750
[sudo] password for gumby:
Typematic Rate set to 15.0 cps (delay = 750 ms)
And I can report that the internal keyboard in my laptop now responds correctly, but the external USB keyboard I use most of the time does not. It still displays the old repeating key behavior.
Is there any workaround that works for a USB keyboard attached to a laptop?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #86 |
And everyone should note that this issue also applies to desktops, since most keyboards nowadays use USB (and may or may not come with one of those purple USB-to-PS/2 keyboard adapters). Once I read here that the problem was specifically affecting USB keyboards, I knew enough to try using the PS/2 jack (and I happened to have one of those old adapters lying around!) -- but we cannot expect the average, inexperienced user to have either the knowhow or the wherewithal to do this.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #87 |
The workaround posted near the top of this bug, submitted by Jorge Peixoto de Morais Neto, seems to be the best fix for this for now. It works on my laptops and home desktop when using any keyboard...
Just add:
kbdrate -r 25 -d 500
...to /etc/rc.local
I just put it right above "exit 0" at the bottom of the file.
Frankly, I can't believe this hasn't been fixed yet.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #88 |
Rich,
I should also point out that my new laptop, (like most of the ones i looked at when i was shopping around), doesn't even HAVE a PS/2 port!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #89 |
wolfwitch,
Okay, I edited rc.local, saved the change, and my USB keyboard still has the same problem. Do you have to restart maybe?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #90 |
Gumby, the builtin keyboard on a laptop is hooked up (internally) to the computer the same way as an external PS/2-style keyboard would be. This explains why the workaround (with a "kbdrate" command) fixes your laptop's internal keyboard.
Wolfwitch, when you say that the "kbdrate" workaround works for you "when using any keyboard", are you trying this with both PS/2 and USB keyboards? If this workaround fixes a USB keyboard, I think that's news.
And I'm having a hard time, too, accepting that this bug is too hard to fix quickly.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
wolfwitch (wolf-mylunarden) wrote : | #91 |
@Gumby- Yes, you would need to restart. The file rc.local runs when your computer boots up (just before Gnome loads). The one "problem" with this fix is it briefly displays the terminal screen just before gdm loads, which isn't nice visually, but it at least makes the computer usable.
@Rich Wales- Sorry, yes- I mean USB keyboards. I can't even remember the last time I used a PS/2 one. I had the key repeat problem on a total of four machines- 3 laptops and 1 desktop (mix of home and work) with USB keyboards. This fixed the problem on all of them.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #92 |
I can confirm that wolfwitch is correct. This morning, after restart, my USB keyboard is working properly. :o)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Glauco (glauco-hass) wrote : | #93 |
I confirm both, the bug and the fix with kbdrate in rc.local, tested in my laptop and desktop, this one with a usb keyboard.
Intrepid with latest updates.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
George Fragos (fragos) wrote : | #94 |
kbdrate works with my USB keyboard adapted to PS/2 but not when placed in
rc.local.
Have a nice day -- George
____________
George Fragos
<email address hidden>
http://
73 East Swift Ave.
Fresno CA 93704
On Wed, Mar 18, 2009 at 4:31 PM, Glauco <email address hidden> wrote:
> I confirm both, the bug and the fix with kbdrate in rc.local, tested in my
> laptop and desktop, this one with a usb keyboard.
> Intrepid with latest updates.
>
> --
> [intrepid] keyboard Repeat Keys is failing to adjust
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jeffrey Knockel (jeff250) wrote : | #95 |
Hi, I've put a patched version of xserver-
https:/
It seems to have fixed the problem for me. If this works for others, and there are no side effects, perhaps we could coerce an Ubuntu dev to include the patch in the jaunty release.
Note that if you want to test it, first undo any previous workaround that you may have use before, and then reboot to make sure that the problem comes back. Then install the new package (version 2.1.1-1ubuntu4~
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #96 |
that package fixes it for me. I'm able to change my repeat rates! Yay! Thanks Jeff250.
Anyway, I'm the original bug reporter, and I consider this proof positive that this bug is resolved upstream, and we may be able to get it resolved downstream. ( I kinda wish I knew the details of patching and packaging. Wish I could have done this myself.)
Anyway, here's how I see it. Im the original bug reporter. Im gona open a new bug dedicated to this fix, and getting it backported to jaunty.
If this fix does not work for you, please say so, and open a new bug. Otherwise, if everything goes well, I will close out this bug.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #97 |
I filed the request for inclusion in jaunty here: https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ricardo Pérez López (ricardo) wrote : | #98 |
@danielhollocher:
Can you test if the key repeat delay of the Left, Down and End keys works well?
(As was reported on bug #278078.)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #99 |
Ricardo:
I've never had that problem. Sorry.
Changed in xorg-server: | |
status: | Confirmed → Unknown |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #100 |
Actually, I do have that problem on intrepid. I never tested on jaunty. Testing now on jaunty with the evdev from the archive, I don't have the problem. I will downgrade, and see if I did have that problem on jaunty.
Changed in xorg-server: | |
status: | Unknown → Fix Released |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #101 |
Jeff, will your patch work on intrepid? I would really like a fix to this problem ASAP, but I depend on my machine being stable and really can't upgrade to jaunty while it's still pre-release.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jeffrey Knockel (jeff250) wrote : | #102 |
It seems to work just as well in intrepid. I've now uploaded intrepid packages to the ppa. Just make sure you use intrepid on the deb/deb-src lines, not jaunty.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #103 |
Thanks. I installed the patch in intrepid just now. It seems to work fine, EXCEPT that the "left" and "down" arrow keys do not repeat AT ALL (no matter how long I hold them down).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jeffrey Knockel (jeff250) wrote : | #104 |
I just tested that, and I can confirm the same regression on intrepid. Since you, Daniel Hollocher, and I can confirm the left/down arrow regression on intrepid when we use the patched evdev packages, we should probably let go of intrepid and focus on jaunty, since both Daniel and I cannot reproduce this regression on jaunty when using the patched evdev packages.
I believe that the left/down regression was fixed somewhere in between intrepid and jaunty's xserver, since, when I cherry-picked the latest jaunty xserver packages onto my intrepid box, the regression was not present, even when using my patched evdev package. (Note that cherry picking packages, in general, is a risky idea in terms of overall stability, and I've since reverted the xserver packages on my intrepid box to the intrepid versions, but doing it can be useful for experiments like this.)
I will leave the intrepid evdev packages in my ppa anyways, in case someone wants to still play around with them, but I don't advise using them, and it's too late for any fix like this to appear in intrepid anyways, whereas at least the chance for this fix to appear in jaunty is nonzero. And since jaunty thus far has *not* been shown to be affected by the left/down arrow regression, this is why we still need more testers for the ppa package in jaunty.
As an aside, I also tested evdev-2.2.0 (a much newer version of the evdev in jaunty) on my jaunty box. I won't put it in my ppa, but it automatically reflects the patch for the repeat bug that I used to patch the package in my ppa archive. Like we would expect, I also tested it to solve repeat bug. So, if we cannot patch jaunty's evdev package to include the fix, the good news is that the first ubuntu version (likely jaunty+1) to use evdev-2.2.0 or greater will get this fix for free.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #105 |
OK, understood. Could you remind me (and others) how to safely uninstall your patched package and revert to the regular version of same?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jeffrey Knockel (jeff250) wrote : | #106 |
Yes, here's the GUI instructions:
Select the package in synaptic
In menu, go to Package -> Force version...
Then select the version you want to downgrade to.
Apply this downgrade, restart X or your computer, and you should be back to using intrepid's version.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Reuben Thomas (rrt) wrote : | #107 |
Would it be possible to keep further discussion to the forums? This bug report is already unhelpfully long, and it's hard to extract the useful information, namely: what is the bug? where is it present? when is it likely to be fixed? how can I work around it? All of these questions are now answered, but some of the remarks about evdev and the arrow keys in the preceding few comments show that at least some users have not managed to find at least some of this information. Example: an announcement of a patched evdev package is useful; discussion of how to install and uninstall it do not belong here.
Having said that, maybe the Ubuntu devs could take note: long threads such as this one in the BTS often reflect bugs that are inconveniencing many users, and quite how they imagine that having unconfigurable keyboard autorepeat two releases in a row[1] is anything approaching acceptable, I do not understand.
[1]Hacks and workarounds don't count. I am talking about the standard configuration mechanism that is all that 99% of users will ever try.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Jeffrey Knockel (jeff250) wrote : | #108 |
The bug for inclusion of the patch into jaunty is bug 345397. It also has summarized mostly what you're looking for, including steps to reproduce, a theory of the problem, and a patch that you can test. Future discussion of one's experience with the jaunty patch should go there.
Other discussion, including how to install the jaunty patch, and so on can go here:
http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Steve Grace (sgrace) wrote : | #109 |
I had this issue as well with a USB keyboard. It drove me nuts until I found out it was a bug; this really should have a higher priority than it's been given.
The kbdrate fix didn't work for me. The xorg.conf fix worked but only if I kept the changes in; I couldn't enable them temporarily and then disable them as some posters could.
I opted for enabling Slow Keys (per Sarath in message #18) plus running a startup script containing the three xset commands (listed by Ricardo Perez Lopez in message #41).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ricardo Pérez López (ricardo) wrote : | #110 |
FYI: I've workaround this bug upgrading to Jaunty. Jaunty seems to resolve it, or, at least, I haven't the Left, Down and End keys issue, and all seems OK.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Toby (tobygrunt) wrote : | #111 |
Two Outstanding Issues ?
1) Did anyone else have the problem that the fixes did not work for a non-admin account? (even when permissions temporarily changed to admin to apply the fixes). The only solution was to create a new user account, for which the fixes already applied worked fine. (i.e. they were in place as soon as the account was created)
2) The problem occurred on a desktop with a wireless multimedia keyboard with PS/2 connector (earlier posts suggested it only affected USB keyboards and PS/2 would fix).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Launchpad Janitor (janitor) wrote : | #112 |
This bug was fixed in the package xserver-
---------------
xserver-
[Bryce Harrington]
* rules: Adding 'patch' to the build task appears to be unnecessary.
[Jeffrey Knockel]
* Add 102_filter_
repeat rate. (LP: #345397, LP: #264196)
-- Bryce Harrington <email address hidden> Fri, 03 Apr 2009 17:45:01 -0700
Changed in xserver-xorg-input-evdev (Ubuntu): | |
status: | Confirmed → Fix Released |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #113 |
The bug is back. The edit in rc.local fixed it for 2-1/2 weeks, but
today the old fast-repeat misbehavior has returned on my USB keyboard,
but not on the laptop's built-in keyboard.
I checked rc.local and my fix is still there, has not disappeared.
I am using Mint 6.0
On 4/4/09, Launchpad Bug Tracker <email address hidden> wrote:
> This bug was fixed in the package xserver-
> 1:2.1.1-1ubuntu4
>
> ---------------
> xserver-
>
> [Bryce Harrington]
> * rules: Adding 'patch' to the build task appears to be unnecessary.
>
> [Jeffrey Knockel]
> * Add 102_filter_
> repeat rate. (LP: #345397, LP: #264196)
>
> -- Bryce Harrington <email address hidden> Fri, 03 Apr 2009 17:45:01
> -0700
>
> ** Changed in: xserver-
> Status: Confirmed => Fix Released
>
> --
> [intrepid] keyboard Repeat Keys is failing to adjust
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in X.Org X server: Fix Released
> Status in “xserver-
>
> Bug description:
> go to System > Preferences > Keyboard > General
>
> The controls under Repeat Keys are failing to properly adjust the timing of
> how fast keys are repeated when held down.
>
> I filed under gnome, but a person there thinks its an xorg bug in ubuntu:
> http://
> clear that this is a problem with the xorg-evdev driver, and intrepids new
> hotplug architecture.
>
>
> Here is a workaround for this:
>
> Temporarily add the following to your xorg.conf:
> Section "ServerFlags"
> Option "AutoAddDevices" "off"
> EndSection
>
> Restart X, and you will be able to change the settings. Once changed, you
> can remove those lines from your xorg.conf (which is recommended since
> setting AutoAddDevices to off can interfere with your keyboard)
>
>
> Another (and possibly better) workaround is to set the repeat rate manually,
> see this comment for directions:
> https:/
>
>
> This bug may also be related to bug 278078
>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #114 |
Okay, um...today the USB keyboard is working fine again. I didn't change anything. Never mind!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #115 |
thanks to everyone. I am very glad to have this bug fixed. Time for one last edit...
description: | updated |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Thane (byd) wrote : | #116 |
Not fixed yet! I'm using Ubuntu 8.10 amd 64 Desktop and I've still got the problem unfortunately. Saw the reference to xserver-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Reuben Thomas (rrt) wrote : | #117 |
Please stop this noise. The bug IS fixed IN JAUNTY AND KARMIC, as the updated description clearly says, and not in Intrepid.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #118 |
@Thane
Yep, no fix for 8.10. You will get it with 9.04 at the end of this month. (If you really need the fix now, you can upgrade to the 9.04 beta with the command `update-manager -d`. But, that has the drawback that its still beta, and still has bugs in it)
Good luck.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Rich Wales (richw) wrote : | #119 |
Intending no disrespect here to the developers, I am less than happy about the apparent decision not to try to fix this bug in Intrepid. It was my understanding that Intrepid was supposed to be supported for another year. Also, the conflicting reports regarding the nature and extent of this bug -- people saying the bug appears and goes away for no apparent reason, people disagreeing on whether fixes work for them or not, etc. -- suggest to me that the problem still might not be fully understood, and that this isn't a good time to abandon groups of users yet.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel Hollocher (chogydan) wrote : | #120 |
@Rich Wales: yes, Intrepid is supported awhile longer, but only for bugs that cause data loss or security issues.
@Reuben Thomas: hit unsubscribe. /me reaches for the unsubscribe button himself.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Reuben Thomas (rrt) wrote : | #121 |
The bug is fully understood and fully fixed, but it's quite complicated, as it involves multiple components, specifically, the interaction between X and kernel auto-repeat. That's also why the suggested workarounds are quite different, and, presumably, why the devs are not keen to backport the fix to Intrepid, though personally I think putting out a distro in which 99% of users will conclude that autorepeat is broken is very unfortunate, and not fixing it is really dumb from a PR perspective, if nothing else. But maybe it doesn't register in the big picture.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Gumby (gumbygum) wrote : | #122 |
First of all, I have not been able to reach the website for this bug,
https:/
in over a week.
I must point out that this bug is now happening approximately half the time
I start a Linux session. It's happening again today. This is despite the
fix. So, sometimes the fix works, and sometimes it does not, on the same
compuuter. It's driving me crazy even as I type this message. I'vvve already
corrected a bunch of the repeat types.
Changed in xorg-server: | |
importance: | Unknown → Medium |
Changed in xorg-server: | |
importance: | Medium → Unknown |
Changed in xorg-server: | |
importance: | Unknown → Medium |
When holding a key down keyboard repeat starts with softrepeat delay/rate settings and is interrupted temporarily when the kernel autorepeat delay/rate would have caused a character to be repeated if the kernel autorepeat would be used.
It's easiest to demonstrate the problem when setting "xset r rate 175 100; kbdrate -r 2 -d 1000" (incidentally also the settings that least disturb softrepeat). So when holding a key down the 175ms delay and 100/sec repeat rate works perfectly for 1000ms (exactly when the kernel repeat delay kicks in), then there's a shot interruption and the 100/sec rate is again continued and again interrupted, but this time after about 500ms (basically at 2/sec, which is the kernel repeate rate).
With default kbdrate settings (those set by xset itself, delay 250ms and 10.9 cps), the problem is even more annoying because the fast softrepeat rate only lasts for 250ms and then slows down to a very slow rate probably dictated by the 10.9 cps. So basically after the kernel repeat delay only the really slow kernel repeat rate applies as softrepeat seems to get no chance of doing anything between the short interruptions caused by the kernel autorepeat.
This is all with xorg-server 1.5.0, kernel 2.6.25, evdev 2.0.4.
I don't remember this problem to have existed with the kbd driver and unfortunately I'm no longer able to get the kbd driver to work (I think it gets confused by the event device which hal is providing and I'm not sure what to do about it).
Thank you,