Hi On Thu, Oct 2, 2014 at 2:10 PM, Christophe Fergeau <cferg...@redhat.com> wrote:
> Hey, > > On Wed, Aug 27, 2014 at 07:22:07PM +0200, Marc-André Lureau wrote: > > From: Marc-Andre Lureau <marcandre.lur...@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. -- Marc-André Lureau
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
