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.

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

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 (buildd@rothera.buildd) 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Module Loader present

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

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

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 attachment 19635 [details]
My /var/log/Xorg.0.log

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 attachment 19773 [details]
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.

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.

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.

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.

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.

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.

+1 from another  poor guy upgraded to ubuntu 8.10

priority: low?!

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

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.

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

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

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.

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.

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.

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.

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

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

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.

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

Fixed by "xset r 113/116".

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

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.

it's now 7 years later, let's not pretend we'll fix this one. re-file if it's still a bug please