GNOME Bugzilla – Bug 91535
esd started even when event server is disabled ...
Last modified: 2004-12-22 21:47:04 UTC
This is really broken - and it takes a long time to do, further delaying login. We basically need to ensure we don't call gnome_sound_connection or whatever if the gconf key is disabled; change should be trivial.
Is this actually control-center's fault?
Yes; It's in gnome-settings-daemon which is in control center; Havn't had time to test this patch more than casually which should fix it: Index: gnome-settings-daemon/gnome-settings-sound.c =================================================================== RCS file: /cvs/gnome/gnome-control-center/gnome-settings-daemon/gnome-settings-sound.c,v retrieving revision 1.9 diff -u -p -u -r1.9 gnome-settings-sound.c --- gnome-settings-daemon/gnome-settings-sound.c 8 Aug 2002 04:26:12 -0000 1.9 +++ gnome-settings-daemon/gnome-settings-sound.c 10 Sep 2002 16:09:51 -0000 @@ -73,7 +73,11 @@ start_esd (void) } } -static gboolean set_standby = FALSE; +/* + * TRUE: Stops esd being started just to drop the + * device on the first time in + */ +static gboolean dropped_device = TRUE; /* stop_esd * @@ -84,7 +88,7 @@ stop_esd (void) { /* Can't think of a way to do this reliably, so we fake it for now */ esd_standby (gnome_sound_connection_get ()); - set_standby = TRUE; + dropped_device = TRUE; } /* reload_foreach_cb @@ -153,12 +157,12 @@ apply_settings (void) if (gnome_sound_connection_get () < 0) start_esd (); - else if (set_standby) { + else if (dropped_device) { esd_resume (gnome_sound_connection_get ()); - set_standby = FALSE; + dropped_device = FALSE; } - } else if (!enable_esd && !set_standby) + } else if (!enable_esd && !dropped_device) stop_esd (); if ((enable_esd && event_sounds) &&
Michael: I tested this patch and it starts esd only if the option 'enable sound server startup' is choosen from sound properties. This might solve bug 90719 also.
Other than the variable rename your patch just changes the initial state of set_standby from FALSE to TRUE. After poking at some esd code it seems ok to call resume without suspend (which is possible as a result of this) so the patch goes in to both branches. Thanks
Elliot, could you confirm resuming a non-suspended esd is not a problem ?
Shouldn't be a problem.