keyboard not working after logging in via gdm due to"slow keys" feature being accidentally enabled

[Juri Pakaste]

I run Edgy. Everything is up to date. I wanted to give upstart a try, but ran into problems. I'm not sure if this bug is in upstart or if upstart just triggered a bug in somewhere else.

Startup seemed to go OK, I got the GDM login screen and could log in. However, once the Gnome session was running, there was no keyboard input. No window reacted in anyway to hitting the keyboard. I restarted to see if this was some kind of one time fluke, but the same thing happened again. Next time I booted up into single user mode, reinstalled sysvinit, rebooted and everything was fine again.

On the second reboot I also tried switching to other virtual terminals, but they were empty. I'm not sure how to debug this, as I can't really do anything if the keyboard isn't working.

[Jan (debian-gepro)]

I observe similar problem. Time to time keyboard stops working. I can restore normal function by switching workspaces using mouse. In the keyboard-less state gksu won't work complaining: "Cannot grab your keyboard".

It started after I upgraded to upstart.

[Scott James Remnant (Canonical) (canonical-scott)]

?! this has nothing to do with upstart

[Sebastien Bacher (seb128)]

Thanks for your bug. If you pick a another session then GNOME (or Default) from the login screen, do you have the issue too? Looks rather an xorg issue than a gdm one

[Henrik Nyberg (henrik-mysko)]

This could be related to upstart. I have a similar problem, where the keyboard does not work after the boot process is complete. By logging in remotely to the computer I shut down GDM and X, and on the VT below there was a terminal with the text: "The system has reached a state where there are no jobs running.", and that it would open a shell instead. This shell seemed to have received some of the keyboard input that was attempted while GDM was running.

Although, I have no knowledge about the workings of upstart, I am suspecting that it might have some relation to the boot process. It was not experienced until sysvinit was replaced by upstart.

[Diego Ongaro (ongardie)]

I just upgraded to edgy last night/today and my keyboard is no longer working (at all. no Ctrl+Alt+*, no Num Lock, etc) after I log in through gdm. It does work in gdm, in gnome fail-safe mode, in fluxbox, and in gnome for my other user account, but it fails to work in gnome for my regular user account.

i have tried manually resetting the keyboard map to US English 104 and using the reset button in gnome's keyboard preferences, but that doesn't work either.

I'd suggest bumping up the severity of this bug, too. If people upgrade and can't use their keyboard, they're going to have trouble accomplishing anything at all.

[Diego Ongaro (ongardie)]

I should have mentioned that if I later log out of gnome/switch users, they keyboard starts working again. If I then go back to gnome on my regular user, it no longer works. etc.

[Diego Ongaro (ongardie)]

I've determined that this issue is not related to gdm at all, because it kept happening when I tried:
As root: /etc/init.d/gdm stop
As user: startx

I also verified that the keyboard does work in gnome for my regular user after deleting/renaming the following directories:
.gconf, .gconfd, .gnome, .gnome2, .gnome2_private . It's obviously not a good solution though, because all my gnome settings have defaulted.

[Sebastien Bacher (seb128)]

Juri, do you have the issue with an another session or user?
Diego, do you have the issue if you starts gnome-settings-daemon from fluxbox by example?

[Diego Ongaro (ongardie)]

Sorry, I long ago started over with clean preferences.

[Juri Pakaste (juri)]

I just tried it again, this time I got a different problem:

The system has reached a state where there are no jobs running. A shell will be spawned so that... etc.

It had got the network connection up, but that was pretty much it. Oh well, reinstalled sysvinit.

I'm planning on doing a clean install of Edgy anyway, so I probably won't be able to give much input on the bug after this. The edgy installer is giving me some grief, trying to use a display mode my monitor can't handle, but that's another bug...

[Daniel Holbach (dholbach)]

Assigning to X Swat people, they surely know some clever questions too.

[Frederik Himpe (fhimpe)]

I experienced two times the same problem already on my Apple Powerbook. I could solve it by removing ~/.gconf in my user account, so I do think it's a gnome problem somewhere.

[Michael Hutchinson (m.j.hutchinson)]

This has happened to me on Feisty. It does look like a Gnome issue.

[Shaved Wookie (shavedwookie)]

I'm having this issue as well, but on Kubuntu Gutsy (32 bit)! I suspect that it's probably an X thing.

I can also use the keyboard fine for the grub / login / failsafe, but not at all once I've actually logged in (not even Ctrl+alt+f1/del/backspace.

Man, it's not easy to debug a problem with no keyboard! Personally I feel having people across multiple versions of *buntu not be able to use their computer in any non mouse related way as a bit higher than "low" priority...

Whatever I can do to help just let me know.

[Glyn Davies (agdavies)]

I also had the same symptoms, under KDE Kubuntu / Gutsy. I could enter my password at the login screen (kdm?) but by the time the desktop loaded, the keyboard was non-functional (not even caps-lock toggled the LED), though mouse was fine.
After lots of trial and error, I narrowed it down to the presence of $HOME/.kde/share/config/kaccessrc which for me, contained:

[Keyboard]
GestureConfirmation=false
Gestures=true
SlowKeys=true

Moving the file out the way solved the problem. Seeing this reminded me that I probably caused this myself by choosing "Deactivate All Gestures" from the dialogue after randomly hitting the shift key lots of times - but it wasn't until I rebooted a number of weeks later that the problem surfaced.

