Hi
--
Marc-André Lureau
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.
--
Marc-André Lureau
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel