Hi, I've finally looked in vdagent for Windows and find out that it works differently. From a quick grasp I get following: Vdagent for Windows applies settings listed --disable-effects=... to current session via WinAPI call For settings not listed there, a reload is done - settings are restored to values from Windows registry of current active user (looks like API call that disables them doesn't affect register, at least that place). So my question is - should I stick with the plan (i), or go for the approach as at Windows vdagent (similar to my previous idea (ii))? Instead of implementing '--reset-effects' option I need to store values of settings somewhere before disabling them and restore them back when connected without setting listed in --disable-effects. Preserving user changes is a challenge. I think it should be doable though - at least via implementing similar environment to Windows case - vdagent will need to maintain an analog of Windows register storage for effect settings and track user changes of their real counterparts of Gnome settings... Seems doable using GSettings. Maybe developers of vdagent for Windows can step in? We need your advise! Also looks like oVirt use case should be of our primary concern - and with (i) we need to update code there as well (to support new option, --reset-effects). For (ii) no changes in oVirt are required (seems so). On Tue, Jul 30, 2013 at 1:57 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > On 07/29/2013 10:50 PM, Fedor Lyakhov wrote: > > <snip> > > >>> I would prefer to have a VD_AGENT_DISPLAY_CONFIG_FLAG_RE_ENABLE_ALL or >>> some such rather then an empty message. >> >> >> My idea was based on preserving current protocol - if it is OK to >> introduce new message, I'm willing to do so. > > > Not a new message, just a new flag inside the existing message. > > >> >>> >>>> (ii) Make vdagent stateful - remember that previous connection was >>>> disabling some effects, and if current one isn't disabling these >>>> effects, reset them. No need for '--spice-reset-effects' option in >>>> this case. We can even remember previous states of effects and restore >>>> them instead of resetting them to default. This seems to be the most >>>> user-friendly approach, but it is harder to implement. If this >>>> approach is selected, I see implementation via GSettings (afaik there >>>> is no config for vdagent right now, correct?) >>> >>> >>> >>> I would not go here, --spice-disable-effects is mostly used by the >>> ovirt user-portal which does this without the user knowing, so the user >>> is not really aware this is happening, what if the user changes some >>> settings after the agent has made its changes, then the client >>> disconnecting >>> will restore the wrong settings? >> >> >> Ok, I'll go with (i). >> I don't have experience with ovirt user-portal - need to look into it >> probably. One concern: I find --spice-disable-effects=font-smooth >> really annoying - font quality is extremely degraded (even without >> setting hinting to none)... As a user I wouldn't like this to happen >> behind the scenes without my opinion asked - guess I need to check >> ovirt workflow here. Is --spice-disable-effects usage in ovirt >> configurable by e.g. administrator? > > > AFAIK it is enabled automatically when the user indicates he is on > a slow (wan) connection. > > <snip> > > >>>> Note2: I've got 100% reproducible crash at Host-1 Guest1.1: qemu >>>> crashes in following scenario1: >>>> 1. Start VM, connect with Spice client, open System >>>> settings->Background, select new background [or just open >>>> dconf-editor], close it >>>> 2. Re-connect client >>>> 3. Open System settings->Background->select background [or open >>>> dconf-editor] -> VM crashes >>>> Scenario2: >>>> 1. Start VM, connect with Spice client, open System >>>> settings->Background->select new background (do not close the window) >>>> 2. Re-connect client -> VM crashes >>>> It seems to be unrelated to my changes though, because it is >>>> reproducible even without vdagentd/vdagent running. Does anybody know >>>> whether it is >>>> already reported? >>> >>> >>> This sounds like a new bug, can you file a bug for this please? >>> >> OK, sure. What do I need to do to collect enough debug information >> about the crash? I've never debugged qemu/spice server... > > > Just step-by-step reproduction instructions is enough for now, if > this is reproducable we should be able to reproduce ourselves, and > then we can get all the info we need. > > Regards, > > Hans -- Best regards, Fedor _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel