Bug 1651

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).