<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 1:11 PM, Christophe Fergeau <span dir="ltr"><<a href="mailto:cfergeau@redhat.com" target="_blank">cfergeau@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Wed, Oct 08, 2014 at 12:28:53PM +0200, Marc-André Lureau wrote:<br>
> Hi<br>
><br>
> On Thu, Oct 2, 2014 at 2:10 PM, Christophe Fergeau <<a href="mailto:cfergeau@redhat.com">cfergeau@redhat.com</a>><br>
> wrote:<br>
><br>
> > Hey,<br>
> ><br>
> > On Wed, Aug 27, 2014 at 07:22:07PM +0200, Marc-André Lureau wrote:<br>
> > > From: Marc-Andre Lureau <<a href="mailto:marcandre.lureau@redhat.com">marcandre.lureau@redhat.com</a>><br>
> > ><br>
> > > GNOME will restore monitors.xml configuration whenever the timestamp<br>
> > > "config > change". The "change" timestamp is the last user applied<br>
> > > configuration, whereas the "config" timestamp is updated when<br>
> > > the screen is updated or ouput/crtc modes are added/removed.<br>
> > ><br>
> > > These condition are triggered by vdagent during monitor config. Since we<br>
> > > can't control the timestamps (playing with delay will be inherently<br>
> > > event more racy), the only sane way I can think of is to disable gsd<br>
> > > behaviour. This can be achieved by deleting the ~/.config/monitors.xml,<br>
> > > which is the intended configuration to restore, so vdagent will override<br>
> > > whatever configuration was saved previously.<br>
> > ><br>
> > > Somehow, if vdagent would be better integrated with gnome2, it would use<br>
> > > the gnome-rr and/or org.gnome.SettingsDaemon.XRANDR dbus<br>
> > > API. Thanksfully, in gnome3, the monitor auto-configuration has been<br>
> > > merged in.<br>
> ><br>
> > Actually a bit curious how this relates to<br>
> > <a href="https://bugzilla.gnome.org/show_bug.cgi?id=706735" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=706735</a> which seems to have<br>
> > added a hack to avoid similar situations ?<br>
> ><br>
> ><br>
> There is a similar timestamp check in gsd. However, when enabling monitors<br>
> with vdagent, the timestamps are very close and there is a race between<br>
> vdagent & gsd: you get random results. With the proposed patch, spice<br>
> client = vdagent wins over gsd when it wants to set some config.<br>
<br>
</div></div>You make it sound like it's only an issue when running GNOME2. If you<br></blockquote><div><br></div><div>I already mentionned recent gnome3 auto-config has been merged in (last year) and don't reach the issue (no related code).<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
tested with gnome-settings-daemon in RHEL6, the relevant (if I looked in<br>
the right place!) code seems different from upstream because of a<br>
downstream patch.<br></blockquote><div><br></div><div>You are correct, showing that this part of gsd code doesn't have a clean solution and needs various workarounds.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I also assume it will not be an issue either when<br>
monitor configuration is not done through the agent but through<br>
qxl/client monitor config?<br></blockquote><div><br></div><div>What do you mean? Monitor are only enabled through vdagent here.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If all of that is correct, and given that we don't own monitors.xml, I'd<br>
prefer not to have this patch upstream.<br></blockquote><div><br></div><div>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.<br clear="all"></div></div><br>-- <br>Marc-André Lureau
</div></div>