After I upgraded to the kbd driver, the autorepeat becomes very slow after spitting out ca 40 keycodes. My setting is 'xset r rate 200 50'. The same problem occurs when setting 'Option "AutoRepeat" "..."' in xorg.conf, and not changing it with 'xset'. I use Gentoo, but the problem has also been reported for Fedora: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134110
I have the same problem, running Gentoo on both x86 and amd64 platform. I spent some time trying to characterize the bug. It seems that when the settings of "Option AutoRepeat" in xorg.conf and "xset r rate" are the same, there is no problem. But it seems like the xorg.conf setting takes precedence over xset except during the delay time interval according to xorg.conf. After that time, xorg.conf repetition rate is used. The default setting in xorg.conf is Autorepeat 500 5 which will give a 500ms delay with repetition of 5 characters/second. Setting 'xset r rate 100 50' will now reproduce the bug. When pressing a key, it seems like the next character is delayed 100ms, and then repeated at a rate of 50 characters/second until 500ms has passed. Then characters are repeated with a rate of 5 characters/second. Having a larger timeout or slower repetition rate with the xset command compared to xorg.conf will result in the parameters from xorg.conf will determine the behaviour. --- Mikael Rosbacke
I discovered that setting the rate of the keyboard with 'kbdrate' also affects the behaviour in X. It seems like the X server stops it's own autorepeat as soon as it sees the first repeated scancode from the keyboard. When the delay is set very high with 'kbdrate', it takes that long before X starts to misbehave. Thus, for those who can disable autorepeat in their keyboards, that may be a workaround. Otherwise, if you are lucky, your keyboard has a usable autorepeat, and you can disable software repeat by setting the delay high with 'xset' as explained by M. Rosbacke. (Unfortunately, neither solution is feasible on my Kinesis keyboard.)
Created attachment 1320 [details] [review] Filter out all autorepeat scancodes generated by keyboard Why was the code in kbd.c intentionally letting through hardware autorepeat at all, when there already is code to filter some? Anyway, autorepeat works smoothly for me with this patch.
Patch commited. Thanks. This probably needs to go into 6.8.2 too.
Great news, good work. I've been wanting to look into this for a while, now I wont have to :) I'm closing the bug. cheers, Kristian
Oh, and I vote for inclusion into 6.8.2 as well.
Hmm. The proposed fix is not correct. It breaks auto-repeat at least on OpenBSD if you don't change the default repeat rate (which relies on the hardware auto-repeat) or if you disable XKB. I think the correct fix is to keep a private copy of the autoRepeat flag in the kbd driver, like the legacy driver does. New patch is following shortly.
Created attachment 1483 [details] [review] keep a local copy of autoRepeat flag
Created attachment 1484 [details] [review] [FIXED_X11R68x] Hmm this is the correct patch, relative to 6.8.1. This patch also adds the switch to pc105 as the default model, to sync with the legacy keyboard driver behaviour.
Comment on attachment 1484 [details] [review] [FIXED_X11R68x] Hmm this is the correct patch, relative to 6.8.1. Approval for X11R6.8.x stable branch granted in the 2004-12-13 release-wranglers phone call. Please don't commit yourself, I'll do that myself...
Comment on attachment 1484 [details] [review] [FIXED_X11R68x] Hmm this is the correct patch, relative to 6.8.1. Patch checked-in into X11R6.8.x stable branch: /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.365.2.99; previous revision: 1.365.2.98 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. /cvs/xorg/xc/programs/Xserver/hw/xfree86/input/keyboard/kbd.c,v <-- kbd.c new revision: 1.6.2.1; previous revision: 1.6 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. Mailing the commit message to xorg-commit@lists.freedesktop.org...
Patch checked-in into Xorg trunk and X11R6.8.x stable branch... ... marking bug as FIXED.
*** Bug 1832 has been marked as a duplicate of this bug. ***
*** Bug 2122 has been marked as a duplicate of this bug. ***
i think that this patch is buggy. I only know the xfree86 version,but it seems the problem applies here too. My note/description can be found here: http://maruska.dyndns.org/comp/activity/mails/down In _few_ words: the bit array down is not updated when the device is frozen (sync grab), so if you release and re-press a key during the grab, the press event will be discarded (due to this patch, which afaik is the behaviour of the original xfree86 kbd driver). The right solution, imo, is a correct code for Auto-repeat (in XKB). I have it, i'm willing to provide it, but there is need for precise time information of the key events (something the evdev driver does't provide). Doing that is simple, my solution would be have a clone of xf86PostKeyboardEvent, called from evdev, which uses a provided time,instead of calling GetTimeInMillis. And, another thing; evdev would have to provide the time of last read from keyboard device. I.e. when no event arrives, i still need some time (point) - a correct upper bound of the time when really no events occured on the physical keyboard.
by "correct code for Auto-repeat" i mean auto-repeat coordinated (correctly) with AllowSome & friends (i.e PlayReleasedEvents must generate the AR to fill time gaps between the hardware events).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.