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

[Ricardo Pérez López]

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.

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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

[Sergey V. Udaltsov (svu)]

It has nothing to do with xkeyboard-config

[Ricardo Pérez López (ricardo)]

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

Sorry, Sergey, and thanks for the fast reply.

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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

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

[Ricardo Pérez López (ricardo)]

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", "", ""

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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", "", ""

[Ricardo Pérez López (ricardo)]

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

Confirmed, but not likely to be fixed for intrepid.

[Ricardo Pérez López (ricardo)]

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

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.

[Ricardo Pérez López (ricardo)]

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

[icorbett (icorbett)]

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

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

[Ricardo Pérez López (ricardo)]

The bug has been confirmed by another two users in Launchpad:

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

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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

[ayucat (ayucat)]

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

[Ricardo Pérez López (ricardo)]

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

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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

[Emphyrio (syprien)]

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'

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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

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

[Ricardo Pérez López (ricardo)]

Any news about this issue?

[Ricardo Pérez López (ricardo)]

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

[Ricardo Pérez López (ricardo)]

$ 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)" };
};

[Ricardo Pérez López (ricardo)]

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

This is the "xkbcomp :0 -" output.

[Ricardo Pérez López (ricardo)]

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

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

$ 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)" };
};

[Ricardo Pérez López (ricardo)]

This is the "xkbcomp :0 -" output.

[Ricardo Pérez López (ricardo)]

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

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

Latest Intrepid live CD still has the issue.

To easily reproduce:

1. Download and boot into latest Intrepid live CD.
2. Applications->Accessories->Terminal.
3. Type:

xset r rate 10 50

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

[jessed (jesse-driskill)]

   I only appear to be affected by this issue if I start synergy to control the ubuntu system from my windows system. Once started, the local keyboard and remote keyboard both experience this issue. It continues even after synergy is stopped.

   I don't know if this is helpful or not, but I can run whatever diagnostic commands might assist in identifying the cause.

thanks,
--jesse

[Ricardo Pérez López (ricardo)]

@jessed:

1. Are you affected by this bug when you start your Ubuntu desktop normally?
2. What if you type the "xset r rate 10 50" command on a terminal prompt and then press and hold the left and right cursor keys to move over a typed text? Is the left slower than the right?
3. What Ubuntu version do you use? What keyboard layout?

Thanks in advance.

[Te Anton (te-anton)]

+1 After upgrade from 8.04 to 8.10

I do:

sudo kbdrate -d 1 -r 50

It little help. But:
1. I need delay 100 and keyboard repeat rate 50. Current parameters 250/32. It is very slow for me.
2. After reboot problem returned.

[Ricardo Pérez López (ricardo)]

@Te:

This bug is about a repeat delay problem with Left, Right & End keys *INSIDE X-WINDOW*. Do you have problems in X-Window or in the Linux console?

[Te Anton (te-anton)]

I have problems in X-Window. I found partial solution of this problem. I do:

1. in terminal: sudo kbdrate -d 1 -r 50
2. System/Preference/Keyboard, tab General, move Speed rule to left position (Slow).

But this is not good for me. I need delay 100 and speed 50.

[Ricardo Pérez López (ricardo)]

Sorry. I just tried your workaround, but it didn't work for me :(.

Please, 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. 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.

Can you please test if you can reproduce the above behavior?

[Te Anton (te-anton)]

I did your test. I confirm. I have some problem. What is mean?

[Ricardo Pérez López (ricardo)]

So obviously it seems to be a problem in the new X.Org 1.5 keyboard driver or, maybe, in the evdev handler. I haven't got the necessary knowledge of the X.Org internals to do a further diagnostic. The bug had been notified to the upstream developers, and had been confirmed, but still no improvements.

[Tully (tully.foote)]

@jessed

