The key repeat delay for the "down-arrow", "left-arrow", and "End" keys is longer than the other keys

Bug #278078 reported by Ricardo Pérez López on 2008-10-04
118
This bug affects 15 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Unknown
Medium
X.Org X server
Won't Fix
Low
gnome-settings-daemon (Ubuntu)
Undecided
Unassigned
Nominated for Hardy by Stefan Baramov
Declined for Intrepid by Timo Aaltonen
Nominated for Jaunty by sirianni
xkeyboard-config (Ubuntu)
Undecided
Unassigned
Nominated for Hardy by Stefan Baramov
Declined for Intrepid by Timo Aaltonen
Nominated for Jaunty by sirianni
xserver-xorg-input-evdev (Ubuntu)
Low
Unassigned
Nominated for Hardy by Stefan Baramov
Declined for Intrepid by Timo Aaltonen
Nominated for Jaunty by sirianni

Bug Description

Binary package hint: gnome-settings-daemon

I'm testing Intrepid beta, upgraded from Hardy.

When I press & hold the "down-arrow" key, or the "left-arrow" key, or the "End" key, the delay (until the key starts to repeat) is longer than the rest of the keys in the keyboard. I have 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), or the left-arrow in the keypad (the "4" key), or the "End" key in the keypad (the "1" key).

I'm using a Spanish keyboard. In Layouts tab on "Keyboard Preferences" dialog, I have the following:

- Keyboard model: Generic 105-key (Intl) PC
- Selected layouts: Spain (default)

To test it, try the following:

1. Go to System->Preferences->Keyboard.
2. Go to Layouts tab.
3. Check "Key presses repeat when key is held down" chekbox.
4. Move the Delay rule to the very left (near to "Short" label).
5. Now, press and hold the arrow (cursor) keys. You can see that the up-arrow and right-arrow keys works OK, but you need to hold left-arrow, down-arrow and End keys more time to get the repetition work.

It's a very irritating bug!

ANOTHER (EASIER) METHOD TO REPRODUCE:

1. $ xset r rate 10 50
2. Press and hold any printable key.
3. Now, move the cursor back and forth using the left and right cursor keys (pressing and holding one of the keys and then the other after a while). You can see the left key is clearly slower than the right key. Using the down-arrow key or the End key produces the same issue.

From the GNOME's bugzilla, a developer says:

"I cannot reproduce the behaviour you describe, and in any case, key repeat
delay is a global X server setting. There is no way for us to define different
delays or different keys. So if anything, this is a bug in the X server."

I've tested then on Xfce4 and I got the same issue, so the problem is not a GNOME problem.

Another way to test the existence of the issue:

1. Go to System->Preferences->Keyboard.
2. Go to Layouts tab.
3. Check "Key presses repeat when key is held down" chekbox.
4. Move the Delay rule to the very left (near to "Short" label).
5. Go to Accessibility tab.
6. Check "Only accept long keypresses" in "Slow Keys".
7. Move the Delay rule of the "Slow Keys" section to the very left (near to "Short" label).
8. Open a Terminal. Press and hold any printable key (say, for instance, the "d" key). You can see the "d" char appearing repeatedly. Now, press and hold the left-arrow key.

Expected behavior: The blinking cursor moves repeatedly to the left, traveling all the "d" chars.

Actual behavior: The cursor moves ONLY ONE POSITION to the left, without repetition.

You can check that the down-arrow key is affected with this bug, too. However, the up-arrow key and the right-arrow key works as expected.

Download full text (3.2 KiB)

From Launchpad:
https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/278078

I'm testing Ubuntu 8.10 beta, with GNOME 2.24.0, although I've tested it on Xfce4 and I got the same issue, so the problem is not a GNOME problem.

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 rest of the keys in the keyboard. I have 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).

I'm using a Spanish keyboard. In Layouts tab on "Keyboard Preferences" dialog,
I have the following:

- Keyboard model: Generic 105-key (Intl) PC
- Selected layouts: Spain (default)

To test it, try the following:

1. Go to System->Preferences->Keyboard.
2. Go to Layouts tab.
3. Check "Key presses repeat when key is held down" chekbox.
4. Move the Delay rule to the very left (near to "Short" label).
5. Now, press and hold the arrow (cursor) keys. You can see that the up-arrow
and right-arrow keys works OK, but you need to hold left-arrow and down-arrow
keys more time to get the repetition work (the same for End key).

