Bug 816764

Summary: Slow keys turned itself on (keyboard "died")
Product: [Fedora] Fedora Reporter: Richard W.M. Jones <rjones>
Component: gnome-settings-daemonAssignee: Bastien Nocera <bnocera>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: akostadi, amcnabb, awilliam, bnocera, bob.bogo, brovvnout+rh, bugzilla, covex, dov.grobgeld, ehabkost, fdewaley, fedorabugmail, fedora, gmaxwell, igeorgex, imc, jaisonb, jpazdziora, kas, kevin, mail, mdavis, meklu, michele, michel, mike, mrunge, nemesis, neteler, nyh, opensource, pas, paul.destefano, pauljohn, peter.hutterer, Philippe.Vouters, pmatilai, pnewell, ppecka, relrod, rstrode, smithj4, stein, susi.lehtola, thomas.moschny, tom, xgl-maint
Target Milestone: ---Keywords: CommonBugs, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://fedoraproject.org/wiki/Common_F18_bugs#slow-keys
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-01 21:37:41 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
suggested workaround none

Description Richard W.M. Jones 2012-04-26 18:16:00 EDT
Description of problem:

This is probably the wrong component, but I've no idea what
component to assign this to.

My keyboard died today.  No key input was accepted at all.

After a lot of research (on another computer) I worked out what
had happened: "Slow keys" (an accessibility feature) had turned
itself on by itself, with no visible feedback.

When I worked this out, I also noticed that Settings ->
Accessibility showed "Slow keys" as disabled.  But enabling
and disabling it returned my keyboard to normal.

Version-Release number of selected component (if applicable):

Fedora 17, up to date as of today.

How reproducible:

unknown

Steps to Reproduce:
1. unknown, it did it all by itself
Comment 1 Kevin Fenzi 2012-04-27 11:17:17 EDT
Seeing this here as well in Xfce. All prefs show slow keys disabled here too.
Comment 2 Michele Baldessari 2012-05-07 16:23:50 EDT
Saw this one too. I assume you're all using gdm/gdm3 right?

Disabling the following gconf setting and relogging in should work:
/apps/gdm/simple-greeter/settings-manager-plugins/a11y-keyboard/active
Comment 3 Jeff Iddings 2012-05-13 19:31:19 EDT
No luck with disabling /app/gdm/simple-greeter/settings-manager-plugins/a11y-keyboard/active

However, I did bypass GDM and just ran startxfce4 from the console and the problem is gone. So it is GDM -- I can only conclude it's ignoring the setting and/or it's a different GDM setting.
Comment 4 Richard W.M. Jones 2012-05-14 12:01:16 EDT
This is annoying ...  Has anyone worked out what combination
of keys/actions causes it to activate?
Comment 5 Jeff Iddings 2012-05-14 12:59:27 EDT
Holding down shift for 10 seconds seems to be the way you enable/disable it. 

Shift is my thinking key.. it'll often depress it for a long period of time while thinking how to start my sentence. It's really annoying.
Comment 6 Gregory Maxwell 2012-05-29 18:33:43 EDT
I'm an xmoand user hitting it here too since installing F17— horrible, at first it was randomly hitting me while coding, I thought was failing hardware or a kernel bug, had to keep rebooting to fix it (hard to close and save thing typing at 0.5 CPS) but I didn't know what to file the bug against because I didn't even know where to start troubleshooting.

Figured out what it was after a binge of Inkscape use where it's basically impossible not to trigger (likewise in gimp). Holding down shift more doesn't appear to turn it off for me.

This behavior is degrading the quality of my life because I'll be in the middle of busy activity and then have to very slowly shut down and save everything and reboot to recover.
Comment 7 Paul Sand 2012-06-04 10:56:36 EDT
I am also experiencing this problem, running xfce, not bypassing gdm.

I can cause the problem by holding down the shift key for awhile, but I think that it crops up eventually even if I don't do that. (Because, unlike Jeff, I don't think I habitually do that. Do I?) The message appearing in my .xession-errors is:

(xfce4-settings-helper:1270): xfce4-settings-helper-WARNING **: Failed to show notification: Slow keys (Slow keys are enabled).

Holding down the shift key (thank goodness) for awhile works to fix things without rebooting. Message:

(xfce4-settings-helper:1270): xfce4-settings-helper-WARNING **: Failed to show notification: Slow keys (Slow keys are disabled).
Comment 8 Gregory Maxwell 2012-06-04 11:02:36 EDT
I should amend my comment: holding down shift for a very long time does in fact fix it. I just couldn't believe it took that long.  I also feel like it's happening even when I don't hold down shift, but I really can't be sure of that— it's easy to imagine things and the more likely hypothesis is that in those cases I'm just not noticing.
Comment 9 Ryan C. Underwood 2012-06-04 11:12:19 EDT
I am experiencing exactly the same as Paul on my laptop, also with XFCE.  For me the problem seems to correspond with periods of high system load (memory/CPU usage).
Comment 10 Jim Minter 2012-06-06 12:36:11 EDT
"Me too", using XFCE, up-to-date F17, x86_64.

