[Spice-devel] Bug62033 Add support for --spice-disable-effects client option to spice-vdagent on Linux guests with Gnome3

[Fedor Lyakhov]

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 at redhat.com> 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