I guess it can't be the same problem for the Gnome users here, but maybe it'll give some clues. Sorry if it's a red-herring.

[Maia Everett (linneris)]

This is apparently an issue with gnome-settings-daemon, gdm is innocent. And I have the same problem right now with no clue how to fix it :(((

[Miguel Rodríguez (migrax)]

This is happening here too since the latest gnome-settings-daemon update. In fact, removing gnome-settings-daemon solves the keyboard problem (dpkg --purge --force-depends gnome-settings-daemon).

[Miguel Rodríguez (migrax)]

The problem seems related to the a11y plugin. Deactivating it manually

gconftool-2 -s /apps/gnome-settings-daemon/plugins/a11y-keyboard/active -t bool false

fixes the problem for me. If I reactivate it, the keyboard stops working again.

HTH.

[Sebastien Bacher (seb128)]

the gnome-control-center task is enough

[Sebastien Bacher (seb128)]

Does disabling the a11y option workaround the issue for other users having the bug?

[Miguel Rodríguez (migrax)]

I have found the reason for the "bug" in my machine.

Somehow the slow keys feature of the keyboard was activated. I don't know how that happened, but that was the reason why disabling the a11y plugin did work around the problem. Sorry for the noise.

Maybe the rest of the people should recheck their keyboard accessibility settings.

[Martin von Wittich (martin.von.wittich)]

I just had the same problem and I can confirm that the "slow keys" feature was the reason for this. As the option "Allow to turn on accessibility features on and off from the keyboard" was set, I guess I accidentally enabled it with some obscure key combination (the help doesn't state which key combination would enable slow keys, though). It's not a bug, it's a feature :)

Seeing the amount of confusion this has created, there is apparently a need for some kind of notification bubble that informs users that are desperately hitting keys about this.

[ethanay (ethan-y-us)]

my keyboard recently stopped working after logging in. I will check whether it is an accessibility "feature" and report back. The keyboard behavior may be the result of a properly functioning feature, but the lack of any communication/notification to the user that the feature is active is certainly a bug (or at the very least a very important feature request). Keeping my fingers crossed...

[ethanay (ethan-y-us)]

confirming that it was indeed that accessibility features had somehow been silently enabled. phew!! thanks for your help! this definitely needs better notification!

[Bryce Harrington (bryce)]

Thanks Miguel, Martin, and ethanay for identifying and confirming the problem is with the "slow keys" accessibility feature; I've updated the title. @Juri, if you're still tracking this bug it would be helpful if you concur with this analysis.

Could someone propose what the next step should be for this bug report? Is it just user error, or is there something that silently turns this feature on, that should be corrected? Or is there a deeper issue that deserves further analysis?

[Martin von Wittich (martin.von.wittich)]

I just tried it again, and I think I've found the underlying issue. As I disabled the option 'Keyboard Preferences' -> 'Allow to turn accessibility features on and off from the keyboard', I had to reactivate this to test it.

As I now know, the required action is to hold SHIFT for 8 seconds to toggle the 'Slow Keys' feature, and I did just that. After 8 seconds, a dialog popped up, asking me "Do you want to activate Slow Keys?" (possible answers: 'Don't activate', 'Activate') - just as expected.

What I did not expect though was this: the feature gets enabled as soon as the dialog pops up; only when you hit 'Don't activate', it will get disabled again. And to make this even worse: the dialog tends to remain hidden behind maximized windows. In the beginning, it would pop up over my maximized Firefox window, but after I did this several times, it will only "pop under" the Firefox window. So if I didn't know about this, the 'slow keys' feature would now be enabled, I wouldn't know why. If I would now minimize all windows, I would see that dialog; but most users (as I did back then I guess) will freak out and e.g. try to re-login or to reboot the computer, leading to a permanently enabled 'slow keys' feature.

My suggested fix: disable 'Allow to turn accessibility features on and off from the keyboard' by default (I don't think there are really people relying on this), and fix that dialog so it won't enable the 'slow keys' feature until the user has clicked on 'Activate'.

Additionally, the focused button in that dialog should be 'Don't activate' (why focus the 'Help' button?!), and a warning like "WARNING: if you don't know what the Slow Keys feature is, don't enable it! You will have problems with typing when you activate it!" would be nice.

BTW - this is a duplicate: https://bugs.launchpad.net/ubuntu/+bug/41427
this could be a duplicate: https://bugs.launchpad.net/ubuntu/+bug/195805 (I tested it, you also need to hold CTRL+ALT+F1 for a moment when you want to switch consoles with slow keys enabled. I won't test CTRL+ALT+BACKSPACE though ;))

[Juri Pakaste (juri)]

Bryce: I suppose it's plausible the slow keys feature was the reason, although I as I said in the original report, this was related to playing with upstart/sysvinit. I'm pretty certain I didn't visit the slow keys dialog box, but at this point, three Ubuntu releases later, I can't really confirm or deny conclusively :-)

[Lars Kruse (lars-kruse)]

I had this issue with my keyboard not working, and I read this bug report and thought that this was it - but no! Although it gave me some clues.
What happenden to me was that NUMLOCK was turned on (!!!) the problem was that I'm on a Macbook and the keyboard does not have a numloc key. But I had an external keyboard attached and here I turnede numlock on - after detaching the the external keyboard the one on the macbook didn't work no more.
I deleted the setting using just the mouse by deleting the file; ~/.gconf/desktop/gnome/peripherals/keyboard/<computername>/0/%gconf.xml