On Wed, Oct 8, 2014 at 1:11 PM, Christophe Fergeau <[email protected]> wrote:
> On Wed, Oct 08, 2014 at 12:28:53PM +0200, Marc-André Lureau wrote: > > Hi > > > > On Thu, Oct 2, 2014 at 2:10 PM, Christophe Fergeau <[email protected]> > > wrote: > > > > > Hey, > > > > > > On Wed, Aug 27, 2014 at 07:22:07PM +0200, Marc-André Lureau wrote: > > > > From: Marc-Andre Lureau <[email protected]> > > > > > > > > GNOME will restore monitors.xml configuration whenever the timestamp > > > > "config > change". The "change" timestamp is the last user applied > > > > configuration, whereas the "config" timestamp is updated when > > > > the screen is updated or ouput/crtc modes are added/removed. > > > > > > > > These condition are triggered by vdagent during monitor config. > Since we > > > > can't control the timestamps (playing with delay will be inherently > > > > event more racy), the only sane way I can think of is to disable gsd > > > > behaviour. This can be achieved by deleting the > ~/.config/monitors.xml, > > > > which is the intended configuration to restore, so vdagent will > override > > > > whatever configuration was saved previously. > > > > > > > > Somehow, if vdagent would be better integrated with gnome2, it would > use > > > > the gnome-rr and/or org.gnome.SettingsDaemon.XRANDR dbus > > > > API. Thanksfully, in gnome3, the monitor auto-configuration has been > > > > merged in. > > > > > > Actually a bit curious how this relates to > > > https://bugzilla.gnome.org/show_bug.cgi?id=706735 which seems to have > > > added a hack to avoid similar situations ? > > > > > > > > There is a similar timestamp check in gsd. However, when enabling > monitors > > with vdagent, the timestamps are very close and there is a race between > > vdagent & gsd: you get random results. With the proposed patch, spice > > client = vdagent wins over gsd when it wants to set some config. > > You make it sound like it's only an issue when running GNOME2. If you > I already mentionned recent gnome3 auto-config has been merged in (last year) and don't reach the issue (no related code). tested with gnome-settings-daemon in RHEL6, the relevant (if I looked in > the right place!) code seems different from upstream because of a > downstream patch. > You are correct, showing that this part of gsd code doesn't have a clean solution and needs various workarounds. > I also assume it will not be an issue either when > monitor configuration is not done through the agent but through > qxl/client monitor config? > What do you mean? Monitor are only enabled through vdagent here. > > If all of that is correct, and given that we don't own monitors.xml, I'd > prefer not to have this patch upstream. > This patch does not harm, we don't want gsd to race with vdagent: vdagent should win over for auto-conf/resize to work properly. -- Marc-André Lureau
_______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