It's a very irritating bug!

Steps to reproduce:
1. Go to System->Preferences->Keyboard.
2. Go to Layouts tab.
3. Check "Key presses repeat when key is held down" chekbox.
4. Move the Delay rule to the very left (near to "Short" label).
5. Now, press and hold the arrow (cursor) keys. You can see that the up-arrow
and right-arrow keys works OK, but you need to hold left-arrow and down-arrow
keys more time to get the repetition work (the same for End key).

Actual results:
You can see that the up-arrow and right-arrow keys works OK, but you need to
hold left-arrow and down-arrow keys more time to get the repetition work. The
key repeat delay for left-arrow, down-arrow, and End keys is longer.

Expected results:
All the keys, without exception (including left-arrow, down-arrow & End keys) have the same repeat delay.

Does this happen every time?
Yes.

Another way to testing the existence of this bug:

1. Go to System->Preferences->Keyboard.
2. Go to Layouts tab.
3. Check "Key presses repeat when key is held down" chekbox.
4. Move the Delay rule to the very left (near to "Short" label).
5. Go to Accessibility tab.
6. Check "Only accept long keypresses" in "Slow Keys".
7. Move the Delay rule of the "Slow Keys" section to the very left (near to
"Short" label).
8. Open a Terminal. Press and hold any printable key (say, for instance, the
"d" key). You can see the "d" char appearing repeatedly. Now, press and hold
the left-arrow key.

Expected behavior: The blinking cursor moves repeatedly to the left, traveling
all the "d" chars.

Actual behavior: The cursor moves ONLY ONE POSITION to the left, without
repetition.

You can check that the down-arrow & End keys are affected with this bug, too. However, the up-arrow key and the right-arrow key works as expected.

FYI, I'm using latest Ubuntu Intrepid (fully updated), although the problem is
still present with Ubuntu Intrep...

Read more...

It has nothing to do with xkeyboard-config

