On Wed, Oct 8, 2014 at 1:11 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote:
You make it sound like it's only an issue when running GNOME2. If youOn 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 <cfergeau@xxxxxxxxxx>
> wrote:
>
> > Hey,
> >
> > On Wed, Aug 27, 2014 at 07:22:07PM +0200, Marc-André Lureau wrote:
> > > From: Marc-Andre Lureau <marcandre.lureau@xxxxxxxxxx>
> > >
> > > 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.
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 Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel