[Spice-devel] [vdagent-linux 1/2] randr: remove monitors.xml on auto-configuration

[Christophe Fergeau]

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 <cfergeau at redhat.com>
> wrote:
> 
> > Hey,
> >
> > On Wed, Aug 27, 2014 at 07:22:07PM +0200, Marc-André Lureau wrote:
> > > From: Marc-Andre Lureau <marcandre.lureau at redhat.com>
> > >
> > > 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
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.
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?

If all of that is correct, and given that we don't own monitors.xml, I'd
prefer not to have this patch upstream.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20141008/f45fbcbf/attachment.sig>