(In reply to comment #1)
> It has nothing to do with xkeyboard-config
>

Sorry, Sergey, and thanks for the fast reply.

Changed in gnome-settings-daemon:
status: Unknown → Invalid

I just tried with Kubuntu Intrepid beta live CD, and I can confirm that the bug appears on KDE too, so it's obvious that it's not a GNOME problem nor a KDE problem.

I can confirm that this bug is present during a live session in Intrepid beta desktop CD, using English or Spanish language & keyboard.

Ricardo Pérez López (ricardo) wrote :

I just realized that the "End" key suffers the same issue. I tested all the keyboard, and I confirm that the issue affects only the following three keys: "left-arrow", "down-arrow", and "End" (all placed in the keyboard block which is between alphanumeric block and the keypad block).

description: updated

I don't know if the following can help:

This is what I have in my Intrepid box (which presents the problem):

$ xprop -root|grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "es", "", "lv3:ralt_switch"
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "es", "", "lv3:ralt_switch,grp:alts_toggle"

This is what I have in a Hardy box (which doesn't present the problem):

$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "es", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc105", "es", "", ""

FYI, this is my actual xorg.conf:

=======================
Section "Screen"
 Identifier "Default Screen"
 DefaultDepth 24
EndSection

Section "Module"
 Load "glx"
 Disable "dri2"
EndSection

Section "Device"
 Identifier "Default Device"
 Driver "nvidia"
 Option "NoLogo" "True"
EndSection
=======================

Interestingly, the symptoms are worse if you use the following settings in your xorg.conf:

=======================
Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "pc105"
    Option "XkbLayout" "es"
    Option "XkbOptions" "lv3:ralt_switch"
EndSection

Section "InputDevice"
    Identifier "Configured Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "ExplorerPS/2"
    Option "ZAxisMapping" "4 5"
    Option "Emulate3Buttons" "true"
EndSection
=======================

(which are the settings I had got in Hardy before updating to Intrepid). Using these settings, the "left", "down", and "End" keys delay is still longer.

I just tried with Kubuntu Intrepid beta live CD, and I can confirm that the bug appears on KDE too, so it's obvious that it's not a GNOME problem. Instead, it seems to be an X.org problem.

Changed in gnome-settings-daemon:
status: New → Invalid
Changed in xorg-server:
status: Unknown → Confirmed

I don't know if the following can help:

This is what I have in my Intrepid box:

$ xprop -root|grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "es", "", "lv3:ralt_switch"
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "es", "", "lv3:ralt_switch,grp:alts_toggle"

This is what I have in a Hardy box:

$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "es", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc105", "es", "", ""

This is my actual xorg.conf:

=======================
Section "Screen"
 Identifier "Default Screen"
 DefaultDepth 24
EndSection

Section "Module"
 Load "glx"
 Disable "dri2"
EndSection

Section "Device"
 Identifier "Default Device"
 Driver "nvidia"
 Option "NoLogo" "True"
EndSection
=======================

Interestingly, the symptoms are worse if you use the following settings in your xorg.conf:

=======================
Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "pc105"
    Option "XkbLayout" "es"
    Option "XkbOptions" "lv3:ralt_switch"
EndSection

Section "InputDevice"
    Identifier "Configured Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "ExplorerPS/2"
    Option "ZAxisMapping" "4 5"
    Option "Emulate3Buttons" "true"
EndSection
=======================

(which are the settings I had got in Hardy before updating to Intrepid). Using these settings, the "left", "down", and "End" keys delay is still longer.

Timo Aaltonen (tjaalton) wrote :

Confirmed, but not likely to be fixed for intrepid.

Changed in xorg:
importance: Undecided → Low
status: New → Confirmed

FYI, I'm using X.Org X Server version 1.5.1

$ Xorg -version

X.Org X Server 1.5.1
Release Date: 23 September 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-16-server i686 Ubuntu
Current Operating System: Linux kadath 2.6.27-5-generic #1 SMP Fri Oct 3 00:38:23 UTC 2008 i686
Build Date: 06 October 2008 03:13:08PM
xorg-server 2:1.5.1-1ubuntu2 (<email address hidden>)
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Module Loader present

icorbett (icorbett) wrote :

I can also confirm this for at least the left and down arrow keys. I'm not sure what the value of these outputs are but on an Hardy system, updated to latest packages this morning:

-(~)$ xprop -root|grep XKB
_XKB_RULES_NAMES(STRING) = "xorg", "pc101", "us", "", "lv3:ralt_switch"

And on the beta Intrepid system installed Tuesday and updated to the latest packages this morning:

-(~)$ xprop -root|grep XKB
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""

I am seriously considering rebuilding the Intrepid system using Hardy as this bug limits my ability to do my job effectively.

icorbett, +1. It's a very annoying bug.

You can say that again... I am thrashing desperately trying to find a
way to fix it even temporarily. If I have any luck I will post it here.

Ricardo Pérez López wrote:
> icorbett, +1. It's a very annoying bug.
>

ayucat (ayucat) wrote :

i've got this problem as well after updating Intrepid beta from Hardy.
in the result of xprop, evdev is appeared...

$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "jp106", "jp", "latin", "grp:alt_shift_toggle,grp_led:scroll,ctrl:nocaps"
_XKB_RULES_NAMES(STRING) = "evdev", "jp106", "jp", "", "grp:alt_shift_toggle,grp_led:scroll,ctrl:nocaps"
$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [jp]
 model =
 options = []

once executing "setxkbmap latin", the layout became like pc105...
however the followings cause some errors:
$ setxkbmap pc105
Error loading new keyboard description
$ setxkbmap pc101
Error loading new keyboard description
$ setxkbmap jp106
Error loading new keyboard description

Users who upgrades from Hardy to Intrepid will likely have the xorg.conf sections (or similar) I mentioned on comment #6, i.e.:

=======================
Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "pc105"
    Option "XkbLayout" "es"
    Option "XkbOptions" "lv3:ralt_switch"
EndSection

Section "InputDevice"
    Identifier "Configured Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "ExplorerPS/2"
    Option "ZAxisMapping" "4 5"
    Option "Emulate3Buttons" "true"
EndSection
=======================

So the problem could be bigger than expected after Intrepid release when a huge number of Hardy users upgrades massively to Intrepid.

@icorbett, @ayucat: Can you please repeat your comments on freedesktop's bugzilla? It could help for fixing the bug upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=17925

Thanks in advance.

i've got this problem as well after updating Intrepid beta from Hardy.
in the result of xprop, evdev was appeared...

$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "jp106", "jp", "latin", "grp:alt_shift_toggle,grp_led:scroll,ctrl:nocaps"
_XKB_RULES_NAMES(STRING) = "evdev", "jp106", "jp", "", "grp:alt_shift_toggle,grp_led:scroll,ctrl:nocaps"
$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [jp]
 model =
 options = []

once executing "setxkbmap latin", the layout became like pc105...
however the followings cause some errors:
$ setxkbmap pc105
Error loading new keyboard description
$ setxkbmap pc101
Error loading new keyboard description
$ setxkbmap jp106
Error loading new keyboard description

Some related parts of /etc/X11/xorg.conf on my computer are also shown as follow:
----
Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "jp106"
 Option "XkbLayout" "jp,"
 Option "XkbVariant" ""
 Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ImPS/2"
 Option "ZAxisMapping" "4 5"
 Option "Emulate3Buttons" "true"
EndSection
----

This comment is almost the same as the comment: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/278078/comments/11

The point is that using xorg is worse than using evdev, because the key delay for left, down & end is longer using xorg. That's the case when you upgrade from Hardy to Intrepid. Anyway, the problem appears using evdev, too (which is the case when you install Intrepid by scratch).

I just realized that Xorg.0.log shows two keyboards detected (I have only one):

...
(II) config/hal: Adding input device USB-compliant keyboard
(**) USB-compliant keyboard: always reports core events
(**) USB-compliant keyboard: Device: "/dev/input/event2"
(II) USB-compliant keyboard: Found x and y relative axes
(II) USB-compliant keyboard: Found 10 mouse buttons
(II) USB-compliant keyboard: Found keys
(II) USB-compliant keyboard: Configuring as mouse
(II) USB-compliant keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "USB-compliant keyboard" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) USB-compliant keyboard: xkb_rules: "evdev"
(**) Option "xkb_model" "pc105"
(**) USB-compliant keyboard: xkb_model: "pc105"
(**) Option "xkb_layout" "es"
(**) USB-compliant keyboard: xkb_layout: "es"
(**) Option "xkb_options" "lv3:ralt_switch"
(**) USB-compliant keyboard: xkb_options: "lv3:ralt_switch"
(**) USB-compliant keyboard: YAxisMapping: buttons 4 and 5
(**) USB-compliant keyboard: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) config/hal: Adding input device USB-compliant keyboard
(**) USB-compliant keyboard: always reports core events
(**) USB-compliant keyboard: Device: "/dev/input/event1"
(II) USB-compliant keyboard: Found keys
(II) USB-compliant keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "USB-compliant keyboard" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) USB-compliant keyboard: xkb_rules: "evdev"
(**) Option "xkb_model" "pc105"
(**) USB-compliant keyboard: xkb_model: "pc105"
(**) Option "xkb_layout" "es"
(**) USB-compliant keyboard: xkb_layout: "es"
(**) Option "xkb_options" "lv3:ralt_switch"
(**) USB-compliant keyboard: xkb_options: "lv3:ralt_switch"
...

