after installing xf86-input-evdev-2.2.0 left arrow button does not repeat events on long pres 2.1.3 still works fine Reproducible: Always Steps to Reproduce: 1. install xf86-input-evdev-2.2.0 2. type something in any input field 3. hold left arrow Actual Results: move left only one symbol Expected Results: move to each left symbol until start of line xorg-server-1.5.3-r3 gnome hal-0.5.11-r8
Same here. In addition, also breaks the down-arrow button.
I just wanted to report the same.
I have a very similar problem. But in my case it affects all keys (I tried). But there is different behaviour in the different desktop environments. In the login-manager (gdm) pressing a key longer does not work, when logged into gnome-2.24.1 it works. Logged in to kde:live it does not work. Downgrading to xf86-input-evdev-2.1.3 fixed the problem for me.
This issue has been fixed in xf86-input-evdev git master with commit a7fb654a68a26ad5f019a902312c6b94dbe9c3ea ( http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=a7fb654a68a26ad5f019a902312c6b94dbe9c3ea)
Created attachment 184569 [details] xf86-input-evdev-2.2.0-r1.ebuild new ebuild with patch
Created attachment 184571 [details, diff] files/2.2.0-fix-repeat-filtering.patch the actual patch from git master
Fixed in 2.2.0-r1 before I even saw this bug. =)
*** Bug 262044 has been marked as a duplicate of this bug. ***
*** Bug 262066 has been marked as a duplicate of this bug. ***
*** Bug 262090 has been marked as a duplicate of this bug. ***
I suggest reopening this bug because it happens again with xorg-server-1.6*. The patch just solves incompability between the new evdev-2.2* and old xorg-server-1.5*. In fact with evdev-2.2* and xorg-server-1.6* hardware autorepeat is completely disabled and software autorepeater is used instead (in order to disable autorepeat selectively for modifier keys I guess). But when using evdev, the Left Arrow, Down Arrow and End keys have software autorepeat disabled by default, which seems to be bug in XKB configuration (I suspect the keycodes are mistakenly considered modifiers). There is a simple workaround - just turn the software autorepeat on for the keys: xset r 113 xset r 115 xset r 116 For more details consult also the upstream bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=17925. I can reproduce the bug with the following configuration: x11-base/xorg-server-1.6.1.901-r3 x11-drivers/xf86-input-evdev no hal xorg.conf: ... Section "InputDevice" Identifier "keyboard2" Driver "evdev" Option "Device" "/dev/input/by-id/usb- ... event-kbd" Option "XkbLayout" "us,cz,sk" Option "XkbVariant" ",qwerty,qwerty" Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll" EndSection ...
Confirming above, xorg-server-1.6, all evdev versions above 2.2 (including GIT one), no hal. Of course, reversing above patch doesn't help.
Can you reproduce the bug with a simpler configuration, US QWERTY for instance? Thanks
(In reply to comment #13) > Can you reproduce the bug with a simpler configuration, US QWERTY for instance? Yes, same thing. I also removed .Xmodmap, still no success.
Please file a bug in FreeDesktop's bugzilla [1] and paste the url here. Thanks [1] https://bugs.freedesktop.org
(In reply to comment #15) > Please file a bug in FreeDesktop's bugzilla [1] and paste the url here. Haven't you seen #c11? zimous has already provided the URL and detailed explanation but neither of us can modify the bug info.
I've CCed myself on the upstream bug, let's track it there directly. Thanks
Ok, I'm almost sure that this is xorg-server/xkb bug, not evdev one. Removing #if/#endif from code mentioned in above patch fixes the issue but as far as I understand it, this moves autorepeat control back to evdev. Moreover, it looks like xorg is loading all the rules correctly (both when XkbRules is set to evdev in xorg.conf and when it is set to other value and evdev replaces it). I'm still working on understanding the xkb code but the first thought is that xorg is setting the autorepeat before loading keymaps.
As I noticed in the upstream bugzilla, the keycodes 113, 115 and 116 assigned to Left, Down and End when using evdev, are asigned to RALT, RWIN and LWIN (modifiers!) when using kbd and not evdev. Hence I think the problem lies somewhere in /usr/share/X11/xkb/* --- by mistakenly including some kbd- and non evdev-aware file, the autorepeat is turned off like for the modifiers. Unfortunately I have no time to examine these files in more detail at the moment.
(In reply to comment #19) > As I noticed in the upstream bugzilla, the keycodes 113, 115 and 116 assigned > to Left, Down and End when using evdev, are asigned to RALT, RWIN and LWIN > (modifiers!) when using kbd and not evdev. Hence I think the problem lies > somewhere in /usr/share/X11/xkb/* --- by mistakenly including some kbd- and non > evdev-aware file, the autorepeat is turned off like for the modifiers. > Unfortunately I have no time to examine these files in more detail at the > moment. I can't agree with you although I'm not a specialist on xkb. AFAICS there are no other occurences of these keycodes than in keycodes/ (everything else uses keynames). As evdev sets correct keycode file and these keys are recognized correctly with normal work (which proves that rules are loaded), I think the bug is somewhere within Xserver or even xkbcomp. It looks like Xorg is setting all the repeat rules before it loads the correct keycodes. If you take a look at xev you may also notice that for example right alt key repeats while left does not, so rather Xorg doesn't even try to reset repeats after loading new maps.
