After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 94049 - gnome-settings-daemon is not activated for each X display
gnome-settings-daemon is not activated for each X display
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: [obsolete] settings-daemon
2.2.x
Other All
: High normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
: 91977 94051 139113 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-09-24 08:09 UTC by Mamatha
Modified: 2007-02-19 17:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
patch to register g-s-d per-display (1.81 KB, patch)
2002-09-30 23:56 UTC, Mark McLoughlin
needs-work Details | Review
new patch (2.19 KB, patch)
2004-12-17 09:47 UTC, Mark McLoughlin
reviewed Details | Review
Same patch against 2.12.1 (1.97 KB, patch)
2006-03-06 12:35 UTC, Michael Witrant
committed Details | Review

Description Mamatha 2002-09-24 08:09:05 UTC
I'm running Sun's beta 2 build 9 source (17th Sep snapshot from CVS).

Workspace switcher doesnot change the ‘workspace’ name when logged in as 
same user on two SunRay clients

I observed the following behavior on Sunray machine.

I tested on a sunray server with 2 clients. 
Lets say s1 - server, c1 - client and c2 - client. I logged in as the same 
user on all the 3 machines (s1, c1 and
c2). 

1. I logged into the machines in the following order: 
c1 first, then into s1 and then into c2.

2. I tried to change the ‘Workspace’ name in s1  and I observed that the 
Workspace name did not change in s1 but it changed in c1 where I had 
logged in 1st.
Comment 1 Mark McLoughlin 2002-09-30 23:55:26 UTC
I'm guessing this is because gnome-settings-daemon doesn't register
itself per-display with bonobo-activation-server. So, instead of
having a g-s-d for every display we only have one.

I'll attach a patch
Comment 2 Mark McLoughlin 2002-09-30 23:56:32 UTC
Created attachment 11322 [details] [review]
patch to register g-s-d per-display
Comment 3 Mark McLoughlin 2002-09-30 23:58:36 UTC
*** Bug 94051 has been marked as a duplicate of this bug. ***
Comment 4 Mark McLoughlin 2002-11-04 00:19:15 UTC
PATCH -> High
Comment 5 Jody Goldberg 2002-11-04 00:46:39 UTC
Sorry for not commenting on this earlier.  The patch is not viable, nor is this
solution with the current code.  We had a choice between having multiple
daemons, one per screen, and designating one of them as the master to handle
the truely singleton operations.   Or the alternative to add a pile of
FOREACH_DISPLAY macro wrappers in the daemon.
Comment 6 Mark McLoughlin 2002-11-04 00:56:53 UTC
Jody: this is intended for registering gnome-settings-daemon per
*display* as opposed to per screen. Granted that's not what the code
does but that's easily fixed ...

I can't think offhand what the problem with having g-s-d per display
is ...
Comment 7 Jody Goldberg 2002-11-04 02:08:01 UTC
The problem is not specific to per display vs per screen.  Multiple copies of
the daemon would get into fights.  There are areas in it that assume they are
the only thing monitoring gconf.

Just off hand I think we can ignore the code that fixes up the mime handlers to
keep text/plain == text/* and now that the accessX stuff uses changesets we're
probably ok there.  However, it is not hard to forsee an area where

Daemon A changes gconf key 1
				Daemon B sees changed key 1 and updates display
Daemon A changes gconf key 2
				Daemon B sees change in display that it just caused
					and updates the gconf keys from the display
				Daemon B changes gconf key 2 to old value

Its not insurmountable but it does get tricky.
Comment 8 Andrew Sobala 2002-11-04 16:34:49 UTC
Removing PATCH keyword since the patch isn't applicable (this _is_ the
correct usage :-))

Jody: Could you look at bug 91575, bug 90726, and bug 91975. I think
they're all duplicates of this bug but it would be nice if you could
check this.
Comment 9 Andrew Sobala 2002-11-06 19:06:13 UTC
*** Bug 91575 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Sobala 2002-11-06 19:06:18 UTC
*** Bug 90726 has been marked as a duplicate of this bug. ***
Comment 11 Andrew Sobala 2002-11-06 19:06:37 UTC
*** Bug 91975 has been marked as a duplicate of this bug. ***
Comment 12 Mark McLoughlin 2002-11-08 01:22:55 UTC
*** Bug 91977 has been marked as a duplicate of this bug. ***
Comment 13 Ghee Teo 2004-08-10 13:04:39 UTC
The worst scenario due to bug is of course when the same user login more than
once into the same Sunray server, on the second login, xscreensaver-lock will
not lock the display because g-s-d has already registered the xscreensaver
service during the first login and has associated with it the DISPLAY one.

The second invocation of xscreensaver-lock then come up with an error saying 
xscreensaver-lock: no xscreensaver associated with dispplay xx:0

I patched that for 2.0 as a sun-patches in the 'gnome-2-0-2' of
sun-patches/gnome-session/560-4780014-s.diff

Is there a better way of doing this? Or is this just another one of those
fundamental design inadequency in the PC-centric world of Desktop :)

Comment 14 Mark McLoughlin 2004-09-20 09:47:04 UTC
Jody, I've never properly understood you argument against the patch. I
understand there might be a logical split in gnome-settings-daemon where some of
the things it does is not per-display, but I don't get the argument about how
fights occur. Isn't it the role of g-s-d to bridge preferences from GConf *to*
other means, rather than the other way around?

The accessX is the only part that seems to break that model AFAICS.

Personally, I'd prefer to make g-s-d per-display and fix any problems that occur
rather than spend another 2 years mulling over the issue.
Comment 15 Mark McLoughlin 2004-12-16 13:54:04 UTC
Okay, this has been languishing for a long time now and the bugs keep rolling in:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141874

I think its time to just commit the patch and see if we really see any bugs with
the per-display approach.
Comment 16 Ghee Teo 2004-12-16 14:06:23 UTC
Arvind has taken your patch, Mark. I am sure he will report any abnormal
bahavior here when we come across them. :) 
Comment 17 Jody Goldberg 2004-12-16 17:12:34 UTC
mark : true, accessX is one of the few areas that also implement server back to
gconf settings for now.  Without an audit I can't name a specific failure but my
suspicion is that any time we are storing related values in multiple keys things
can get into conflict or lost.  However, given that no one is working on making
a single g-s-d multiple display aware you might as well put this in and we'll
see what breaks.  Fixing the problems can't be much worse than implementing a
foreach display loop in lots of places.
Comment 18 Mark McLoughlin 2004-12-17 09:47:20 UTC
Created attachment 34932 [details] [review]
new patch

Okay, so here's a patch to use the new bonobo-activation APIs for this and to
register it per display rather than per screen.
Comment 19 Christian Kirbach 2005-03-28 14:03:26 UTC
any news on this? has it been committed Mark?
Comment 20 Sebastien Bacher 2005-08-07 17:05:45 UTC
Jody could you comment on the new patch?
Comment 21 Jody Goldberg 2005-09-12 14:20:53 UTC
Seems reasonable to me.
Comment 22 Michael Witrant 2006-03-06 12:35:53 UTC
Created attachment 60753 [details] [review]
Same patch against 2.12.1

There is a little difference in 2.12.1 (and probably many other versions) that prevents the previous patch to apply.

I applied this patch and I confirm it solves the configuration problems when running multiple displays. I don't know, however, if it adds any problem.

Any hint about what could fail?
Comment 23 Oliver Grawert 2006-03-06 14:17:23 UTC
i've tested the patch very extensively with ubuntu ltsp with g-s-d 2.13.93 during the dapper development cycle and can only say that it runs very fine. (its one of the loudest complaints i get in edubuntu that you cant easily use it in a kiosk mode (internet cafes etc.) through this bug)
Comment 24 Rodrigo Moya 2006-03-06 15:41:53 UTC
This works perfectly also for me, so, unless someone has anything against it, I'll commit it before the hard freeze tonight.
Comment 25 Rodrigo Moya 2006-03-06 22:41:25 UTC
ok, committed
Comment 26 Jens Granseuer 2007-02-19 17:43:03 UTC
*** Bug 139113 has been marked as a duplicate of this bug. ***