Is it right? I don't think so. Curiously, the /dev/input/event2 device is detected as both mouse and keyboard. However, I have only ONE mouse and ONE keyboard. My system is a desktop computer, not a laptop or such.

Created an attachment (id=19635)
My /var/log/Xorg.0.log

Emphyrio (syprien) wrote :

I might have the same bug, but for me all key share the problem.

1. Go to System->Preferences->Keyboard.
2. Go to Layouts tab.
3. "Key presses repeat when key is held down" chekbox is checked.
4. Place cursor in the field, hold the key. only one letter appear even if i hold one minute.
4. Move the Delay rule a litlle.
5. Now, it will works normally for ten minutes ...

It appears after i got some issue with my keyboard (it simply stop working in gnome) and be forced to install 'xserver-xorg-input-all'

I just realized that Xorg.0.log shows two keyboards detected (I have only one):

...
(II) config/hal: Adding input device USB-compliant keyboard
(**) USB-compliant keyboard: always reports core events
(**) USB-compliant keyboard: Device: "/dev/input/event2"
(II) USB-compliant keyboard: Found x and y relative axes
(II) USB-compliant keyboard: Found 10 mouse buttons
(II) USB-compliant keyboard: Found keys
(II) USB-compliant keyboard: Configuring as mouse
(II) USB-compliant keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "USB-compliant keyboard" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) USB-compliant keyboard: xkb_rules: "evdev"
(**) Option "xkb_model" "pc105"
(**) USB-compliant keyboard: xkb_model: "pc105"
(**) Option "xkb_layout" "es"
(**) USB-compliant keyboard: xkb_layout: "es"
(**) Option "xkb_options" "lv3:ralt_switch"
(**) USB-compliant keyboard: xkb_options: "lv3:ralt_switch"
(**) USB-compliant keyboard: YAxisMapping: buttons 4 and 5
(**) USB-compliant keyboard: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) config/hal: Adding input device USB-compliant keyboard
(**) USB-compliant keyboard: always reports core events
(**) USB-compliant keyboard: Device: "/dev/input/event1"
(II) USB-compliant keyboard: Found keys
(II) USB-compliant keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "USB-compliant keyboard" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) USB-compliant keyboard: xkb_rules: "evdev"
(**) Option "xkb_model" "pc105"
(**) USB-compliant keyboard: xkb_model: "pc105"
(**) Option "xkb_layout" "es"
(**) USB-compliant keyboard: xkb_layout: "es"
(**) Option "xkb_options" "lv3:ralt_switch"
(**) USB-compliant keyboard: xkb_options: "lv3:ralt_switch"
...

