xset -r causes loss of control of keyboard

[John Parchem]

Binary package hint: xorg

Using Ubuntu 9.04 64-Bit.

"xset -r" or "xset r off" (see man xset) is a command which is supposed to turn off the keyboard repeat. However, when I run this in Ubuntu 9.04 64-bit, it causes an endless stream of enter key inputs instead (as if you just held down the enter key). I've tried this on two different machines with the same results. Here are the steps to reproduce:

1) Open two terminal windows

2) In the first terminal window, enter "xset r" (no quotes) but don't hit the enter key yet. You'll need this command already typed in to gain control of the keyboard later when the X server goes into a loop of enter keys making typing of commands in the terminal at that point otherwise impossible.

3) In the second terminal window, enter "xset -r" (no quotes) and hit the enter key. Observe that instead of the repeat being turned off for the keyboard, a steady rapid stream of enter keypresses occur which makes typing into anything impossible because the enter keystrokes are interfering with whatever you are typing.

4) Now go back to the first terminal window and press enter to execute the command "xset r" which will turn the repeat back on. At this point, you should have regained control of keyboard input again.

[Xarax-fd (xarax-fd)]

After upgrading from Ubuntu 8.10 to 9.04, i.e from Xorg server version 1.5.2 to 1.6.0, I started having problems with 'stuck keys'. I mean a key stuck in autorepeat mode as if the key was being pressed constantly, even if it was released normally. This happened randomly with different applications and different keys, but most often when entering VMWare remote consoles.

When I tried to set autorepeat off, I noticed that in fact the problem is triggered by the command

  $ xset r off

When the command is typed (e.g. in a gnome-terminal or xterm) and Enter pressed, the Enter key starts repeating. A different variation is

  $ read; xset r off

When this command is typed, Enter pressed and then Ctrl-D pressed (to terminate the read), the 'd' key starts repeating. However, if I do

  $ sleep 1; xset r off

no key starts repeating. So it seems that when the autorepeat function is turned off, the last key pressed starts repeating if it was pressed within a sufficiently short interval before turning autorepeat off.

My normal autorepeat setting is delay 500, rate 30. When a key gets stuck and starts repeating, the way I can recover is to set a slow autorepeat rate, typcially I use 'xset r rate 500 3'. Then the next key press stops the repeating. Doing 'xset r off' does not help.

I reported this problem yesterday in Ubuntu's bug tracker under issue #124406, which has a long comment history of possibly related problems with stuck keys. See https://bugs.launchpad.net/ubuntu/jaunty/+source/linux/+bug/124406/comments/235 .

[jujube (jujubetc)]

I'm having the same problem with Ubuntu 9.04 32-bit. There are a couple workarounds:

1. Disable autorepeat in System->Preferences->Keyboard.

2. Run a script which contains the command "xset r off".

[PhilippeDePass (depassp)]

I am also seeing this behaviour, using Ubuntu 9.04 (jaunty) amd64.

My keyboard is a Logitech G15, and is configured as so under Keyboard Preferences -> Layouts.

Disabling autorepeat in System->Preferences->Keyboard _does_ work, however.
Running a script with "xset r off" or "xset -r" also produces the bug (endless stream of the enter key).

[Runge (runge)]

See also the discussion at:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/367136

[K Runge (ubuntuforums)]

We are seeing this problem with x11vnc too.

x11vnc toggles the X server key autorepeating in exactly the same way that xset(1) does: it uses the XChangeKeyboardControl() interface.

Details here: http://ubuntuforums.org/showthread.php?t=1125694&highlight=x11vnc

[Saivann Carignan (oxmosys)]

I'm pretty interested to help identifying the source of the problem. I verified and the problem does not seem to belong to xserver-xorg-input-evdev as downgrading that package to the one in intrepid is not enough to make the bug disappear. Does anyone has a idea in which project this bug can belong to? xserver-xorg-core itself?

[Saivann Carignan (oxmosys)]

I built 1.3.0 , 1.6.0 and 1.6.1 xserver-xorg-core on intrepid and I was never able to reproduce the bug.
I built the same 1.6.0 xserver-xorg-core on jaunty and I was still able to reproduce the bug.

That seems to demonstrate that xserver-xorg-core is not the faulty package either. Any other idea about what package could be the cause?

[Saivann Carignan (oxmosys)]

Not linux kernel either, downgrading to intrepid kernel does not change anything.

[PsYcHoK9 (psychok9)]

Same bug here.
Jaunty 64 bit, and kernel 2.6.30-020630rc5-generic.

[Andrew (andrew-rw-robinson)]

Can we bump up the severity on this bug?

I reported this bug:
https://bugs.launchpad.net/ubuntu/+source/libvncserver/+bug/379459

But apparently this is the real problem. It is killing me with x11vnc

[Freedesktop-bugzilla (freedesktop-bugzilla)]

