Bug 445898 - Slow keys turn on spontaneously, output two symbols at once
Slow keys turn on spontaneously, output two symbols at once
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
: 448604 453399 475432 481154 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-09 14:08 EDT by Pavel Roskin
Modified: 2009-01-29 18:04 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-29 18:04:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X11 configuration (864 bytes, text/plain)
2008-05-14 16:23 EDT, Pavel Roskin
no flags Details
X11 log (48.48 KB, text/plain)
2008-05-19 07:31 EDT, Pavel Roskin
no flags Details
output from ps -ef after triggering bug (8.94 KB, text/plain)
2008-10-23 10:27 EDT, Andrew Schultz
no flags Details
xkbcomp :0 output (39.87 KB, text/plain)
2008-10-23 10:28 EDT, Andrew Schultz
no flags Details
ps output with fewer processes (5.01 KB, text/plain)
2008-10-23 19:46 EDT, Andrew Schultz
no flags Details
Shutdown cleanly on SIGTERM and restore xkb state on shutdown (6.88 KB, patch)
2008-12-09 17:33 EST, Ray Strode [halfline]
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 564042 None None None Never
GNOME Desktop 564045 None None None Never

  None (edit)
Description Pavel Roskin 2008-05-09 14:08:20 EDT
Description of problem:

Every day or so the keyboard becomes essentially useless in X.  When pressing a
key for a short time, it's not accepted.  If the key is pressed for about half a
second, the key is accepted twice (i.e. when holding "j", "jj" appears) and then
the usual autorepeat starts.

It's possible to turn it off by going to keyboard properties in the GNOME
control center and turning off "slow keys".  Please note that I don't enable
"slow keys" by default.

Version-Release number of selected component (if applicable):
xorg-x11-drv-keyboard-1.3.0-3.fc9

How reproducible:
Once a day when actively using the keyboard.

Steps to Reproduce:
1. Use the X server for a day or so.  Typing something seems to inclrease the
chances of it happening.
  
Actual results:
The keys are accepted only after a pause and only as sequences of two or more
presses.

Expected results:
No change in the keyboard behavior.

Additional info:
The problem can be reproduced reliably by turning slow keys in the GNOME control
center on, off and on again.  When turning slow keys on for the first time, the
behavior is correct (one character after the pause).  When turning slow keys on
for the second time, the behavior is incorrect (two characters after the pause).

I tries both PS/2 and USB keyboards, and it made no difference.  Disconnecting
the USB keyboard and connecting it again doesn't fix the problem.

I've seen the X server going down a few seconds after spontaneous enabling of
the slow keys.  It happened to me twice.  Normally the X server keeps working.
Comment 1 Bug Zapper 2008-05-14 06:55:49 EDT
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
Comment 2 Pavel Roskin 2008-05-14 16:23:38 EDT
Created attachment 305401 [details]
X11 configuration
Comment 3 Pavel Roskin 2008-05-14 16:26:33 EDT
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.
Comment 4 Pavel Roskin 2008-05-14 17:00:40 EDT
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.
Comment 5 Matěj Cepl 2008-05-16 19:15:05 EDT
Reporter, could we get /var/log/Xorg.*.log attached to this bug as well, please?

