Keybord gets sluggish after a while (after upgrade from 11.10 to 12.04)

[Geir Isene]

Hardware: Lenovo X200 laptop
OS: Ubuntu 12.04

Bug occured after upgrading from 11.10 to 12.04

Bug:

Originally reported a few weeks ago here: http://ubuntuforums.org/showthread.php?p=11869633

Short recap:

At a random time after login (never less than half an hour so far), approximately once every other day (after upgrading 6 weeks ago), the keyboard stops responding as usual. It seems that the initial keypress is disregarded, but key registers after the repeat-interval and then repeats as usual - i.e. I press a key and wait and the key registers and repeats just as it would before the bug appears except the first keypress is not registered. I cannot trigger this bug "at will", and I see no traces of errors in any error log.
---
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
DistUpgraded: 2012-04-12 13:02:14,469 DEBUG enabling apt cron job
DistroCodename: precise
DistroRelease: Ubuntu 12.04
DistroVariant: ubuntu
MachineType: LENOVO 7455D7G
Package: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/zsh
ProcKernelCmdLine: root=UUID=7d09fa0a-8d28-4a02-8acb-abc193a646e3 ro quiet splash
ProcVersionSignature: Ubuntu 3.2.0-24.38-generic 3.2.16
Tags: precise ubuntu
Uname: Linux 3.2.0-24-generic x86_64
UpgradeStatus: Upgraded to precise on 2012-04-12 (27 days ago)
UserGroups: adm admin audio cdrom frost fuse lpadmin netdev plugdev sambashare video
dmi.bios.date: 11/10/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 6DET61WW (3.11 )
dmi.board.name: 7455D7G
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6DET61WW(3.11):bd11/10/2009:svnLENOVO:pn7455D7G:pvrThinkPadX200:rvnLENOVO:rn7455D7G:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7455D7G
dmi.product.version: ThinkPad X200
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.7.8-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu35
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.19.0-0ubuntu1~xup1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/996801/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Geir Isene (qc-e-9h)]

I do not know what source package this bug pertains to - but it seems to be an X issue. When I restart X, it is gone. When I exit to a console, it is not there. What part of X, though, I don't know. It seems very unlikely that it is related to my WM (i3), as the chance that the user who first reported this bug also uses i3 is slim at best. The common denominator between that user an me is the x2oo laptop and X under 12.04.

[Geir Isene (qc-e-9h)]

BTW; The source package won't let me choose X in general - as any of the main searches for X returns too many hits), I revert to classify this as an X-bug related to some driver for Lenovo X200.