It's holding down shift that causes the trouble for me.  I get a notification window indicating what's happened (XFCE users, if this doesn't happen for you, do you have xfce4-notifyd installed?), but I can't find an official way to disable this "functionality".

Michele's suggested workaround didn't work for me -- indeed for me the /apps/gdm tree doesn't even show in dconf-editor.  Mucking around with /org/gnome/settings-daemon/plugins/a11y-{keyboard,settings} as my user or the gdm user haven't helped either, and I can confirm that all the .*-?enable settings are set to false.

In mild exasperation I've written a short hack which can be run once after you've logged in through gdb which stop the trouble from happening, at least on my machine.  I'll attach it to this bug -- feel free to try it (at your own risk).
Comment 11 Jim Minter 2012-06-06 12:37:27 EDT
Created attachment 589953 [details]
suggested workaround

suggested workaround -- see comment 10
Comment 12 Paul Sand 2012-06-06 13:23:16 EDT
(In reply to comment #10)
> (XFCE users, if this doesn't
> happen for you, do you have xfce4-notifyd installed?)


Correct. I get notifications after I install xfce4-notifyd. Thanks to Jim for the code.
Comment 13 Paul Sand 2012-06-12 06:38:54 EDT
(In reply to comment #7)
> I can cause the problem by holding down the shift key for awhile, but I
> think that it crops up eventually even if I don't do that. (Because, unlike
> Jeff, I don't think I habitually do that. Do I?) 

After a few days of more careful observation, it turns out that I *do* do that. Apologies if my misconception wasted anyone's time.
Comment 14 Ian Collier 2012-06-12 20:37:34 EDT
Thanks, Jim!  So it's the XKB EnabledControls settings (and the AccessX bit in particular), which are part of the core X server; I'm guessing it's the case that gdm turns this bit on where it didn't before, and this setting is inherited when you log in.

Based on that, I've located a small utility called xkbset:
http://www.math.missouri.edu/~stephen/software/#xkbset

Running "xkbset -a" does the trick.  Can also be used to fix the other thing I've noticed, which is that the audible bell is now turned off by default ("xkbset b").  It would be trivial to package this - maybe Fedora can be persuaded to do so (or the related "xkbctrl" that's mentioned on that page)?
Comment 15 Jaison 2012-06-17 21:38:16 EDT
I too am running F17 Xfce.

I ran into this issue while playing Diablo III where you have to hold down the shift button quite a lot when you run into huge mobs.

Mr Minter, thanks for that hack!  That slow key was gettting super annoying.

Mr Collier, I've tried installing xbset and get an error "install: cannot create regular file `/usr/X11R6/bin': No such file or directory".
Comment 16 Peter Hutterer 2012-06-20 00:18:46 EDT
Server bug. GNOME should warn about this but we don't send it the right event.
In the meantime, the feature can be disabled by unsetting the dconf key.

Technical details:
That checkbox sets a bitflag in the server that enables hardcoded shortcuts to enable/disable certain XKB features. SlowKeys is toggled by holding shift for 8 seconds.

Workaround:
  gsettings set org.gnome.desktop.a11y.keyboard enable false
or, in the accessibility/typing panel, by unchecking the checkbox "Turn on accessibility features from the keyboard"
Comment 17 Peter Hutterer 2012-06-20 01:45:23 EDT
Reassigning, bug caused by upstream commit GNOME_SETTINGS_DAEMON_3_3_4-8-g5e4dcfb, see https://bugzilla.gnome.org/show_bug.cgi?id=668213#c9
Comment 18 Peter Hutterer 2012-06-20 02:01:15 EDT
*** Bug 832321 has been marked as a duplicate of this bug. ***
Comment 19 Gregory Maxwell 2012-06-20 08:33:34 EDT
I'm not so sure about that workaround, on a system that experiences this:

$ gsettings get org.gnome.desktop.a11y.keyboard enable
false
Comment 20 Jeff Iddings 2012-06-20 08:50:59 EDT
(In reply to comment #19)
> I'm not so sure about that workaround, on a system that experiences this:
> 
> $ gsettings get org.gnome.desktop.a11y.keyboard enable
> false

Same here. I'm using the 'disable-slowkeys' hack provided above; which works.. but is not an ideal workaround.
Comment 21 Peter Hutterer 2012-06-20 21:38:00 EDT
(In reply to comment #19)
> I'm not so sure about that workaround, on a system that experiences this:
> 
> $ gsettings get org.gnome.desktop.a11y.keyboard enable
> false

are you still running xmonad? if so, gnome-settings-daemon that reads that configuration and applies it to X (much in the same way as xkbset) won't be running. Should've mentioned that the workaround is for GNOME systems, other desktop environments have other methods I suspect.
Comment 22 Fedora Update System 2012-06-26 00:38:33 EDT
xorg-x11-server-1.12.2-4.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.12.2-4.fc17
Comment 23 Fedora Update System 2012-06-26 17:29:20 EDT
Package xorg-x11-server-1.12.2-4.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.12.2-4.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9936/xorg-x11-server-1.12.2-4.fc17
then log in and leave karma (feedback).
Comment 24 Peter Backes 2012-06-26 19:57:27 EDT
(In reply to comment #23)
> Package xorg-x11-server-1.12.2-4.fc17:
> * should fix your issue,

Problem persists in XFCE. Pressing shift for 10 seconds yields the notification "Slow Keys  Slow Keys are enabled" and enables slow keys, despite accessibility "Settings => Accessibility => Use slow keys" being turned off.

Can't say anything about GNOME, though.
Comment 25 Peter Hutterer 2012-06-26 20:36:13 EDT
grab xkbset from http://www.math.missouri.edu/~stephen/software/ and run
  xkbset q | grep "Accessibility Features"
is it on or off?
Comment 26 Peter Backes 2012-06-26 20:46:35 EDT
"Accessibility Features (AccessX) = On"
Comment 27 Peter Hutterer 2012-06-26 21:45:07 EDT
This appears to be an xfce bug then. Please file it separately.
Comment 28 Jeff Iddings 2012-06-26 22:16:32 EDT
(In reply to comment #27)
> This appears to be an xfce bug then. Please file it separately.

This issue appears to be happening with all desktop environments I've tried, how do you propose I file that?
Comment 29 Peter Backes 2012-06-26 22:26:27 EDT
Bug 835740
Comment 30 Gregory Maxwell 2012-06-27 11:35:25 EDT
Accessibility Features (AccessX) = On

Likewise with xmonad.
Comment 31 Fedora Update System 2012-07-02 18:26:31 EDT
xorg-x11-server-1.12.2-4.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 32 Till Maas 2012-07-24 04:43:52 EDT
(In reply to comment #31)
> xorg-x11-server-1.12.2-4.fc17 has been pushed to the Fedora 17 stable
> repository.  If problems still persist, please make note of it in this bug
> report.

The problem is not properly fixed. With i3 and xmonad I still see that "Slow Keys" ist turned on, when the shift key is pressed too long. It is not obvious how to disable this, for example in xorg.conf, and it seems to be disabled when the keyboard is re-connected. Afterwards it will also not turn on again. The update notes only say, that the fact that slows keys is turned on in the Xorg log file and that somehow gnome is notified.
Comment 33 Nadav Har'El 2012-08-04 17:53:50 EDT
This bug still exists (I am using xorg-x11-server-Xorg-1.12.2-4.fc17.x86_64), and is one of the most annoying bugs that have hit Fedora in many years.

Basically, for about a month now, almost every day my keyboard "died" at a random time. At first, I thought this was a hardware problem, so I used to reboot. Then, I discovered that the keyboard "comes back" if I restart the X server, so I started doing that (which was only mildly less disturbing than a reboot...). Today I finally noticed that they keyboard isn't actually dead - but rather if I press a key for about a second, it works! Which brought me to this bug report. The comments above suggested that pressing shift for 10 seconds is what brings on this terrible bug, and I checked it, and it's true! (for me, only the right shift brings this behavior). Unfortunately, I didn't find any key to disable this "slowkeys" (shift again didn't work...), so I installed "xkbset" recommended above, and "xkbset -sl" restores my keyboard to normal (after I spend about a minute slowly typing this command ;-)).

Like I said, the new version did *NOT* help, as I'm still seeing this problem in xorg-x11-server-Xorg-1.12.2-4.fc17.x86_64. 
The bug is also not Gnome specific, as I'm not using Gnome, nor KDE nor XFCE (I'm actually using my own ~/.xinitrc, and my own window manager - not that any of this matters, or should matter).

Also note that this is not a Fedora-specific bug: It also hit Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677173)

I'm now using another workaround described above, also using xkbset: I run "xkbset -a" in the beginning of my session which seems (?) to prevent a long shift press from having its usual annoying effect.
Comment 34 James 2012-08-11 11:52:26 EDT
Under XFCE, the notification for this has always worked. However there is no way to turn slowKeys auto-toggle off other than using xkbset(which isn't in the Fedora repository and must be run after every reboot).
Comment 35 Nadav Har'El 2012-08-11 15:03:24 EDT
I want to stress that *notifying* the user that slowkeys was turned on (because he pressed shift for a few seconds) is a good start, but X *cannot* count on this. If it does, this is broken behaviour that breaks decades of X Windows System conventions:

In my opinion the "accessx" feature in the X server *must* be *off* by default, and only turned on explictly by desktop environments (Gnome, KDE, XCFE or something homebrewed) which know how to deal with this feature. Namely, if Gnome wants to support slowkeys, it will turn on accessx explicitly, and capture the switch-to-slowkeys even and notify the user. At the same time, a more primitive desktop environment (e.g., twm) will leave accessx off, and slowkeys can never be turned on. Users for which slowkeys are important will simply need to avoid the primitive environment (which they will, anyway).
Comment 36 Peter Hutterer 2012-08-12 21:00:54 EDT
Tested F16, F17 and upstream Xorg. A plain X server does not enable slow keys. Unless you find different behaviour, you'll need to take this up with your WM or DE, whatever enables the slow keys behaviour.

Reproduce yourself, install xterm, stop your current session, start plain X server.

yum install xterm
systemctl stop prefdm.service
xinit --

This starts a plain X server and xterm. Try if SlowKeys is on.
Comment 37 Jan Pazdziora 2012-08-13 03:55:09 EDT
(In reply to comment #36)
> 
> A plain X server does not enable slow keys.

[...]

> This starts a plain X server and xterm. Try if SlowKeys is on.

Just to make sure our investigation is sane -- how did you test for the slow keys to be on? By holding the left shift long enough or by checking something in the X server?
Comment 38 Ian Collier 2012-08-13 14:27:52 EDT
As I suspected in comment 14, this is a gdm issue.  I have now tested:

- log in with the gdm login screen: AccessX is on
- log in with the kdm login screen: AccessX is off
- log in on text console then xinit (as comment 36): AccessX is off

The test was done with "xkbset q" and looking for the line:

Accessibility Features (AccessX) = Off

(Also of interest is the fact that GNOME doesn't turn it back on: I've tried all of the above with both GNOME and FVWM as my session manager and results didn't depend on which one I used.)
Comment 39 Peter Hutterer 2012-08-13 18:07:55 EDT
(In reply to comment #37)
> Just to make sure our investigation is sane -- how did you test for the slow
> keys to be on? By holding the left shift long enough or by checking
> something in the X server?

holding shift key, checking the log for the message (F17 and upstream only) and the xkbset utility.
Comment 40 Paul Johnson 2012-08-21 13:18:10 EDT
On 2012-08-19, I complained about the 10-second Shift key activation of slow keys in an xfce mailing list. 

The package maintainer responded quickly.  He sent a message indicating that he had fixed the problem upsteam in xfce:
 
Pushed a fix in git master branch: http://git.xfce.org/xfce/xfce4-settings/commit/?id=153b19efaff6577b80d1d396c35c4dd688512da7

AccessXKeys control should now be disabled by default. You can use the /accessibility/AccessXKeys Xfconf property to control this.

Regards,

Jérôme


Until that package works its way into repositories, I suggest users install xkbset and run "xkbset -a" at the beginning of the session to de-activate the 10-second Shift key problem.
Comment 41 Nadav Har'El 2012-08-21 13:41:10 EDT
(In reply to comment #38)
> As I suspected in comment 14, this is a gdm issue.  I have now tested:
> 
> - log in with the gdm login screen: AccessX is on
> - log in with the kdm login screen: AccessX is off
> - log in on text console then xinit (as comment 36): AccessX is off

Good catch. This is definitely a bug. Perhaps it was turned on in order to allow this feature to be used for the duration of the login screen itself? This would make (some) sense, but then the bit needs to be turned off again - until the desktop environment (which will not necessarily be Gnome!) decides if it wants to turn it back on.
Comment 42 Tomas Smetana 2012-08-22 16:32:28 EDT
Hello,
  here's a workaround that looks to be working for me:

Create a new file in /etc/dconf/db/gdm.d/ with a number prefix (the highest one in the directory, e.g. 01-no-a11y-keyboard) with the following content:

[org/gnome/desktop/a11y/keyboard]
enable=false

Then run 'dconf update': this should create new /etc/dconf/db/gdm settings database.

Then restart gdm...

Hope this helps.
Comment 43 Adam Pribyl 2012-08-25 11:38:46 EDT
Happens here with IceWM too. Logging in thru GDM. It looks like after dropping the memory hog Gnome-shell, I'll have to drop also GDM. Back to roots.:)
Comment 44 Paul Johnson 2012-08-25 12:37:24 EDT
(In reply to comment #43)
> Happens here with IceWM too. Logging in thru GDM. It looks like after
> dropping the memory hog Gnome-shell, I'll have to drop also GDM. Back to
> roots.:)

Removing GDM isn't really necessary. The problem may not even be in there. It is more likely in your desktop environment, some component is turning on AccessXKeys. Until you find how to permanently remove it, install xkbset and run xkbset -a to turn off the 10 seconds to death. I mean shift key activation of accessibility features.

For my case, I found that the settings were in xfce and they have fixed it.
Comment 45 Kevin Fenzi 2012-08-25 13:14:12 EDT
> Removing GDM isn't really necessary. The problem may not even be in there.

It seems to me it pretty clearly is. No other DM shows this issue... so I think it's a matter of gdm changing the setting and perhaps _also_ the DE not setting it back. 

So, another simpler workaround for folks is to just switch to lxdm or lightdm for now.
Comment 46 Adam Pribyl 2012-08-26 06:51:52 EDT
I agree with Kevin. This is clearly GDM setting slow keys on, while the server defaults are and always were off. Then DE/WM is not setting it to any other state - for sure the case of IceWM. This is not the bug of WM as it is only a.. window manager. It is not possible "fix" all WMs (as this is not something WM should set) in Fedora just because of GDM.

Well I understand GDM should support disabled people out of the box to login but it should set the slow keys back to default (off) at handover to DE/WM = agree with comment #35.
Comment 47 Ray Strode [halfline] 2012-08-27 17:00:57 EDT
GDM's gnome-settings-daemon could probably disable accessX on exit (on it's way to the user's session) if none of the AccessX features are in use.
Comment 48 Tomas Pospisek 2012-09-22 00:49:53 EDT
(In reply to comment #42)

The dconf update procedure proposed by Tomas Smetana didn't work. At least not under Xfce4 under Ubuntu Precise.
*t
Comment 49 GeoffLeach 2012-09-24 19:41:37 EDT
(In reply to comment #37)
> (In reply to comment #36)
> 
> Just to make sure our investigation is sane -- how did you test for the slow
> keys to be on? By holding the left shift long enough or by checking
> something in the X server?

Fedora 17 and Xfwm4. Settings->Accessibility shows SlowKeys OFF. Nevertheless, I loose the keyboard about once the day. Previously, the solution I was using was to log out (back to GDM) and log in. thanks to this discussion, I'm now holding down the shift key to remove the problem.
Comment 50 Michele Baldessari 2012-09-25 03:35:30 EDT
Geoff,

that is an XFCE bug. Somehow it doesn't read the right slowkeys status.
Just go in Settings->Accessibility and turn it on and off again and it will be disabled.
Comment 51 Panu Matilainen 2012-09-28 06:25:46 EDT
Just FWIW, Tomas' dconf trick from comment #42 works fine for me and has restored both my "thinking key" and sanity, the mysterious keyboard lockups were driving me crazy.
Comment 52 tengel 2012-09-28 10:44:27 EDT
I can also confirm the dconf work from comment #42 has fixed it for me, I have also been experiencing the "thinking key" activation and random weekly lockups of my keyboards on both the work desktop and home laptop (w/USB external keyboard).

For the keyboard lockups I found (in both cases) unplugging the USB, waiting a second, and plugging it back in "fixed" that issue. Crossing my fingers this dconf works fixes it for real.
Comment 53 Ray Strode [halfline] 2012-09-28 13:16:19 EDT
Filed an upstream report.
Comment 54 Ray Strode [halfline] 2012-09-28 13:17:02 EDT
( https://bugzilla.gnome.org/show_bug.cgi?id=685063 )
Comment 55 Paul Johnson 2012-09-28 14:43:22 EDT
Reply to #49 

Dear Geoff: That is the known problem, which has since been fixed for future xfce, but not in the version you have. THat applet cannot control the automatic activation of the slow keys by the "long rest on the shift key". 

You need to try the more direct approaches to the problem, either the one I propose in note #40 or the one proposed in #42.
Comment 56 GeoffLeach 2012-09-28 15:15:39 EDT
(In reply to comment #55)
> Reply to #49 
> 
> Dear Geoff: That is the known problem, which has since been fixed for future
> xfce, but not in the version you have. THat applet cannot control the
> automatic activation of the slow keys by the "long rest on the shift key". 
> 
> You need to try the more direct approaches to the problem, either the one I
> propose in note #40 or the one proposed in #42.

Hey Paul, thanks for the info.  FWIW, I have not seen the problem since I went to Settings->Accessibility and clicked on for slow keys, closed and re-opened and clicked off. Seems to have worked, but that's hardly a positive result. I'll update if it changes. Also FWIW, before doing that, I found that leaning on the shift key cleared the problem.
Comment 57 Till Maas 2012-10-02 14:05:06 EDT
I just created a review request for xkbset (see bug 862368) which at least allows to easily work around this bug.
Comment 58 Aleksandar Kostadinov 2012-12-17 16:47:07 EST
confirmed that comment #42 fixes the issue on fedora 18 current running XFCE and GDM. Sounds like a GDM bug to me. It shouldn't alter that setting permanently. I see why it would be enabled in the GDM itself but should not be leaved turned on to the DE.

Please fix somehow for fedora 18, it really causes great confusion.
Comment 59 Kevin Fenzi 2012-12-17 16:50:52 EST
Note that fresh installs of Xfce in f18 use lightdm, which doesn't have this issue.
Comment 60 Gregory Maxwell 2012-12-17 17:05:46 EST
It's pretty disappointing that this is still open and still getting reports after all this time. :(

That XFCE installs of f18 use lightdm doesn't solve it for, e.g. people using xmonad.
Comment 61 Nadav Har'El 2012-12-18 02:28:30 EST
Guys, I can't believe that after 8 months, this bug still exists. Before I knew how to work around it (with xkbset -a in my .xinitrc), I was experiencing keyboard hangs almost every day. Less experienced people than myself would surely leave Fedora after 8 months of keyboard hangs reminiscent of the bad old days of MS-Windows' daily hangs.

I realise it's an upstream bug in GDM - but if they don't bother to do anything about it (see https://bugzilla.gnome.org/show_bug.cgi?id=685063) why doesn't fedora drop GDM as the default? Why does Gnome being the default "desktop environment" mean that it also must be the login screen? I don't see any connection - if GDM sucks, please choose KDM, or most likely - "lightdm" (I have to admit, today is the first time I hear of it), or anything else, as the default display manager - anything but the broken GDM.

BTW, if GDM isn't fixed please make sure that also upgrading users - not just fresh installs - use lightdm instead of GDM.

By the way, Ubuntu switched from GDM to LightDM in its October 2011 release, just in time to avoid this bug....
Comment 62 Philippe Vouters 2012-12-26 11:47:32 EST
Fell into this problem at login time.

Suggests /etc/gdm/custom.conf support
[daemon]
Accessibility={True | False}

This way the X server will be able to start with -accessx:

XKEYBOARD OPTIONS
       X servers that support the XKEYBOARD (a.k.a.  "XKB")  extension  accept
       the  following options.  All layout files specified on the command line
       must be located in the XKB base directory or a subdirectory, and speci-
       fied as the relative path from the XKB base directory.  The default XKB
       base directory is /usr/lib/X11/xkb.

       [+-]accessx [ timeout [ timeout_mask [ feedback [ options_mask ] ] ] ]
               enables(+) or disables(-) AccessX key sequences.

instead of the current:

root      1239  1215  2 17:22 tty1     00:00:18 /usr/bin/Xorg :0 -background none -logverbose 7 -auth /var/run/gdm/auth-for-gdm-LJ1Ur8/database -seat seat0 vt1

Yours truly,
Comment 63 Paul DeStefano 2013-01-02 16:56:34 EST
Seems reasonable, but it didn't work.  The 'Accessibility' value in /etc/gdm/custom.conf didn't seem to make any difference and the symptom is still observed.

Furthermore, I would like to echo Navad's call for fixing upgraded users.
Comment 64 Paul DeStefano 2013-01-02 17:30:14 EST
Uh, yeah.  How the heck do you do use lightdm?  It doesn't seem to be supported by prefdm.   It's not a SYSV-compatible service.   It's not a new systemd service, either.  At least, it doesn't come with the appropriate files for such service managers.  Nice.
Comment 65 Kevin Fenzi 2013-01-02 17:53:48 EST
Drifting way off topic for this bug, but: 

yum install lightdm-gtk
systemctl enable --force lightdm.service
Comment 66 Andrew McNabb 2013-01-03 15:28:24 EST
I've had this happen about ten times over the last month, and I had no idea what was causing it. Once I had to reboot my machine in the middle of a job interview, and on another occasion I had to borrow someone else's computer for a presentation. Wow, what an awful feature.

In response to Comment #50, I've now tried going to Settings->Accessibility and toggling slowkeys in XFCE, but this does not bring back keyboard functionality for me. Holding down on the shift key for 10 seconds works, though (temporarily).

In response to comment #65, I installed lightdm-gtk and tried doing `systemctl enable --force lightdm.service` but got the error: "Failed to issue method call: No such file or directory". However, I was able to switch to lightdm by setting DISPLAYMANAGER="lightdm" in /etc/sysconfig/desktop.
Comment 67 Aleksandar Kostadinov 2013-01-03 16:06:50 EST
To switch from gdm to lightdm I just did "yum remove gdm". Simple and effective.

btw I also had troubles with multiscreen setup using xrandr when using GDM and that was the reason to remove it altogether... I didn't want to debug it and hope there is nothing else it (gdm) breaks.
Comment 68 Paul 2013-01-03 18:14:56 EST
This sounds alot like a problem that I was having in October of 2012 in F17 under Xfce. The shift key workaround didn't help.

It seemed that switching keyboard from a 2001 vintage Microsoft Natural to the HP keyboard that came with the machine fixed it ... which doesn't make sense to me if it is related to this bug. I never got to give an extended multiple day/week/month test as I've been on a project which requires I use F16. Nevertheless, I figured I'd mention it on the one in a million chance it makes sense to someone
Comment 69 Paul DeStefano 2013-01-04 01:15:34 EST
Sorry, Kevin.  Let me try to close the loop.  I think your method may work for F18, but F17's lightdm-gtk pkg doesn't include the systemd service file for lightdm, so it cannot be loaded or enabled that way.  I read the prefdm script wrong and, as Andrew and others have stated, creating sysconfig/desktop and setting variable DISPLAYMANAGER *does* select lightdm over gdm (although, I'm pretty sure the proper value is the full path '/sbin/lightdm', not just 'lightdm' as others have used.)

That said, if the fresh-install configuration uses lightdm.service, replacing prefdm.service, please include that in the upgrade configuration if at all possible.  At the very least, please make a clear note about it here so upgrade users have a chance to find out about it.
Comment 70 ppecka 2013-01-23 18:10:45 EST
on lenovo thinkpad x220 running updated F17. when internal keyboard "slowed down", i plugged external keyboard via USB, the external one operates at normal speed, internal is however in "slow" mode. 10sec "shift" on external kbd works, at least for some time
Comment 71 fedora 2013-01-28 04:56:56 EST
I have "fixed" this on my X220 by using a cronjob which calls "xkbset -sl" every minute. Real bug fixing seems to be low priority. Before I had this, I had to reboot the machine in such situations - I couldn't even search for solutions because I was on the road. Very inconvenient. I also have to say that co-workers are increasingly switching from fedora to other linuxes because of continued usability issues like this. Some even refuse to use linux on the desktop at all.
Comment 72 Fedora Update System 2013-01-28 13:50:48 EST
gnome-settings-daemon-3.6.4-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/gnome-settings-daemon-3.6.4-3.fc18
Comment 73 Philippe Vouters 2013-01-29 14:01:41 EST
As far as it seems, I have the issue I faced under both Xfce when logged in and gdm when logging into with the following:
$ sudo find /etc/ -type f -exec grep xkbset {} \; -print
xkbset -a
/etc/gdm/PostLogin/Default
Many thanks indeed to all repliers to this Bugzilla report to have drove me to this solution. Slow keys (Accessibility) is no longer an issue for me.
Comment 74 Fedora Update System 2013-01-29 19:54:35 EST
Package gnome-settings-daemon-3.6.4-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-settings-daemon-3.6.4-3.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1632/gnome-settings-daemon-3.6.4-3.fc18
then log in and leave karma (feedback).
Comment 75 Fedora Update System 2013-02-09 06:27:06 EST
gnome-settings-daemon-3.6.4-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 76 Erik Streb del Toro 2013-03-11 07:17:21 EDT
I am still facing this problem. I am using Fedora 17, GDM and Xmonad. Great that I found this bug report with all the workarounds. Right shift key for 10 seconds makes my keyboard usable again.

Will this bug be truly resolved some day? In GDM I mean?

gdm --version
GDM 3.4.1

X -version

X.Org X Server 1.12.4
Release Date: 2012-08-27

xmonad --version
xmonad 0.10

cat /etc/fedora-release
Fedora release 17 (Beefy Miracle)
Comment 77 Adam Williamson 2013-04-19 19:52:13 EDT
several reporters still seem unhappy on F17, so re-opening.
Comment 78 Paul 2013-04-19 20:06:00 EDT
Thank you,
F17 User
Comment 79 Fedora End Of Life 2013-07-04 01:41:22 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 80 Jan Pazdziora 2013-07-16 13:50:31 EDT
For the record, I haven't experienced this problem on Fedora 18 for a couple of months and I do not see it on Fedora 19 either. Can we agree that for bugzilla reported for Fedora 17, this is a NEXTRELEASE resolution (rather than WONTFIX)?
Comment 81 Kevin Fenzi 2013-07-16 14:03:28 EDT
*** Bug 835740 has been marked as a duplicate of this bug. ***
Comment 82 Adam Pribyl 2013-07-16 15:31:11 EDT
Acctually I implemented everywhere the workaround and on my desktops I switched to different DM/WM. I only tried that now on F19 and it seems to me, it's OK there (checked with xkbset q). But would be glad if someone else could confirm as the duplite seems to be reported against F18.
Comment 83 Fedora End Of Life 2013-08-01 12:53:50 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 84 Melker Narikka 2014-07-25 08:33:34 EDT
I bumped into this a couple of weeks ago, thinking my keyboard was dead.
Since this problem manifested on a USB keyboard attached to the laptop,
I thought something was fishy and stumbled upon this bug.

Still happens on Fedora 20.

gdm-3.10.0.1-1.fc20.x86_64
i3-4.8-3.fc20.x86_64
xorg-x11-server-Xorg-1.14.4-11.fc20.x86_64
Comment 85 Peter Backes 2014-07-25 09:32:46 EDT
(In reply to Melker Narikka from comment #84)
> I bumped into this a couple of weeks ago, thinking my keyboard was dead.
> Since this problem manifested on a USB keyboard attached to the laptop,
> I thought something was fishy and stumbled upon this bug.
> 
> Still happens on Fedora 20.

The solution is:

yum install lightdm
yum erase gdm
Comment 86 Adam Williamson 2014-07-25 11:15:23 EDT
That's not a solution, it's a workaround...

and I've actually seen this happen a couple of times recently too on F21. Let's re-open it.
Comment 87 Ricky Elrod 2014-08-18 15:37:26 EDT
Yeah, I keep hitting this as well using GDM + Xmonad.
Comment 88 Tom Trebisky 2014-11-22 01:12:04 EST
This is certainly still an issue with Xfce and F20.  It has been biting me off and on, and I finally got irritated enough to research the issue.  Clearly this
is not something that should be enabled by default.
Comment 89 James 2014-12-15 16:42:45 EST
I don't see this on F21 Workstation. Post-install, the only WM-related change I made is switching to Mate.
Comment 90 Dov Grobgeld 2014-12-15 16:46:46 EST
I can't reproduce it either under F21, and I'm using the same fvwm configuration in which I previously experienced the bug in F20.
Comment 91 Brownout 2015-01-26 12:20:40 EST
I can definitely reproduce it, but it's not a clean installation, upgraded from F17 -> F18 -> F19 -> F20 -> F21
Comment 92 MB 2015-02-04 13:50:19 EST
Still happens on F21, GDM, XFCE, despite "Accessibility" settings window with "Assistive Technologies" unchecked, and "Keyboard / Slow Keys" unchecked.
Comment 93 Paul Johnson 2015-02-04 15:15:47 EST
For those of you who are new here and don't read the whole history, please know this.  This problem can be completely eliminated if you add this in your startup:

xkbset -a

See comment 44.  As soon as I started doing that, the problem was completely disappeared.  So, while it is fun to complain about this unexpected behavior, it is easy to make it go away.
Comment 94 MB 2015-02-04 16:14:25 EST
Re #93. It's not really a fun/no-fun thing; it's just reporting data, since there are clearly configurations for which the bug is not present.

:) For those of you that have been here a long time, please know this.
While there appear to be a handful of work-arounds, the bug itself is alive and well.
Comment 95 Erik Streb del Toro 2015-07-31 04:04:35 EDT
I am using Fedora 21 with gdm and Xmonad. The bug appears again and drove me crazy (because I forgot about it after having it “fixed” in Fedora 17).

Couldn’t the standard way be to have it turned off? I bet most of the affected users never find this bug report here, but think their computer is broken.
Comment 96 Erik Streb del Toro 2015-07-31 04:46:40 EDT
Just for information: The former from comment 42 workaround which fixed the bug for all users doesn’t work anymore on Fedora 21.

First /etc/dconf/db/gdm.d/ does not exist. Then I tried putting a file 01-no-a11y-keyboard in /etc/dconf/db/ibus.d/ and then did dconf update, but nothing changed. Then I created /etc/dconf/db/gdm.d/ manually and put the file there and did dconf update again. But it didn’t resolve the problem either.

So I ended up installing xkbset and have to call
  xkbset -a
at login for every single user.
Comment 97 Ian Collier 2015-07-31 05:29:46 EDT
Re comment 96: that is basically bug 1174344 and is fixed by creating 
/etc/dconf/profile/gdm as described in the first point here:
https://help.gnome.org/admin/system-admin-guide/stable/login-userlist-disable.html.en
Comment 98 Fedora End Of Life 2015-11-04 10:26:14 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 99 Fedora End Of Life 2015-12-01 21:38:06 EST
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.