Is it right? I don't think so.

Curiously, the /dev/input/event2 device is detected as both mouse and keyboard. However, I have only ONE mouse and ONE keyboard. My system is a desktop computer, not a laptop or such.

Søren Holm (sgh) wrote :

I just removed the core keyboard thing in "ServerLayout". But it did not help.

Any news about this issue?

I can confirm the issue on, at least, two additional computers, using either USB or PS/2 keyboards.

$ setxkbmap -print
xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+es+inet(evdev)+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)+level3(ralt_switch)" };
 xkb_geometry { include "pc(pc104)" };
};

Created an attachment (id=19773)
xkbcomp :0 -

This is the "xkbcomp :0 -" output.

Switching the distribution layout model from "PC Generic 105 keys (Intl)" to "Evdev-managed keyboard" doesn't solve the problem.

Using:

$ xinput test 5

I realized the key presses and releases are correctly detected for all the keys, but however the key delay for left, down and End is abnormaly longer. You can check this very easily if you do:

$ xset r rate 10 50

(for instance) before the "xinput test" command.

ANOTHER (EASIER) METHOD TO REPRODUCE THE ISSUE:

1. $ xset r rate 10 50
2. Press and hold any printable key.
3. Now, move the cursor back and forth using the left and right cursor keys. You can see the left key is clearly slower than the right key. Using the down-arrow key or the End key produces the same issue.

$ setxkbmap -print
xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+es+inet(evdev)+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)+level3(ralt_switch)" };
 xkb_geometry { include "pc(pc104)" };
};

This is the "xkbcomp :0 -" output.

Switching the distribution layout model from "PC Generic 105 keys (Intl)" to "Evdev-managed keyboard" doesn't solve the problem.

Using:

$ xinput test 5

I realized the key presses and releases are correctly detected for all the keys, but however the key delay for left, down and End is abnormaly longer.

description: updated
description: updated
Bryce Harrington (bryce) on 2008-11-07
Changed in xorg-server:
status: Confirmed → Triaged
Changed in xkeyboard-config:
status: New → Invalid
Changed in xorg-server:
status: Confirmed → Invalid
Changed in xorg-server:
status: Invalid → Unknown
Changed in xorg-server:
status: Unknown → Confirmed
Changed in xorg-server:
status: Confirmed → Fix Released
33 comments hidden view all 113 comments

I experienced the same issue, and found it critically important. I would have installed a new distro to avoid this issue, as I was very unproductive with my work, it was causing me to make continual mistakes when editing my programs and web sites in Vim. I heavily rely on my repeat rate of 150 ms delay and 40 characters per second repeat, and expect the cursor to move at exactly that rate -- I don't even look where the cursor is much of the time, knowing how fast it travels and where it should be.

The solution for me was the one suggested above:

Option "AutoAddDevices" "Off"

I tried this after noticing that my Xorg.3.log file showed that not only was the "kbd" driver being loaded, which is the one I specified in my xorg.conf file, but also one which I did not specify which was coming from HAL and using the "evdev" driver.