I too have the problem when I start using synergy. Left arrow, down arrow and others stop working. However if I quit or stop synergy fully it recovers. (I'm using the quicksynergy gui)

[Ricardo Pérez López (ricardo)]

At

https://bugs.launchpad.net/bugs/278078

some other users reported the same issue, with both GNOME and KDE, and had been confirmed by an Ubuntu Core Developer.

[Søren Holm (sgh)]

I but the way uses kde 4.1.2 and it also have the problem. So it es not only related to gnome

[Bryce Harrington (bryce)]

This isn't a bug in xkeyboard-config so closing out this task.

[John Watson (jwatson)]

I arrived here from the launchpad.net bug report. I have the same problem on my system and can reproduce the problem using Ricardo's method in comment 18. This is a fresh install of Ubuntu Intrepid 8.10 (not an upgrade). I previously had no problem with the same hardware on Ubuntu Hardy 8.04.

I'm happy to oblige with any diagnostic info you may need.

[John Watson (jwatson)]

I just noticed another symptom: the key repeat speed changes while holding down a key. To reproduce:

1. Open a text editor (I tried in GVIM and in Gedit)
2. Hold down X
3. After approximately 1 or 2 seconds the key repeat delay changes.

If I set my key repeat to the slowest setting and do this test, the key repeat gets faster. If I set it to the fastest setting, it slows down. The new speed appears to be identical in both cases.

I get similar behavior when I use the arrow keys to scroll up or down in Firefox. Down arrow is consistently slow. Up arrow is fast for a second and then slows to the "down arrow" speed.

[Coenraad Loubser (launchpad-net-wish)]

I'm having the same issue on Intrepid on a Compaq NX6110 Laptop.

Clean install of Ubuntu 8.10; Change the keyboard repeat rate under System Preferences. All keys are affected by the new repeat rate, except for the "left arrow" and "down arrow". (Can't really test "end" repeat rate!)

I do not recall having the same problem with other distributions or versions of Linux. I will double check and confirm.

My suspicion is either a driver problem, or a hardware problem. Lets eliminate the latter by confirming that it can indeed work properly.

I am available to do any tests if necessary.

[sirianni (eric-sirianni)]

Here's a "me too" on both accounts.

I've filed an ubuntu launchpad bug 299144 https://bugs.launchpad.net/ubuntu/+bug/299144 for the "temporary nature" of the repeat key setting.

To summarize, here is what I'm observing:

1. The "down" and "left" arrow keys always repeat at a slow rate. I have not been able to find any setting that will change this.
2. The remaining keys repeat at a rate dictated by the "gnome keyboard preferences" setting ("repeat keys speed"). However, this rate is only used for the first 15 or so repeats. After that the rate reverts to the same slow speed that the "down" and "left" arrow keys repeat at.

This is a serious usability issue for anyone who uses their machine as a development workstation.

[sirianni (eric-sirianni)]

Here's a "me too".

I've filed an ubuntu launchpad bug 299144 https://bugs.launchpad.net/ubuntu/+bug/299144 for the "temporary nature" of the repeat key setting.

To summarize, here is what I'm observing:

1. The "down" and "left" arrow keys always repeat at a slow rate. I have not been able to find any setting that will change this.
2. The remaining keys repeat at a rate dictated by the "gnome keyboard preferences" setting ("repeat keys speed"). However, this rate is only respected for the first 15 or so repeats. After that, the rate reverts to the same slow speed that the "down" and "left" arrow keys repeat at.

This is a serious usability issue for anyone who uses their machine as a development workstation.

[Ricardo Pérez López (ricardo)]

From Launchpad bugreport (https://bugs.launchpad.net/bugs/278078):
------------------------------------------------------------------

Gah! I just upgraded to Intrepid and this happens to me too. Left and down aren't much slower at repeating than the other keys, but all the keys are quite slow. I can get at most about 6 keypresses per second.

By twiddling with the keyboard repeat controls, xset r rate, and (oddly enough) turning "slow keys" on and off in Accessibility, I can create all kinds of strange behaviors:
* xset r rate allows me to get very fast key repeats... but they happen in a spaced out rhythm. That is, I get 5 keypresses at once, then a 1/6 second or so pause, then 5 more keypresses, and so on.
* If I turn on "slow keys" in Accessibility (oddly enough), I get almost the behavior I want... except that left and down don't repeat _at all_, which is of course a dealbreaker.
* If I set the key repeat delay too low, I get the repeat rate I asked for... for about half a second. Then it slows down to 6 per second.
* If I use xset r rate and move the key repeat sliders anywhere in the Keyboard control panel, it goes back to the slow rate.

I assume from this behavior that there are two things competing for the keyboard repeat rate.

https://bugs.edge.launchpad.net/bugs/264196 seems to be describing the same issue, but over there they've found a few workarounds! Here's the one that worked for me with the least nasty side-effects:

Add this to the end of xorg.conf:

Section "ServerFlags"
Option "AutoAddDevices" "off"
EndSection

The downside is that any extra keys on your keyboard (such as "multimedia keys") won't work.

[Rob Speer (rspeer)]

Gah! I just upgraded to Intrepid and this happens to me too. Left and down aren't much slower at repeating than the other keys, but all the keys are quite slow. I can get at most about 6 keypresses per second.

By twiddling with the keyboard repeat controls, xset r rate, and (oddly enough) turning "slow keys" on and off in Accessibility, I can create all kinds of strange behaviors:
* xset r rate allows me to get very fast key repeats... but they happen in a spaced out rhythm. That is, I get 5 keypresses at once, then a 1/6 second or so pause, then 5 more keypresses, and so on.
* If I turn on "slow keys" in Accessibility (oddly enough), I get almost the behavior I want... except that left and down don't repeat _at all_, which is of course a dealbreaker.
* If I set the key repeat delay too low, I get the repeat rate I asked for... for about half a second. Then it slows down to 6 per second.
* If I use xset r rate and move the key repeat sliders anywhere in the Keyboard control panel, it goes back to the slow rate.

I assume from this behavior that there are two things competing for the keyboard repeat rate.

[Rob Speer (rspeer)]

Bug 264196 seems to be describing the same issue, but over there they've found a few workarounds! Here's the one that worked for me with the least nasty side-effects:

Add this to the end of xorg.conf:

Section "ServerFlags"
Option "AutoAddDevices" "off"
EndSection

The downside is that any extra keys on your keyboard (such as "multimedia keys") won't work.

[Ricardo Pérez López (ricardo)]

Rob,

The "AutoAddDevices OFF" workaround works as you tell:

1. Fix the repeat delay problem for the left, down & end keys.
2. Fix the repeat speed problem (the keys seems to be faster when you press and hold down any of them).
3. However (sadly) the multimedia keys no longer works.

Obviously, this is a step forward, while waiting for an upstream developer solution.

[Søren Holm (sgh)]

Works for me as well.

[Te Anton (te-anton)]

It's works for me too. Thank you, Rob.

[Attila Lendvai (attila-lendvai)]

+1 from another poor guy upgraded to ubuntu 8.10

priority: low?!

this is an incredibly annoying bug... please, treaat it with higherr pririty!

[Peter Hutterer (peter-hutterer)]

Look, we got bugs that crash the server, screw up output rendering, disable your input devices completely, etc.

I understand that this bug is annoying, but being overly vocal to up the priority is not the right to do.

[Luke Ashe-Browne (lukeab)]

Yes, having the same issue when using quicksynergy, on dell D630 as server and dell precision 3800 as client, more or less. There's a slight point of difference perhaps.
It is only happening when focus is on the client machine, with only with the remote keyboard, not the clients local keyboard. Both machines with thier own keybaords are fine.
I just can't live without the multimedia volume keys as I play rhythmbox as my focus shield(cut out the rest of the world) while coding. So can't use the xorg fix :( The down arrow is getting close to causing mega carpel tunnel issues for me though.

[Ricardo Pérez López (ricardo)]

The "AutoAddDevices OFF" workaround suggests that the problem is in Input/evdev, not Input/XKB. I'll change this in the bugreport accordingly.

[Daniel Stone (daniels)]

*** This bug has been marked as a duplicate of bug 17500 ***

[Ricardo Pérez López (ricardo)]

Daniel, thanks for taking care of this bugreport.

So the left, down & end keys delay issue is clearly related to a more general problem, isn't it? I wonder why these three keys are so special in that sense.

[Ricardo Pérez López (ricardo)]

The "AutoAddDevices OFF" workaround suggests that the problem is in
xserver-xorg-input-evdev, not xorg-server. Waiting for an X developer to confirm that.

[Daniel Stone (daniels)]

well, that's my hypothesis, anyway. the repeat delay for the arrow keys is slightly different to the alphabetic keys, so that presumably just induces undesirable side effects. the fix should be pretty easy.

[Ricardo Pérez López (ricardo)]

The fix from bug #17500 does NOT resolve the Left, Down and End keys issue, as an user reported here:

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

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 this bug, because there's obviously not the same problem as bug #17500.

[Freedesktop-atu (freedesktop-atu)]

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

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>

[Ricardo Pérez López (ricardo)]

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

[mannheim (kronheim)]

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

[Petri Savilahti (petri-savilahti)]

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

[mannheim (kronheim)]

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

[Ricardo Pérez López (ricardo)]

Any news about this issue?

[Ricardo Pérez López (ricardo)]

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

[Pawel (pslomski64-deactivatedaccount)]

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

[Søren Holm (sgh)]

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

[Pawel (pslomski64-deactivatedaccount)]

It was fixed and now it's broken again.

[Rajeev V. Pillai (rajeevvp)]

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

"Me too"

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

[Nico Kempe (nkempe)]

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

[Iustin Pop (iustin)]

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

regards,
iustin

[Whitney-post (whitney-post)]

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.

[Ricardo Pérez López (ricardo)]

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.

[Ricardo Pérez López (ricardo)]

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!

[Oli Wade (olithered)]

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

Fixed by "xset r 113/116".

[Oli Wade (olithered)]

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

Fixed by "xset r 113/116".

[Ricardo Pérez López (ricardo)]

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

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

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

[Rajeev V. Pillai (rajeevvp)]

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

[zimous (zimous)]

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.

[Wael Nasreddine (emxyzptlk)]

(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!

[Alon Bar-Lev (alon-barlev)]

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

[Whitney-post (whitney-post)]

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

Wayne

[Nico Kempe (nkempe)]

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

agree

[Bryce Harrington (bryce)]

Thanks for letting us know the issue is resolved.

[Drakoun (drakoun)]

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

[Bugzilla-marinmo (bugzilla-marinmo)]

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?

[Rajeev V. Pillai (rajeevvp)]

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

[Alon Bar-Lev (alon-barlev)]

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.

[Bugzilla-marinmo (bugzilla-marinmo)]

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

[Petr Machata (pmachata)]

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.

[Petr Machata (pmachata)]

Oops, wrong bug. Ignore my comment please.

[martin hodges (martin-hodges)]

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

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.