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
Seeing this here as well in Xfce. All prefs show slow keys disabled here too.
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
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.
This is annoying ... Has anyone worked out what combination of keys/actions causes it to activate?
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.
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.
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).
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.
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).
"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).
Created attachment 589953 [details] suggested workaround suggested workaround -- see comment 10
(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.
(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.
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)?
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".
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"
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
*** Bug 832321 has been marked as a duplicate of this bug. ***
I'm not so sure about that workaround, on a system that experiences this: $ gsettings get org.gnome.desktop.a11y.keyboard enable false
(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.
(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.
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
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).
(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.
grab xkbset from http://www.math.missouri.edu/~stephen/software/ and run xkbset q | grep "Accessibility Features" is it on or off?
"Accessibility Features (AccessX) = On"
This appears to be an xfce bug then. Please file it separately.
(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?
Bug 835740
Accessibility Features (AccessX) = On Likewise with xmonad.
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.
(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.
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.
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).
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).
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.
(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?
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.)
(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.
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.
(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.
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.
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.:)
(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.
> 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.
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.
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.
(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
(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.
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.
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.
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.
Filed an upstream report.
( https://bugzilla.gnome.org/show_bug.cgi?id=685063 )
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.
(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.
I just created a review request for xkbset (see bug 862368) which at least allows to easily work around this bug.
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.
Note that fresh installs of Xfce in f18 use lightdm, which doesn't have this issue.
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.
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....
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,
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.
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.
Drifting way off topic for this bug, but: yum install lightdm-gtk systemctl enable --force lightdm.service
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.
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.
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
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.
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
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.
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
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.
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).
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.
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)
several reporters still seem unhappy on F17, so re-opening.
Thank you, F17 User
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.
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)?
*** Bug 835740 has been marked as a duplicate of this bug. ***
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.
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.
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
(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
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.
Yeah, I keep hitting this as well using GDM + Xmonad.
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.
I don't see this on F21 Workstation. Post-install, the only WM-related change I made is switching to Mate.
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.
I can definitely reproduce it, but it's not a clean installation, upgraded from F17 -> F18 -> F19 -> F20 -> F21
Still happens on F21, GDM, XFCE, despite "Accessibility" settings window with "Assistive Technologies" unchecked, and "Keyboard / Slow Keys" unchecked.
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.
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.
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.
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.
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
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.
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.