xtrs (http://tim-mann.org/xtrs.html) is being victimized by this bug too. xtrs does not want X key repeat, so when the mouse enters the xtrs window, xtrs remembers the current state of key repeat and turns it off. It then restores the previous key repeat state when the mouse leaves the window or you exit from xtrs. I've gotten various keys to repeat infinitely when typing and moving the mouse in and out of the xtrs window.

I notice in the Ubuntu discussion that x11vnc and VMware Workstation are also affected, probably for the same reason -- they don't want X key repeat and thus turn it off automatically at certain times.

[Saivann Carignan (oxmosys)]

This bug is still confirmed on karmic.

Andrew : We could bumb the importance but that won't help the bug to get fixed faster. Medium seems appropriate. What we need to fix this issue is more relevant information about what is really causing this issue and since when.

[Xavier Aragon (xarax-lp)]

I started having this problem after upgrading from Intrepid to Jaunty. At that time I was using the default GNOME desktop.

However, the problem disappeared when I installed the kubuntu-desktop package and starting using KDE desktop. I'm not able to reproduce the endless repeat behavior any more with 'xset r off' or by entering VMWare consoles, which both triggered the problem while using GNOME desktop.

So I'm wondering if the source of the problem could have something to do with GNOME / GTK. Has anybody observed this problem while using KDE desktop, or can we confirm that it only occurs with GNOME ?

[lemmy (lemmyg)]

I have the same problem with Gnome in Jaunty. The curious is that in KDE and Xfce does not appear.
So I don´t think is a Xorg problem.

[Saivann Carignan (oxmosys)]

Thanks for this great discovery! That is a very helpful information that I was able to confirm. We now need to identify which GNOME component is causing the bug in order to understand the real cause and how to fix it.

[John Parchem (jparchem838)]

Also, in Ubuntu 9.04 64 bit if you turn off key repeat entirely in System --> Preferences --> Keyboard the problem doesn't occur (although you don't have key repeats anymore either).

[lemmy (lemmyg)]

Hi,
I found something that can help. If you start gnome session with gnome-settings-daemon disabled, You can run xset r off smoothly.

[Saivann Carignan (oxmosys)]

According to comment in ubuntu bug report : https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/367136

This problem is only reproducible with gnome-settings-daemon, therefore maybe not a Xorg issue. The upstream bug is there :
http://bugzilla.gnome.org/show_bug.cgi?id=587229

Can a Xorg developer confirm this?

[Saivann Carignan (oxmosys)]

lemmy : Thank you very much for this great discovery! This allowed me to find the upstream bug report at GNOME and to try a git bisect and to give more information to the developers. http://bugzilla.gnome.org/show_bug.cgi?id=587229

[ragtag (ragtag)]

This bug seems to be with a11y-keyboard. We were having problems with it in Ubuntu 9.04 64bit, running Maya (same as Bug #392746 ). Disabling the a11y-keyboard plug-in with gconf-editor seems to make this bug go away.

[tempo500 (philip-ballinger)]

thank you very much! maya is working again smoothly

[Saivann Carignan (oxmosys)]

It really is a xserver-xorg bug, as updating xorg from 1.5.2 to 1.6.0 in ubuntu intrepid makes the bug appear (under GNOME only with gnome-settings-demon enabled and with his a11y-keyboard plugin enabled)

[John (jspatrick)]

I'm also having the issue within Maya. Ragtag - would you mind explaining how to disable this? I'm a bit new to Maya/Linux but would greatly appreciate having Maya working under Ubuntu!

[lemmy (lemmyg)]

Hi,
to disable the problem , you have open terminal and execute:

gconf-gnome

then go to section app -> gnome-setting-deamon -> plugins -> a11y-keyboard

disable this option.

[kit (kitrule)]

I couldn't run gconf-editor (gconf-gnome) on the host whilst this bug was occuring, so i used the following commands via a ssh:

gconftool -t bool -s /apps/gnome_settings_daemon/plugins/a11y-keyboard/active false
sudo gconftool -t bool -s /apps/gnome_settings_daemon/plugins/a11y-keyboard/active false
sudo restart gdm

^using karmic. try "sudo /etc/init.d/gdm restart" in place of the last line if it doesn't work on jaunty.
(subscribing to this bug so i remember to change back if/when it's fixed. thanks)

[jpalko (jpalko)]

Nice, setting the /apps/gnome_settings_daemon/plugins/a11y-keyboard/active to false fixed my problems with wine software and I could finally run "xset r off".

Fully updated karmic x86_64 system with backports and proposed (plus some misc other repositories including nvidia ppa for one) enabled.

[Saivann Carignan (oxmosys)]

The bug is gone in Ubuntu 10.04 alpha 2 with these packages :

xserver-xorg-core 2:1.7.3.902-1ubuntu5
gnome-settings-daemon 2.28.1-1ubuntu2

Therefore it seems to be fixed.

[Saivann Carignan (oxmosys)]

Good news, this problem is fixed in Lucid. According to this, I'm changing bug status to Fix Released.

[Peter Hutterer (peter-hutterer)]

i can reproduce the bug in F-11 (with server 1.6) but not in F-12 (server 1.7). XKB had a pretty massive cleanup between the two and finding the exact fix is tricky (bfb219f532f3c78ba905424365ee7c5f7b5f21a2 might be it though). Backporting the fix is probably quite time-consuming so unless someone volunteers to do so for the 1.6 branch, this one is unlikely to get fixed in 1.6.

I'm closing this bug as FIXED, since 1.7 and git don't suffer from this problem.

[Pedro J. Martinez (pedrojmartm)]

Thanks, but this its not a fix, this is a temporal solution. I am using Ubuntu 16.04 and the bug still in it!