GNOME Bugzilla – Bug 94049
gnome-settings-daemon is not activated for each X display
Last modified: 2007-02-19 17:43:03 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.
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
Created attachment 11322 [details] [review] patch to register g-s-d per-display
*** Bug 94051 has been marked as a duplicate of this bug. ***
PATCH -> High
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.
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 ...
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.
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.
*** Bug 91575 has been marked as a duplicate of this bug. ***
*** Bug 90726 has been marked as a duplicate of this bug. ***
*** Bug 91975 has been marked as a duplicate of this bug. ***
*** Bug 91977 has been marked as a duplicate of this bug. ***
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 :)
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.
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.
Arvind has taken your patch, Mark. I am sure he will report any abnormal bahavior here when we come across them. :)
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.
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.
any news on this? has it been committed Mark?
Jody could you comment on the new patch?
Seems reasonable to me.
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?
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)
This works perfectly also for me, so, unless someone has anything against it, I'll commit it before the hard freeze tonight.
ok, committed
*** Bug 139113 has been marked as a duplicate of this bug. ***