Bug 445898

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Created attachment 305401 [details]
X11 configuration

I'm seeing the same problem on another x86_64 machine hours after I installed F9
on it.  On the other hand, an i386 laptop running rawhide for weeks hasn't
experienced the bug despite me using it a lot.

I can reproduce the duplicate keys on a i386 machine by selecting "slow keys" in
gnome-keyboard-properties.  I just don't use it much to see them turn on
spontaneously.

Reporter, could we get /var/log/Xorg.*.log attached to this bug as well, please?

Thank you

Created attachment 305929 [details]
X11 log

The log is attached.  Please note that Russian keyboard support is not required
to trigger the bug.  Just run gnome-keyboard-properties and select "slow keys",
and you'll see what I mean.

I have enough statistic now, and I haven't seen that slow keys are ever enabled
spontaneously once I turn them off in gnome-keyboard-properties.  I'm using
IceWM window manager, and I suspect that gnome-keyboard-properties starts some
GNOME services that somehow prevent the bug from happening again.

Yet it takes about one hour of active keyboard use (like coding or writing
e-mails) to trigger the slow keys for the first time.  It doesn't appear that
I'm pressing some specific key combination, yet it normally happens in the
middle of some work with the keyboard.

Just it case, my IceWM is shipped by Fedora: icewm-1.2.35-4.fc9

