xset -r causes loss of control of keyboard

Bug #367136 reported by John Parchem on 2009-04-26
This bug affects 10 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
X.Org X server
Fix Released
gnome-settings-daemon (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

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.

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 .

Bryce Harrington (bryce) on 2009-04-28
affects: xorg (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
jujube (jujubetc) wrote :

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) wrote :

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

Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Confirmed
K Runge (ubuntuforums) wrote :

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) wrote :

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?

Changed in xserver-xorg-input-evdev (Ubuntu):
importance: Undecided → Medium
affects: xserver-xorg-input-evdev (Ubuntu) → xorg-server (Ubuntu)
Saivann Carignan (oxmosys) wrote :

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) wrote :

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

PsYcHoK9 (psychok9) wrote :

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

Changed in xorg-server:
status: Unknown → Confirmed
Andrew (andrew-rw-robinson) wrote :

Can we bump up the severity on this bug?

I reported this bug:

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

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

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 :

Can a Xorg developer confirm this?

Saivann Carignan (oxmosys) wrote :

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

affects: xorg-server (Ubuntu) → gnome-settings-daemon (Ubuntu)
Changed in gnome-settings-daemon:
status: Unknown → New
Changed in gnome-settings-daemon (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Medium → Low
status: Confirmed → Triaged
ragtag (ragtag) wrote :

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) wrote :

thank you very much! maya is working again smoothly

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) wrote :

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) wrote :

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


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

disable this option.

kit (kitrule) wrote :

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) wrote :

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.

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

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

Therefore it seems to be fixed.

Saivann Carignan (oxmosys) wrote :

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

Changed in gnome-settings-daemon (Ubuntu):
status: Triaged → Fix Released

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.

Changed in xorg-server:
status: Confirmed → Fix Released
Changed in xorg-server:
importance: Unknown → Medium
Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: New → Unknown
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium

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

To post a comment you must log in.
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.