It seems the auto added "evdev" and "kbd" drivers were somehow competing for the same keyboard. All is fine once only one driver is being loaded.

Cheers.

Arlyn Nisly (humph) wrote :

I've been experiencing the same issue; here is a workaround that works for me:

https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/281546

In short,

xset r 116
xset r 113
synergyc <HOST'S IP>

Switched to upstream #17925, since the Left, Down and End problem is not solved with the latest patch from #17500.

Changed in xorg-server:
status: Fix Released → Unknown
Changed in xorg-server:
status: Unknown → Confirmed

A more current title for this bug would now be 'Key repeat for "down-arrow", "left-arrow" & "End" keys is not happening at all'.

The fact that the key-repeat for these keys did happen (albeit at a different rate from other keys) was a symptom of another bug, namely #17500. When the fix for #17500 is applied, so that only evdev is dealing with key-repeats, the effect is that there is no key-repeat for these three keys.

(While I agree that having different rates for different keys might possibly described as a bug of "minor" severity, I do think that having no key-repeat at all on arrow-keys is now a "major" loss of function.)

I have the same problem on a Hardy system which was upgraded from Gutsy.

Possibly the same as (part of) this bug is the fact that certain keys that should not repeat actually *do* repeat. This is also reported as a Fedora but at:

  https://bugzilla.redhat.com/show_bug.cgi?id=468619

On my system, the right-hand Ctrl and Alt keys have this problem, as well as the Win key and the Menu key. These keys can be prevented from repeating usin "xset -r 105" etc, but they should not be repeating at all. As pointed out in the Fedora bug report, this prevents one from selecting multiple items in Nautilus by holding the (right-hand) Control key and dragging a over a rectangle ("rubber-band").

Any news about this issue?

From Launchpad:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/264196/comments/43

I applied the patch from

http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/patch/?id=ece72ce9e97adae23b1932dc1334f63669196d56

to the intrepid version of xserver-xorg-input-evdev. After restarting X, keyboard delay and repeat could once again be set using the gnome "Keyboard Preferences".

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-xorg-input-evdev exposed me to the other bug: Left, Down and End keys not repeating. This I could work around using xset as suggested by Ricardo above.)

The same problem here on Jaunty beta, but it seems every key is affected... It's very annoying.

Søren Holm (sgh) wrote :

The problem is actually fixed in current jaunty, and has been so for a while.

It was fixed and now it's broken again.

The left and down arrow keys do not repeat for me either. The same arrow keys on the number pad work fine, however. The problem started with xf86-input-evdev-2.1.99.1. Versions upto xf86-input-evdev-2.1.3 work just fine. For the later versions, I've had to add the following commands to my ~/.xinitrc:

xset r 113 # left-arrow key repeats
xset r 116 # down-arrow key repeats also

The particular version of the xorg-server being used does not seem to matter. I'm using 1.6.1. My keyboard is an PS/2 TVS Champ keyboard with 107 keys, model no. KB-1808. The relevant xorg.conf lines on my PC:

Section "InputDevice"
        Identifier "Keyboard0"
        Driver "evdev"
        Option "CoreKeyboard"
        Option "Device" "/dev/input/event0"
# Option "Name" "AT Translated Set 2 keyboard"
        Option "AutoRepeat" "250 50"
        Option "XkbModel" "pc104"
        Option "XkbOptions" "ctrl:swapcaps"
EndSection

In comment #31, Raven Morris suggested using:

Section "ServerFlags"
        Option "AutoAddDevices" "Off"
EndSection

to fix the problem. This does not work for me.

Thanks,
Rajeev

Martijn Bastiaan (hmb1) wrote :

"Me too"

This seems to fix it: xset r 113; xset r 116

Nico Kempe (nkempe) wrote :

"This seems to fix it: xset r 113; xset r 116"
Indeed it does. Thanks.

I can confirm that this bug only happens with "evdev", but not with "kdb".

regards,
iustin

Hello,

I recently upgraded to Fedora 11 (xorg-x11-drv-evdev-2.2.1-3.fc11.x86_64) on a dual seat machine, and I started having problems with repeating keys. That is, left arrow, down arrow, and end would not repeat, while right ctrl would repeat when it shouldn't.