(In reply to comment #8)
> I have enough statistic now, and I haven't seen that slow keys are ever enabled
> spontaneously once I turn them off in gnome-keyboard-properties.  I'm using
> IceWM window manager, and I suspect that gnome-keyboard-properties starts some
> GNOME services that somehow prevent the bug from happening again.
> 
> Yet it takes about one hour of active keyboard use (like coding or writing
> e-mails) to trigger the slow keys for the first time.  It doesn't appear that
> I'm pressing some specific key combination, yet it normally happens in the
> middle of some work with the keyboard.
> 
> Just it case, my IceWM is shipped by Fedora: icewm-1.2.35-4.fc9

I have had the same problem with fvwm. I suspect it is gnome-settings-daemon,
which is causing the problem. For some reason, starting any gnome application
seems to cause gnome to take over everything (changing wallpaper, keyboard
configuration, X resources, screensaver etc.) even though I use fvwm. I noticed
that when I have the problem, gnome-settings-daemon is always running, though I
have not explicitly started it and it does not normally run, when I just log in
with fvwm. I haven't yet figured out what it is that starts gnome-settings-daemon.

*** Bug 448604 has been marked as a duplicate of this bug. ***

Fix for the X server to stop the duplicate key events pushed upstream [1].
Reassigning to g-d-s.

[1]
http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branch&id=ff1a9b7fea2cfe00bc02a99b919fa1178d4f0b12

*** Bug 453399 has been marked as a duplicate of this bug. ***

It would be nice if this was also pushed out as an update (after infrastructure mess clears up, that is).

(In reply to comment #11)
> Fix for the X server to stop the duplicate key events pushed upstream [1].
> Reassigning to g-d-s.
> 
> [1]
> http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branch&id=ff1a9b7fea2cfe00bc02a99b919fa1178d4f0b12

And what are we supposed to be doing with that fix?

I've experienced quite a few times the "auto-repeat keeps going with no key pressed" issue, which has been marked as a duplicate of this bug, but with "slow keys" turned OFF; I've never had "slow keys" on. The workaround mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=448604#c2 works for me as well. I'm using compiz with gnome, not XFCE.

Maybe you should ask Peter Hutterer on the way forward.  I noticed that he committed another, similar change to Xorg GIT a couple of days later.  I'm not sure if it's supposed to fix this and whether that fix is included in Xorg 1.5.  At least I'm still getting these lockups with xorg-x11-server-common-1.5.0-1.fc9.i386.  If it's still relevant, and not included in 1.5.0, you should probably apply it in fedora's Xorg version and push it out to updates-testing.

The fix should be part of 1.5.0.

From previous comments, I gather there are two independent issues:
- SlowKeys turning on unexpectedly
- duplicate key events when on

The latter has (or should have) been fixed in xserver 1.5.0. The former was identified as related to g-d-s (Comment #9). Is this correct?

> The former was identified as related to g-d-s (Comment #9). Is this correct?

No.  I hit this last night and g-d-s was not running (in fact, no process had started recently)

SlowKeys turning on is probably due to the fact that "Allow to turn accessibility features on and off from the keyboard" is enabled in the keyboard preferences, and the shift key (or whatever key combo is set to that) was getting stuck.

I don't see anything for us to do in gnome-settings-daemon (that's "g-s-d", not "g-d-s"). And gnome-settings-daemon is usually running for the duration of a GNOME session, so it's likely already started and listening.

Peter, could you please get the fix into F9 and rawhide's Xorg servers?

> And gnome-settings-daemon is usually running for the duration of a GNOME 
> session, so it's likely already started and listening.

The people hitting this bug are not using GNOME...

(In reply to comment #20)
> > And gnome-settings-daemon is usually running for the duration of a GNOME 
> > session, so it's likely already started and listening.
> 
> The people hitting this bug are not using GNOME...

Then you'll want to double-check whether gnome-settings-daemon was started up by an application requiring it, and if so, check the setting in gnome-keyboard-properties.

Finally!  I've been hitting this bug ever since upgrading to F9, but I had no idea what *exactly* was going on as I've never used GNOME or its accessibility features.  I just thought that input was broken.

In any case, I use FVWM, and I'm 99% positive that gnome-settings-daemon has *not* been running when this happens.  When I fired up gnome-keyboard-properties to look at the setting for "Allow to turn accessibility features on and off from the keyboard", gnome-settings-daemon fired up and changed, among other things, my background and my Firefox keybindings.  As I've never seen this behavior when hitting this bug, I can pretty confidently say that g-s-d was not running when this has happened in the past.

As an aside (and this is probably irrelevant as g-s-d wasn't even running), "Allow to turn accessibility features on and off from the keyboard" is *not* set on my system.

> Then you'll want to double-check whether gnome-settings-daemon was started up
> by an application requiring it

No... gnome-settings-daemon wasn't running and I'm not using GNOME

(In reply to comment #19)
> Peter, could you please get the fix into F9 and rawhide's Xorg servers?

The "duplicate symbols" fix is in xorg-x11-server-Xorg-1.5.0-1.fc10 and
xorg-x11-server-Xorg-1.5.0-1.fc9
https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8032

So far I've been unable to reproduce the "turn on spontaneously" issue. I don't think that g-s-d is at fault, tried several bare setups here and anytime I got SlowKeys to activate, g-s-d also popped up a warning. This is on current rawhide.
As of yet, I have no idea what triggers SlowKeys to turn on.

Is it possible to get a reproducible test-case that triggers the bug?

Unfortunately, I have found no reliable way to trigger this bug.  Sometimes it doesn't happen for days, sometimes it happens several times a day.  When it happens again, are there any log files I should look at that would be relevant?  I've looked at Xorg.0.0log before and seen nothing of interest.

I don't know how I trigger this (I don't start any app when it happens, I'm usually just typing).  But I can force it to happen by holding down SHIFT for an extended period of time.  It wouldn't surprise me if I'm doing that when I do hit this.  If I bring up the gnome keyboard properties, I have "Allow to turn accessibility features on and off from the keyboard" turned off, but then I don't run gnome-settings-daemon.

Thanks for the tip, Andrew.  I've been wondering about the key combination.  I can reproduce this every time by pressing down left shift key for some 5-10 seconds.  This happens on gnome-terminal, firefox, xterm and empty desktop.

Gnome-settings-daemon is not running.  This is the gnome output from when the problem is active:

$ ps auxw | grep gnome
psavola   1840  0.0  0.0   4120   680 pts/6    S+   20:28   0:00 grep gnome
root      3029  0.0  0.3   7760  2592 ?        S    Sep14   0:00
/usr/libexec/gdm-simple-slave --display-id
/org/gnome/DisplayManager/Display1
psavola   3313  0.0  0.2  15536  1952 ?        S    Sep14   0:00
/usr/bin/gnome-keyring-daemon -d --login
psavola   3527  0.0  2.2  89652 17456 ?        Sl   Sep14   0:48
/gnome-terminal --sm-config-prefix /gnome-terminal-CZglN2/ --sm-client-id
26fb5152a-de17-4af5-a65c-563103ef4ae2 --screen 0
/--window-with-profile-internal-id=Default --show-menubar
--role=gnome-terminal-25335-1403740775-1219778938 --active --geometry
/159x47+45+27 --title pekkas@otso:~ --working-directory /home/psavola --zoom 1
psavola   3604  0.0  0.0   2912   592 ?        S    Sep14   0:00

In some cases 'gnome-pty-helper' is also running.  The output differs from 'regular' output in that 'gnome-pty-helper' always seems to be running in the normal case.  But a lockup occurred also when it was running before and afterwards, so this is likely not the root cause..

When the problem is active, running gnome-keyboard-properties gives the following error:

Unable to start the settings manager 'gnome-settings-daemon'.
Without the GNOME settings manager running, some preferences may not take
effect. This could indicate a problem with Bonobo, or a non-GNOME (e.g. KDE)
settings manager may already be active and conflicting with the GNOME
settings manager.

"Allow to turn accessibility features on and off from the keyboard" and Slow keys - "Only accept long keypresses" are unchecked in both working and non-working scenario.  Changing either latter toggle does not fix non-working scenario.

The Xorg log is already attached.

(In reply to comment #27)
> Thanks for the tip, Andrew.  I've been wondering about the key combination.  I
> can reproduce this every time by pressing down left shift key for some 5-10
> seconds.  This happens on gnome-terminal, firefox, xterm and empty desktop.

please do the following. stop gdm, log into TTY1 and then run "xinit -- ". This starts up a plain X server with just xterm. Then see if you can trigger it. If not, start up gnome-terminal and see if you can trigger it.
If you can trigger it now, something pulled in by g-t changes your settings.

> please do the following. stop gdm, log into TTY1 and then run "xinit -- ". This
> starts up a plain X server with just xterm. Then see if you can trigger it. If

Doing this did not trigger the problem

> not, start up gnome-terminal and see if you can trigger it.

Doing this also did not trigger the problem.

I also tried invoking startx from the commandline (which with a .Xclients file launched blackbox as my WM).  I was unable to reproduce the bug there as well.

right. so it's not an X problem then. Need to narrow down which component actually triggers it.

doh. clicked on the wrong component. I'm handing this to control-center for now.

Pardon my ignorance, but what's control-center?  I (along with multiple folks above) have hit this bug using non-GNOME WMs (I use fvwm).  I don't see anything called control-center running, ever.

control-center is the package for gnome-keyboard-properties, which is my best guess so far. AFAICT X doesn't have code that would trigger slowkeys after a timeout, so something must be running and toggling it.


Oh, can you please run xkbcomp :0 - and attach the output here? Maybe that would give us a hint.

(In reply to comment #33)
> Pardon my ignorance, but what's control-center?  I (along with multiple folks
> above) have hit this bug using non-GNOME WMs (I use fvwm).  I don't see
> anything called control-center running, ever.

That's correct but Fedora has (healthy/unhealthy? that would be another discussion) tendency to include a lot of Gnome-related stuff anyway. Could we get output of this command please?

gconftool-2 -R / |grep slowkeys |grep -v Schema

andrew@bill>xkbcomp :0
Warning:          Could not load keyboard geometry for :0
                  BadAlloc (insufficient resources for operation)
                  Resulting keymap file will not describe geometry

resulting output is attached...

andrew@bill>gconftool-2 -R / |grep slowkeys |grep -v Schema
     slowkeys_beep_reject = false
     slowkeys_delay = 300
     slowkeys_beep_press = true
     slowkeys_beep_accept = true
     slowkeys_enable = false

Somebody is enabling AccessX slow keys timeout in XKB.

when this happens, can someone post the output of

ps -ef

?

Created attachment 321291 [details]
output from ps -ef after triggering bug

Created attachment 321293 [details]
xkbcomp :0 output

forgot to actually attach this before...

(In reply to comment #39)
> xkbcomp :0 output

There's nothing in there that'd trigger slowkeys in the server. so it has to be a client.

Created attachment 321357 [details]
ps output with fewer processes

I tried killing stuff to see when the bug would go away.  I ran out of stuff to kill.

oh i wonder if this is the gnome-settings-daemon in gdm's fault?

If you boot to runlevel 3 and startx, does the problem happen?

I tried startx as root and as normal user on runlevel 3, and I could not reproduce the slow keys problem by holding Shift for 10 seconds.  I can reproduce it when logging in using gdm on runlevel 5.

okay this is a gdm/gnome-settings-daemon problem then.

My guess is gdm's g-s-d enables accessx for users at the login screen, but then doesn't disable it before starting the session.

g-s-d should probably turn it off in its exit path.

(In reply to comment #44)
> okay this is a gdm/gnome-settings-daemon problem then.
> 
> My guess is gdm's g-s-d enables accessx for users at the login screen, but then
> doesn't disable it before starting the session.
> 
> g-s-d should probably turn it off in its exit path.

sudo -u gdm gconftool-2 -s /apps/gdm/simple-greeter/settings-manager-plugins/a11y-keyboard/active -t bool false

seems to fix it for me. At least it no longer switches to slow keys when I hold shift down for 8 seconds, as it did before. It seems rather ugly, that I have to run gconftool-2 as user gdm rather than as myself or as root, but the simple greeter runs as user gdm, so that is where it gets its resources from.

This certainly seems to imply that Ray's explanation is correct.

Holding Shift doesn't seem to trigger the bug anymore (Fedora 9, all up-to-date).  I'll keep running an X session with IceWM without having run gnome-keyboard-properties to see if the bug is gone.  As I mentioned, it takes hours of keyboard activity to trigger slow keys for me.

The bug is gone.  I've been using that machine for 2 days.  It would normally happen much earlier.

Well, the bug is not gone, just managed to stop buggy behavior, but we should probably make it default or clean up the mess if we did it. Ray?

Thanks for testing anyway.

(In reply to comment #47)
> The bug is gone.  I've been using that machine for 2 days.  It would normally
> happen much earlier.

Pavel, is that with my workaround or without it?

Since I applied the workaround over two weeks ago, the problem has not reoccurred, which is much much longer than I ever had before without it occurring. So I think Ray's analysis of the problem is correct.

Any chance of a version of g-s-d being rolled out that turns off accessx before exiting? That would be better than having to disable it like I am doing (though it makes no difference to me personally).

That's without any workarounds.  Actually, I tried your workaround and it didn't work.  That is, holding Shift would still activate the slow keys.  However, I updated the system after that, and I could not reproduce the problem at all, so I assumed it was fixed.  I haven't seen it happening ever since.

(In reply to comment #50)
> That's without any workarounds.  Actually, I tried your workaround and it
> didn't work.  That is, holding Shift would still activate the slow keys. 
> However, I updated the system after that, and I could not reproduce the problem
> at all, so I assumed it was fixed.  I haven't seen it happening ever since.

You did log out and log back in again after applying the workaround, didn't you? It only takes effect, the next time you log in. And after you tested it, did you run the command again with "true" instead of "false" in order to go back to the normal state?

I understand now that I misunderstood the way the workaround works.  Nothing is really fixed.  Once I set that value to "true" and re-login, holding Shift would turn on slow keys.

*** Bug 475432 has been marked as a duplicate of this bug. ***

So it looks like there are two problems here:

1) the g-s-d keyboard a11y plugin doesn't reset the accessX bits to off when it's deactivated
2) g-s-d doesn't deactivate it's plugins before dying upon getting SIGTERM

This should be good to go now, but I would appreciate it if someone affected would test the changes.  I've pushed builds for F-9, F-10, and rawhide

gnome-settings-daemon-2.22.2.1-3.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/gnome-settings-daemon-2.22.2.1-3.fc9

gnome-settings-daemon-2.24.1-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gnome-settings-daemon-2.24.1-4.fc10

Created attachment 326418 [details]
Shutdown cleanly on SIGTERM and restore xkb state on shutdown

For reference, the patch is here.

I'm stilling hitting the bug with 2.24.1-4 on F10

(In reply to comment #59)
> I'm stilling hitting the bug with 2.24.1-4 on F10

Same for me. I did some extra tests with Ray's patch installed. I added some extra logging using syslog, so I could tell if it was actually calling the function gsd_a11y_keyboard_manager_stop. It wasn't.

However, when I watched gnome-settings-daemon with gdb, this function was called and then Ray's patch worked. i.e. I couldn't reproduce the error.

So I think that Ray's patch is a step forward. I guess he has killed one bug, only to reveal the next one!

So why isn't gsd_a11y_keyboard_manager_stop getting called when gnome-settings-daemon shuts down unless I am debugging? Perhaps a different signal is being raised?

I am also testing on F10. Can anyone test on F9? Or have we all upgraded already? It should be just enought to select something like fvwm as window manager. I guess any window manager which doesn't start its own gnome-settings-daemon?

The reason I am curious about this is I have noticed a new problem with F10 that I didn't have with F9. I have defined CTRL-cursor_keys to switch desktops and sometimes this stops responding and a few other things associated with the window manager. I am wondering if this is something else that gnome-settings-daemon is failing to restore? Perhaps it is dying before it has finished calling all the deactivate functions for the plugins? I should say that this new problem occurred before I applied Ray's patch and it has also occurred once since. So I think it has nothing to do with that problem.

My guess is that Ray's patch is correct and does the right thing, but something else is broken.

yea, I just set up a reproduction environment and it looks like it's exiting from somewhere inside libdbus.

Investigating...

ah so what's probably going on here is that gnome-settings-daemon is doing

dbus_connection_set_exit_on_disconnect (connection, TRUE)

so it's exiting when the dbus-daemon goes away.

What it really should do is

dbus_connection_set_exit_on_disconnect (connection, FALSE)

then listen for the disconnect and quit the main loop.

I'll see if that fixes the problem.

Okay, that seemed to fix the problem.

Packages building now.

gnome-settings-daemon-2.24.1-7.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gnome-settings-daemon'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11131

gnome-settings-daemon-2.22.2.1-4.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update gnome-settings-daemon'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-11133

gnome-settings-daemon-2.24.1-4.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gnome-settings-daemon'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11175

(In reply to comment #64)
> gnome-settings-daemon-2.24.1-7.fc10 has been pushed to the Fedora 10 testing
> repository.  If problems still persist, please make note of it in this bug
> report.
>  If you want to test the update, you can install it with 
>  su -c 'yum --enablerepo=updates-testing update gnome-settings-daemon'.  You
> can provide feedback for this update here:
> http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11131

That solves the problem for me on F10. Thanks Ray. You did a great job.

Also, my other problem of CTRL + cursor keys not working as I had set it up turned out to be a change in a keycode between F9 and F10, which resulted in a modifier being incorrectly set from my .Xmodmap. Once I fixed that, that problem was gone too.

So I think you have solved all the bugs in gnome-settings-daemon that I have had problems with. Once again, thanks.

*** Bug 481154 has been marked as a duplicate of this bug. ***

gnome-settings-daemon-2.24.1-4.fc10 still has the problem.  gnome-settings-daemon-2.24.1-7.fc10 is OK, but it's not available from the "updates" or even "updates-testing" repository.  Something is wrong here.  gnome-settings-daemon-2.24.1-4.fc10 was released and announced after gnome-settings-daemon-2.24.1-7.fc10.  gnome-settings-daemon-2.24.1-4.fc10 has a higher Update ID than gnome-settings-daemon-2.24.1-7.fc10.  It looks like we have a broken version superseding a fixed version.

The problem has happened to me with no gnome-settings-daemon running (I normally don't have or want g-s-d running in my environment). I'd be willing to try updating g-s-d, but I don't see how it'd affect triggering the problem.

Actually, my problems with gnome-settings-daemon were caused by old .desktop files in ~/.config/autostart directory. Either some Betas on this notebook didn't job properly, or we have broken upgrade path. After rm ~/.config/autostart/*.desktop and restart of X, g-s-d works.

(In reply to comment #70)
> The problem has happened to me with no gnome-settings-daemon running (I
> normally don't have or want g-s-d running in my environment). I'd be willing to
> try updating g-s-d, but I don't see how it'd affect triggering the problem.

Are you sure that you never had g-s-d running at all? Not even before you log in? I had the problem because the gdm login window was starting g-s-d and leaving things in an incorrect state when it passed control over to my user session. I wasn't running g-s-d in the user session. It was only running under the gdm account. That is why my workaround (see comment #45) needed a "sudo -u gdm" to disable the setting, because it had to be disabled for the gdm account not for the user account. The settings of my own account were irrelevant, because I wasn't starting g-s-d from my own acount. Indeed starting g-s-d from my own account fixed the problem (but also did other things that I didn't want).

I got gnome-settings-daemon-2.24.1-7.fc10 from updates-testing with the method described in comment #66 back on the 11th December and I haven't had any problem since and I disabled my workaround in order to test this version of g-s-d and haven't bothered to reactivate it. Is that version no longer available?

gnome-settings-daemon-2.24.1-7.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.