[Fabio Marconi (fabiomarconi)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please run the command 'apport-collect 996801' which will attach necessary information for debugging this as an Xorg problem. Thanks in advance.

[Fabio Marconi (fabiomarconi)]

Can also be useful verify you memory, doing:
https://help.ubuntu.com/community/MemoryTest
And take a look at:
https://wiki.ubuntu.com/DebuggingKeyboardDetection
To collect useful information.
Thanks
Fabio
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

apport information

[Geir Isene (qc-e-9h)]

The command:

xprop -root | grep XKB > ~/xkb

...produces:

_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "no", "", "terminate:ctrl_alt_bksp,lv3:ralt_switch"

...while the command:

gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd > ~/gconf

...produces nothing

[Geir Isene (qc-e-9h)]

Specification; When the bug occurs, I can press any key and hold it, and it registers after it would normally start repeating. (But it doesn't start repeating until yet another such interval - half a second or so). Makes for realllly slow typing, this :)

[Jonathan Nieder (jrnieder)]

Hi,

As described at <http://bugs.debian.org/677173> and
<https://bugzilla.redhat.com/816764>, some users accidentally
holding down shift too long end up pressing some other modifiers and
then are confused when applications stop accepting input. Restarting
the X server fixes it, as does holding down shift again if you know to
do so.

Some people reporting running into this scenario:

 Vincent Lefevre
 Wookey
 Bjørn Mork

They are bright people, and if they find this counterintuitive, I expect
many others will as well. A common way to run into this is to hold down
shift while performing some action with the mouse that takes at least
10 seconds.

Julien Cristau pointed reporters to the blog entry

 http://who-t.blogspot.fr/2012/06/xkb-slowkeys.html

so it looks like this usability problem is known, but there doesn't seem
to be a bug filed for it.

Of course, fixing it is tricky. The same annoying keyboard shortcut is
used on Windows, although there the result is an annoying dialog box
popping up instead of the keyboard seeming to just stop working. (I don't
suggest copying that. :)) Making sure this feature remains discoverable
might require some coordination with Desktop Environment authors, to put
an appropriate entry in a keyboard layout switcher on the panel, for
example (sorry, I'm out of touch with the DE world).

Of course, as long as the education problem is solved somehow, the
appropriate fix on the X side is obvious. The keyboard shortcut needs
to be harder to accidentally trip. Perhaps it could be made configurable
to allow people to experiment to find a good one.

Sorry for the ramble, and hope that helps,
Jonathan

[Jonathan Nieder (jrnieder)]

(In reply to comment #0)
> As described at <http://bugs.debian.org/677173> and
> <https://bugzilla.redhat.com/816764>, some users accidentally
> holding down shift too long end up pressing some other modifiers and
> the

Um, I mixed up Sticky Keys and Slow Keys, sorry. So modifiers are not
involved --- the point is that the keyboard really does stop accepting
normal input unless you hold down each key for a while.

Another quick datum: on Mac OS X, holding down the Return key for
4 seconds produces a beep. Continuing to hold it for 4 more seconds
turns on Slow Keys. Enter seems like a less common key to hold down
than Shift and the beep provides useful feedback, so one nice approach
might be to copy them.

[Alan Coopersmith (alan-coopersmith)]

(In reply to comment #0)
> the appropriate fix on the X side is obvious. The keyboard shortcut needs
> to be harder to accidentally trip.

Unfortunately, that's rather inappropriate for reasons that should also be
obvious - making it harder to activate makes it harder for the people who
need this functionality (because they have motor control issues with their
hands) to enable it on their own.

I absolutely agree that the desktop environments should provide more feedback
and notification here, as I've had to help a number of people who hit this
and had no idea why, but we can't change that in the X server.

[Jonathan Nieder (jrnieder)]

(In reply to comment #2)
> (In reply to comment #0)

>> the appropriate fix on the X side is obvious. The keyboard shortcut needs
>> to be harder to accidentally trip.
>
> Unfortunately, that's rather inappropriate for reasons that should also be
> obvious - making it harder to activate makes it harder for the people who
> need this functionality

Perhaps you missed the word "accidentally" and the example of using
the "enter" key instead of shift.

[Vincent-fdt (vincent-fdt)]

(In reply to comment #2)
> I absolutely agree that the desktop environments should provide more feedback
> and notification here,

Not everyone uses a desktop environment. But perhaps the feature [of activating SlowKeys by holding Shift for 8 seconds] should not be enabled by the X server by default, but only by desktop environments if they can provide the notification (and a way to inform the user how to disable the feature and to silent the notification).

Using Enter instead of Shift would not be a solution, because one may hold Enter to insert many blank lines, to scroll (e.g. in less) or whatever.

However you should probably not activate SlowKeys if Shift is used with a combination of mouse operations.

[Jonathan Nieder (jrnieder)]

(In reply to comment #4)
> Using Enter instead of Shift would not be a solution, because one may hold
> Enter to insert many blank lines, to scroll (e.g. in less) or whatever.

Do you disagree that it would be much, much better than Shift, at least?

Do you have an alternative to suggest?

> However you should probably not activate SlowKeys if Shift is used with a
> combination of mouse operations.

If someone can come up with a good heuristic for this, it would be nice,
but it seems somewhat complex to distinguish between accidental mouse
operations (e.g., ordinary mouse motion, which this heuristic would need
to ignore) and intentional ones.

Thanks,
Jonathan

[Vincent-fdt (vincent-fdt)]

(In reply to comment #5)
> (In reply to comment #4)
> > Using Enter instead of Shift would not be a solution, because one may hold
> > Enter to insert many blank lines, to scroll (e.g. in less) or whatever.
>
> Do you disagree that it would be much, much better than Shift, at least?

It depends on whether the test with Shift can be improved. If Shift + mouse operations no longer activates SlowKeys, the use of Shift may become better.

> Do you have an alternative to suggest?

The ISO_Level3_Shift key (generally the AltGr physical key)? AFAIK, it is never used with a mouse combination.

Or the CapsLock key (it doesn't make sense to keep it pressed).

> If someone can come up with a good heuristic for this, it would be nice,
> but it seems somewhat complex to distinguish between accidental mouse
> operations (e.g., ordinary mouse motion, which this heuristic would need
> to ignore) and intentional ones.

If the goal is to activate SlowKeys, the user could be careful not to touch the mouse (there may still be a problem if the mouse is very sensible so that the mouse pointer can move by itself, but I suppose that persons who need SlowKeys do not have such a mouse, as a very sensitive mouse is harder to use without minimal skills).

[Alan Coopersmith (alan-coopersmith)]

(In reply to comment #5)
> Do you disagree that it would be much, much better than Shift, at least?

One advantage of Shift is that pressing it is unlikely to cause text entry
to occur or applications to take any actions during the period it's being
held down.

(In reply to comment #6)
> It depends on whether the test with Shift can be improved. If Shift + mouse
> operations no longer activates SlowKeys, the use of Shift may become better.

That seems reasonable to me, though I'd want to run by accessibility experts
first.

[Peter-korn-k (peter-korn-k)]

[I'm one of the "accessibility experts" that Alan wanted to run this by...]

Use of the shift key has been the standard for a long time across all desktop environments; why Mac OS is now reportedly using the <Return> key now is something I can't speak to at this time.

Given the nature of the disabilities that need SlowKeys, requiring that there be no mouse movement for the entire 8 seconds that Shift is held down seems fine - I don't believe this will negatively impact anyone who needs SlowKeys.

Shifting (pardon the pun) to having desktop environments explicitly turn this on and explicitly provide UI for it (e.g. when held down pop up a confirmation dialog box) also seems like a fine change. I would only be concerned about getting the timing & coordination right for that, so that we don't harm users who need this during a transition to a new model for the roles that the various components are playing.

I think it would be a mistake to require a longer duration of holding down the key. I think it would be a mistake to move to a different key - particularly something that may not be on all keyboards.

I am concerned about emitting a tone at 4 seconds with activation at 8 seconds, for the simple reason that users might erroneously think 4 seconds was enough to activate. But as there are (far) fewer users who need this compared to the general population, this would be a relatively easier education task. BUT... shifting this to the desktop environment's responsibility for UI notification is probably the better way to go; a beep is more easily missed (in both directions) than a dialog box appearing that explains what is going on.

[Vincent-fdt (vincent-fdt)]

(In reply to comment #8)
> I am concerned about emitting a tone at 4 seconds with activation at 8 seconds,
> for the simple reason that users might erroneously think 4 seconds was enough
> to activate.

A tone would be completely useless for me, unless that's a "visual tone" (the speakers are off most of the time). But if it has to be something visual, it should be something informative.

> But as there are (far) fewer users who need this compared to the
> general population, this would be a relatively easier education task. BUT...
> shifting this to the desktop environment's responsibility for UI notification
> is probably the better way to go; a beep is more easily missed (in both
> directions) than a dialog box appearing that explains what is going on.

Yes, exactly. But the information should be available even if one doesn't use a desktop environment (just a window manager), or you should shift the entire feature to the desktop environment.

[Richard Jones (rjones-redhat)]

It seems obvious to me this mis-feature should be disabled
by default in the X server, and only "desktop environments"
that have the infrastructure to displays notifications
should enable it.

[dkg (dkg0)]

I hit this issue today, and i'm pretty sure that i did *not* actually hold down shift for more than 10 seconds. Quite possibly, i held down shift for a couple seconds, and while i did so, there was a successful keyboard grab from an XClient.

at any rate, it seems like it might be possible to miss the shift release event.

[Daniel Stone (daniels)]

(In reply to comment #10)
> It seems obvious to me this mis-feature should be disabled
> by default in the X server, and only "desktop environments"
> that have the infrastructure to displays notifications
> should enable it.

It seems extremely obvious to me that this accessibility requirement should not be disabled by default.

OTOH, it also seems obvious that it should be fixed to take mouse motion into account, and not trigger if there's been any substantial input activity while it's down.

The patch should be reasonably simple, to wrap mouse events similarly to xkb/xkbPrKeyEv.c's ProcessKeyboardEvent, and pass them through to the AccessX code, which would then cancel any pending AccessX events if mouse activity is detected.

[Vincent-fdt (vincent-fdt)]

(In reply to comment #12)
> It seems extremely obvious to me that this accessibility requirement should not
> be disabled by default.

It may be obvious for "desktop environments". But I would have thought that the users of this accessibility feature (mis-feature for those who don't need it) always are under a desktop environment, so that it would be fine to disable it by default everywhere else. I'd like to hear how this feature is used in practice (when, how often, etc.). Wouldn't the system be able to guess whether SlowKeys should be activated or not when Shift is held for 8 seconds (i.e. whether it is intended to activate SlowKeys or not)?

It seems that I sometimes hold Shift without doing anything else, just because I intend to type PageUp/PageDown once I've finished to read text. So, fixing the problem for mouse actions would not be sufficient. IMHO, SlowKeys shouldn't be activated in the case another key is pressed while Shift is still held, i.e. SlowKeys could be activated at the Shift Key Release event if pressed for at least 8 seconds (not once the 8 seconds have elapsed like now), only when another key hasn't been pressed and the mouse hasn't been used between the key press and the key release.

[Micah Anderson (micah-debian)]

I'm a bit puzzled because I too ran into this issue a couple weeks ago, and so did two others that I know who are running Debian. The fact that several people have been hit by this in such a short time seemed coincidental to me, and then I found the Debian bug report, and saw that other people that I know were also recently hit by this. In my case, I'm embarrassed to say that it took me *two weeks* before someone else who ran into this suggested it might be SlowKeys and I was able to then resolve the issue. I had resigned myself that my laptop keyboard had broken again, as it has now several times in the last two years, and had plugged in a USB keyboard to work around it.

I dont know how long this accessibility feature has existed in X, nor do I remember how long I've been using X (at least a decade).... never in that time have I accidentally triggered this.

I think its a good feature, and would not encourage its removal. Changing the key to be something less likely to be pressed might be a good solution, but presents transition problems. I do see how indicating to the user that this has been activated is a problem with the proliferation of different window managers, I also applaud the recent inclusion in the log that this has been triggered. But, boy it sucks when this gets enabled and you have no idea.

[Jonathan Nieder (jrnieder)]

(In reply to comment #14)
> I'm a bit puzzled because I too ran into this issue a couple weeks ago, and so
> did two others that I know who are running Debian. The fact that several people
> have been hit by this in such a short time seemed coincidental to me

gdm3 turns the AccessX bit on. Then it remains enabled after you log in, even if the resulting environment doesn't know how to cope with that.

After http://patchwork.freedesktop.org/patch/10795/ desktop environments should be able to more easily notice that Slow Keys has been enabled and throw up a popup. The discussion here has focused on how to avoid spuriously enabling Slow Keys in the first place, which seems useful because when such a popup appears it is still an interuption to work and a usability problem.

[Geir Isene (qc-e-9h)]

Update: This is not a problem local to the Lenovo X200.

I have changed to a Samsung Series 9 laptop, and the problem showed up also here.

[Geir Isene (qc-e-9h)]

So far, my conclusion is that something in xserver-xorg-input-evdev (?) was changed from 11.10 to 12.04 that causes this sporadic behavior.

Now, if anyone could supply a temporary workaround for this bug, it would be highly appreciated - like reloading a module or some such.

[Geir Isene (qc-e-9h)]

Here's the clue to a solution for this (mentioned by "chrysn" over at the Xorg IRC channel. The issue is triggered by pressing and holding the shift key for 8s. Again pressing and holding the shift key for another 8s resolves the issue. Odd.

[Alan Coopersmith (alan-coopersmith)]

Holding the shift key for 8 seconds enables the SlowKeys
accessibility feature for users who need it.

If you never need it, the GNOME Keyboard Preferences should allow you to
disable keyboard shortcuts for enabling accessibility features.

More details may be found in the upstream enhancement request:
https://bugs.freedesktop.org/show_bug.cgi?id=52611

[Vincent-fdt (vincent-fdt)]

A few minutes ago, the system switched to SlowKeys while I didn't even touch the Shift key!

Note: It sometimes happens that I unintentionally hold the Shift key for 8+ seconds (e.g. because I intend to type PageUp or PageDown, but don't do it immediately). In such a case, a message is written to the /var/log/Xorg.0.log file. But here, nothing was written!

Here are the last messages in the /var/log/Xorg.0.log file:

[778009.172] (II) XKB SlowKeys are now enabled. Hold shift to disable.
[870684.606] (II) XKB SlowKeys are disabled.
[870684.620] (II) XKB SlowKeys are now enabled. Hold shift to disable.
[870793.988] (II) XKB SlowKeys are now enabled. Hold shift to disable.
[870793.988] (II) XKB SlowKeys are disabled.
[970681.038] (II) XKB SlowKeys are disabled.
[970681.101] (II) XKB SlowKeys are now enabled. Hold shift to disable.
[970710.197] (II) XKB SlowKeys are now enabled. Hold shift to disable.
[970710.198] (II) XKB SlowKeys are disabled.
[970782.228] (II) config/udev: removing device USB OPTICAL MOUSE
[970782.519] (II) evdev: USB OPTICAL MOUSE: Close
[970782.641] (II) UnloadModule: "evdev"
[970783.017] (II) config/udev: Adding input device USB OPTICAL MOUSE (/dev/input/mouse0)
[970783.056] (II) No input driver specified, ignoring this device.
[970783.056] (II) This device may have been added with another device file.
[970783.056] (II) config/udev: Adding input device USB OPTICAL MOUSE (/dev/input/event3)
[970783.056] (**) USB OPTICAL MOUSE: Applying InputClass "evdev pointer catchall"
[970783.056] (II) Using input driver 'evdev' for ' USB OPTICAL MOUSE'
[970783.056] Option "XkbRules" "evdev"
[970783.056] Option "XkbModel" "evdev"
[970783.056] Option "XkbLayout" "us"
[970783.056] Option "_source" "server/udev"
[970783.056] Option "name" " USB OPTICAL MOUSE"
[970783.056] Option "path" "/dev/input/event3"
[970783.056] Option "device" "/dev/input/event3"
[970783.056] Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-3/8-3.3/8-3.3:1.0/input/input19/event3"
[970783.056] Option "driver" "evdev"
[970783.056] (**) USB OPTICAL MOUSE: always reports core events
[970783.056] (**) evdev: USB OPTICAL MOUSE: Device: "/dev/input/event3"
[970783.057] (--) evdev: USB OPTICAL MOUSE: Vendor 0x15d9 Product 0xa4c
[970783.057] (--) evdev: USB OPTICAL MOUSE: Found 3 mouse buttons
[970783.057] (--) evdev: USB OPTICAL MOUSE: Found scroll wheel(s)
[970783.057] (--) evdev: USB OPTICAL MOUSE: Found relative axes
[970783.057] (--) evdev: USB OPTICAL MOUSE: Found x and y relative axes
[970783.057] (II) evdev: USB OPTICAL MOUSE: Configuring as mouse
[970783.057] (II) evdev: USB OPTICAL MOUSE: Adding scrollwheel support
[970783.057] (**) evdev: USB OPTICAL MOUSE: YAxisMapping: buttons 4 and 5
[970783.057] (**) evdev: USB OPTICAL MOUSE: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[970783.057] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-3/8-3.3/8-3.3:1.0/input/input19/event3"
[970783.057] (II) XINPUT: Adding extended input device " USB OPTICAL MOUSE" (type: MOUSE, id 12)
[970783.057] (II) evdev: USB OPTICAL MOUSE: initialized for relative axes.
[970...

[Anarcat-8 (anarcat-8)]

I was also bitten by this since I upgraded my Debian install to Wheezy, which means something happened between Xorg 7.5 and 7.7.

I do not use gnome, I do not use KDE, in fact I do not consider I use a "desktop environment" most of the time, the main exception being "gnome-settings" that is started during my session. I notable have *disabled* the slow keys shortcut in gnome-settings, so I do not expect this to happen at all. I can confirm, however, that the following workaround works:

    gsettings set org.gnome.desktop.a11y.keyboard enable false

... but only if you are running "gnome-settings". Oh, and this bug manifests itself in non-GNOME sessions only if you run GDM, which enables accessibility features before your X session starts.

I can also note that I cannot reproduce this with a USB keyboard, which seems at the very least inconsistent.

I can also corroborate with other reports of this being triggered randomly, that is: I did not hold the shift key for 10 seconds - but maybe a serie of different keys were held down in a total of 10 seconds.

As others here, I have thought that my keyboard was broken. I had to reboot my laptop a few times until a friend that was sitting next to me explained what happened. The fact that a line is now written in Xorg.0.log is useful, but will *never* be useful to most of the users out there - in fact I never thought of looking there until I found this bug report.

I do not understand why this feature is there, or how i can be considered an "accessibility" feature. From my point of view, it makes the whole graphical interface a lot *less* usable, as it means that, without any explanation, your laptop's keyboard may stop working completely. I would like to understand what purpose it serves and while I do not object to the feature being present, I'd like to be able to turn this thing off, at the very least.

[Anarcat-8 (anarcat-8)]

To clarify my last comment here:

I had the setting disabled in my gnome-control-center, but because gnome-settings is not running, it's not taking effect.

So in a way, as soon as you run gdm3, you are *forced* to run gnome (or more precisely gnome-settings) to make sure you can disable that setting, otherwise it stays turned on and there is no way to disable that behavior.

[WillDyson (will-dyson)]

This bug bit me today. Although I am using the latest X server from Debian Sid, there was no line in Xorg.0.log notifying me that SlowKeys had been enabled.

I am using Gnome, where keyboard accessability is disabled.

$ gsettings get org.gnome.desktop.a11y.keyboard enable
false

Toggling SlowKeys on and back off in Gnome did not disable the behavior. Only holding down the shift key (after doing research to find this bug) could disable it.

Some of these issues are the fault of Gnome, but it seems there is some path to enabling SlowKeys that does not result in a log entry or notification of the desktop environment.

[Vincent-fdt (vincent-fdt)]

(In reply to comment #19)
> This bug bit me today. Although I am using the latest X server from Debian
> Sid, there was no line in Xorg.0.log notifying me that SlowKeys had been
> enabled.

So, like what happened to me in comment #16 (I also use Debian/sid, but not GNOME).

[Rolf Leggewie (r0lf)]

Is this problem coupled with a high utilization of CPU by Xorg?

[Rolf Leggewie (r0lf)]

Is this problem coupled with a high utilization of CPU by Xorg?

[Rolf Leggewie (r0lf)]

We're closing this bug since it is has been some time with no response from the original bug reporter. However, if the issue still exists in the latest development version of Ubuntu and you are the original reporter please feel free to reopen with the requested information. If you are not the original reporter, please don't reopen this one but instead file a new bug and reference this one.

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/303.