Thank you
Comment 6 Pavel Roskin 2008-05-19 07:31:14 EDT
Created attachment 305929 [details]
X11 log
Comment 7 Pavel Roskin 2008-05-19 07:33:52 EDT
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.
Comment 8 Pavel Roskin 2008-05-20 16:57:21 EDT
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
Comment 9 nvwarr 2008-06-27 09:21:13 EDT
(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.
Comment 10 Peter Hutterer 2008-07-24 04:17:06 EDT
*** Bug 448604 has been marked as a duplicate of this bug. ***
Comment 11 Peter Hutterer 2008-07-24 04:19:44 EDT
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

Comment 12 Peter Hutterer 2008-08-21 03:12:54 EDT
*** Bug 453399 has been marked as a duplicate of this bug. ***
Comment 13 Pekka Savola 2008-08-21 05:27:51 EDT
It would be nice if this was also pushed out as an update (after infrastructure mess clears up, that is).
Comment 14 Bastien Nocera 2008-09-14 08:39:31 EDT
(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?
Comment 15 Vasile Gaburici 2008-09-14 09:05:23 EDT
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.
Comment 16 Pekka Savola 2008-09-14 10:24:31 EDT
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.
Comment 17 Peter Hutterer 2008-09-14 19:04:04 EDT
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?
Comment 18 Andrew Schultz 2008-09-15 13:08:08 EDT
> 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)
Comment 19 Bastien Nocera 2008-09-15 15:33:45 EDT
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?
Comment 20 Andrew Schultz 2008-09-15 15:52:20 EDT
> 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...
Comment 21 Bastien Nocera 2008-09-15 17:52:29 EDT
(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.
Comment 22 Joshua Baker-LePain 2008-09-15 18:33:21 EDT
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.
Comment 23 Andrew Schultz 2008-09-15 20:28:41 EDT
> 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
Comment 24 Peter Hutterer 2008-09-16 00:31:46 EDT
(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?
Comment 25 Joshua Baker-LePain 2008-09-16 11:27:57 EDT
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.
Comment 26 Andrew Schultz 2008-09-16 12:41:54 EDT
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.
Comment 27 Pekka Savola 2008-09-16 13:47:18 EDT
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.
Comment 28 Pavel Roskin 2008-09-17 11:39:13 EDT
The Xorg log is already attached.
Comment 29 Peter Hutterer 2008-10-22 22:47:41 EDT
(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.
Comment 30 Andrew Schultz 2008-10-22 23:51:37 EDT
> 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.
Comment 31 Peter Hutterer 2008-10-23 00:36:07 EDT
right. so it's not an X problem then. Need to narrow down which component actually triggers it.
Comment 32 Peter Hutterer 2008-10-23 00:37:34 EDT
doh. clicked on the wrong component. I'm handing this to control-center for now.
Comment 33 Joshua Baker-LePain 2008-10-23 00:49:07 EDT
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.
Comment 34 Peter Hutterer 2008-10-23 01:04:15 EDT
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.
Comment 35 Matěj Cepl 2008-10-23 02:21:09 EDT
(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
Comment 36 Andrew Schultz 2008-10-23 09:31:44 EDT
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
Comment 37 Ray Strode [halfline] 2008-10-23 09:52:01 EDT
Somebody is enabling AccessX slow keys timeout in XKB.

when this happens, can someone post the output of

ps -ef

?
Comment 38 Andrew Schultz 2008-10-23 10:27:13 EDT
Created attachment 321291 [details]
output from ps -ef after triggering bug
Comment 39 Andrew Schultz 2008-10-23 10:28:19 EDT
Created attachment 321293 [details]
xkbcomp :0 output

forgot to actually attach this before...
Comment 40 Peter Hutterer 2008-10-23 18:40:49 EDT
(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.
Comment 41 Andrew Schultz 2008-10-23 19:46:37 EDT
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.
Comment 42 Ray Strode [halfline] 2008-10-24 09:26:10 EDT
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?
Comment 43 Pavel Roskin 2008-10-24 17:15:38 EDT
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.
Comment 44 Ray Strode [halfline] 2008-10-24 17:27:43 EDT
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.
Comment 45 nvwarr 2008-11-04 07:10:16 EST
(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.
Comment 46 Pavel Roskin 2008-11-10 23:17:07 EST
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.
Comment 47 Pavel Roskin 2008-11-12 23:43:09 EST
The bug is gone.  I've been using that machine for 2 days.  It would normally happen much earlier.
Comment 48 Matěj Cepl 2008-11-13 03:57:21 EST
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.
Comment 49 nvwarr 2008-11-21 11:18:06 EST
(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).
Comment 50 Pavel Roskin 2008-11-21 11:32:12 EST
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.
Comment 51 nvwarr 2008-11-24 12:09:58 EST
(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?
Comment 52 Pavel Roskin 2008-11-24 21:33:55 EST
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.
Comment 53 Ray Strode [halfline] 2008-12-09 10:54:37 EST
*** Bug 475432 has been marked as a duplicate of this bug. ***
Comment 54 Ray Strode [halfline] 2008-12-09 14:04:12 EST
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
Comment 55 Ray Strode [halfline] 2008-12-09 17:28:23 EST
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
Comment 56 Fedora Update System 2008-12-09 17:29:46 EST
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
Comment 57 Fedora Update System 2008-12-09 17:30:39 EST
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
Comment 58 Ray Strode [halfline] 2008-12-09 17:33:29 EST
Created attachment 326418 [details]
Shutdown cleanly on SIGTERM and restore xkb state on shutdown

For reference, the patch is here.
Comment 59 Andrew Schultz 2008-12-09 18:52:26 EST
I'm stilling hitting the bug with 2.24.1-4 on F10
Comment 60 nvwarr 2008-12-10 02:16:21 EST
(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.
Comment 61 Ray Strode [halfline] 2008-12-10 14:31:43 EST
yea, I just set up a reproduction environment and it looks like it's exiting from somewhere inside libdbus.

Investigating...
Comment 62 Ray Strode [halfline] 2008-12-10 14:36:18 EST
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.
Comment 63 Ray Strode [halfline] 2008-12-10 15:06:29 EST
Okay, that seemed to fix the problem.

Packages building now.
Comment 64 Fedora Update System 2008-12-11 02:56:08 EST
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
Comment 65 Fedora Update System 2008-12-11 02:57:33 EST
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
Comment 66 Fedora Update System 2008-12-11 03:03:07 EST
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
Comment 67 nvwarr 2008-12-11 06:51:25 EST
(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.
Comment 68 Matěj Cepl 2009-01-27 20:56:14 EST
*** Bug 481154 has been marked as a duplicate of this bug. ***
Comment 69 Pavel Roskin 2009-01-27 22:06:43 EST
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.
Comment 70 Pat Gunn 2009-01-28 00:13:29 EST
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.
Comment 71 Matěj Cepl 2009-01-28 04:34:05 EST
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.
Comment 72 nvwarr 2009-01-29 01:30:05 EST
(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?
Comment 73 Fedora Update System 2009-01-29 18:04:11 EST
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.

Note You need to log in before you can comment on or make changes to this bug.