I believe this behavior is indicative of the following: the auto repeating keys map as show by 'xset q' is appropriate for the keycodes generated by the kbd driver, but the keyboard is controlled by the evdev driver and generating a different set of keycodes. For some reason, some of the time this map is not getting initialized properly when using the evdev driver.

On my system, I narrowed it down to the following: if the ServerFlags "AutoAddDevices" and "AllowEmptyInput" are both true, then the repeating keys map is set correctly. If either one is false, then the repeating keys map is always set for kbd keycodes, even if the keyboard is controlled by evdev.

I hope this information helps in tracking down the problem.

Cheers, Wayne

P.S. Since I have a dual seat system, I need to control which input devices each X process uses. Originally I did this with AutoAddDevices = false, so X would only see the devices specified in xorg.conf. I was able to workaround the above problem by switching to AutoEnableDevices = false and AllowEmptyInput = true. Now X see all the input devices, but each X process only uses the devices specified in the xorg.conf.

This annoying bug is fixed in Ubuntu Jaunty (at least, I can't reproduce it since I upgraded from Intrepid to Jaunty two months ago). For me, it's fixed now.

This annoying bug is fixed in Ubuntu Jaunty (at least, I can't reproduce it since I upgraded from Intrepid to Jaunty two months ago). For me, it's fixed now!

For me it is broken on a fresh install of ubuntu jaunty.

Fixed by "xset r 113/116".

Oli Wade (olithered) wrote :

For me it is broken on a fresh install of jaunty.

Fixed by "xset r 113/116".

Oli:

I'd just tried with a Jaunty Live CD in a live session (without installing) and I can't reproduce the issue.

Have you tried with a Jaunty live session?

Oli Wade (olithered) wrote :

Hi Ricardo. Thanks for your suggestion!

I have a dual seat configuration and use the "evdev" driver, so I'm not sure that I can (easily) reproduce the same setup with the live CD.

I noticed that above there is a suggestion that the keys do repeat but take longer while for me they did not repeat at all (at least for 30 seconds of holding down), so maybe there is a slightly different error.

I can post my xorg.conf if you'd like?

Joel Lehtonen (zouppen) wrote :

"Me too"

I've set up a multiterminal (multiseat) system with Ubuntu 9.04 (jaunty). One part of reconfiguration was to change Driver "kbd" to "evdev" inside xorg.conf. The problem with down-arrow and left-arrow appears on both terminals.

Thanks to the community for a workaround and hope it will be fixed in next release.

Following Wayne Whitney's suggestion in comment #38 has fixed the bug for me. Thanks, Wayne.

I can confirm this bug with xorg-server-1.6.1.901-r3 and xf86-input-evdev-2.2.2 without hal on Gentoo distribution. In particular the Left, Down and End keys do not autorepeat at all. Also confirming that the workaround `xset r 113; ...' works for me.
However it is just a _workaround_. I suspect the keycodes 113, 115 and 116 are mistakenly considered modifiers and hence not autorepeated. This is suggested by the fact that these keycodes are assigned to RALT, RWIN and LWIN when using standard kbd driver (compared to Left, Down and End when using evdev).
I hope this observation will help someone more familiar with XKB conf files truly fix this bug.

(In reply to comment #41)
> Following Wayne Whitney's suggestion in comment #38 has fixed the bug for me.
> Thanks, Wayne.
>

Ditto, This fixed it for me after hours of struggle with xorg.cong and evdev!

Thanks!

comment#38 is working.
Conclusion: It is not evdev problem.
Please update subject and reassign to correct component, so this will be fixed.
Thanks!

If the problem is not in evdev, what part of Xorg is responsible for setting the default "autorepeating keys" map properly?

Wayne

Bryce Harrington (bryce) on 2009-09-02
tags: added: intrepid
Nico Kempe (nkempe) wrote :

This bug seems to be fixed in Ubuntu 9.10, Karmic Koala.
I've upgraded from 9.04 to 9.10, and the repeat for the down and left arrow keys works like normal now.

Søren Holm (sgh) wrote :

agree

Bryce Harrington (bryce) wrote :

Thanks for letting us know the issue is resolved.

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Triaged → Fix Released

I got this annoying behavior too, after I upgrade evdev from 2.1.3 to 2.2.5 (along with upgrade xserver to 1.6). xset -r <keycode> workaround works for me, but it's only workaround. I tried downgrade evdev back to 2.1.3 and autorepeat works nice, like before upgrades. Is really autorepeat map on blame, when evdev version change helps?

Section "InputDevice"
        Identifier "Keyboard0"
        Driver "evdev"
        Option "protocol" "evdev"
        Option "Device" "/dev/input/event0"
        Option "XkbModel" "evdev"
# Option "XkbLayout" "us"
        Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

Somehow updating to xorg 1.7.1 (and rebuilding of all related input drivers) made this problem go away for me. Anyone else had the same luck?

(In reply to comment #47)
> Somehow updating to xorg 1.7.1 (and rebuilding of all related input drivers)
> made this problem go away for me. Anyone else had the same luck?
>

I can confirm that the bug has disappeared with xorg-server-1.7.1 and xf86-input-evdev-2.3.0. Neither of the hacks in comment #36 and in comment #38 are required.

I can also confirm that this problem is solved.
But from time to time the keyboard just stops responding...
I have mouse+keyboard in evdev... Only keyboard stops responding at random time.

(In reply to comment #49)
> I can also confirm that this problem is solved.
> But from time to time the keyboard just stops responding...
> I have mouse+keyboard in evdev... Only keyboard stops responding at random
> time.
>

I can confirm this. It happens mostly when I alt+tab and it's xkbcomp that's the culprit. Using KDE I'm able to work around this by going to System Settings -> Regional & Language -> Keyboard Layout and adding a layout, hitting apply. Then the keyboardlayouts are reloaded and my keyboard starts working again. Since this is xkbcomp-problem I can ALT+CTRL+F(x) out to console aswell. I can't remember the exact error in the console where X was started, but it was something about RALT already being mapped and input being ignored. I'll post back whenever it happens again and I can look more closely.

I see this problem too. I set a crazy repeat values:

# lshal | sed -n '/input.product.*Keyboard/,+5p'
  input.product = 'Dell Dell USB Keyboard' (string)
  input.x11_driver = 'evdev' (string)
  input.x11_options.AutoRepeat = '1000 250' (string)
  input.xkb.layout = 'us,cz,ru' (string)
  input.xkb.model = 'evdev' (string)
  input.xkb.options = 'terminate:ctrl_alt_bksp,grp:switch,grp:alt_shift_toggle,grp_led:scroll' (string)

... yet the keyboard, when unplugged and re-plugged, has some sort of default repeat ratio.

I took a peek in the sources. config/hal.c:device_added doesn't name that option explicitly (it does so for layout, model, etc.), but it sticks it into its option array anyway. NewInputDeviceRequest then adds all these options to IDevRec::commonOptions. hw/xfree86/common/xf86Option.c:xf86CollectInputOptions then copies this over to InputInfoPtr::config. Then I gave up, `config' is mentioned in too many places for me to sift through.

Oops, wrong bug. Ignore my comment please.

martin hodges (martin-hodges) wrote :

The issue is not resolved, it is only masked. If the xorg.conf file has an InputDevice section that refers to the kbd driver, X reports an error that there is no 'kbd' driver and the odd behaviour occurs.
The bug disappears if all references to the kbd are removed from the xorg.conf file.
All users that upgrade with manually edited xorg.conf files will get hit by this. The documentation concerning the present handling of input devices in xorg is very poor. I use a serial MouseSystems trackball (MEDL actually). Xorg ignores by default all entries in xorg.conf that refer to input devices and keyboards. The normal udev detection works for modern devices but not for older serial devices. The way to enable manual mouse entries is to include the line:-
    Option "AllowEmptyInput" "false"
in the ServerLayout section. This enables the manually added sections without disabling autodetected devices. How is the handling of touchpad options managed now?

martin hodges (martin-hodges) wrote :

My bad. Wrong bug. Removing references from the xorg.conf file may work once but the non-repeat behaviour returned when I rebooted. Bug 366041.

Changed in xorg-server:
importance: Unknown → Low
Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: Invalid → Unknown
Changed in xorg-server:
importance: Low → Unknown
Changed in xorg-server:
importance: Unknown → Low
Changed in xorg-server:
status: Confirmed → Won't Fix
Displaying first 40 and last 40 comments. View all 113 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.