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

Hans de Goede hdegoede at redhat.com
Sun Jul 28 23:26:28 PDT 2013


Hi,

On 07/28/2013 10:43 PM, Fedor Lyakhov wrote:
> Hi,
>
> Bug62033 is a request by Gnome3 developers. They need means to detect
> that spice client runs locally so they shouldn't disable any desktop
> effects on the guest running Gnome3. On the other hand, for slow
> remote connections, they want to disable the effects.
>
> My solution approaches the question from another side: allow user to
> decide whether he needs the effects or not. Sure, he can configure the
> guest manually as he wants, but it isn't very convenient.

Many thanks for working on this!

>
> The user interface for this task already exists in Spice GTK client,
> this is CLI option '--spice-disable-effects=<wallpaper, font-smooth,
> animation, all>. Right now this options works for Windows guest only.
> In next patch series I add following:
> 0001. Unrelated small fix

Added to my local repo and pushed to the official repo.

> 0002. Announce capabilities of Display Config in spice-vdagentd system
> daemon, handle Display Config message in spice-vdagentd - send it to
> spice-vdagent session daemon

Looks good.

> 0003. Handle Display Config message in spice-vdagent - implementation
> uses GSettings API from GIO 2.26+; at run-time: xsettings plugin for
> gnome-settings-manager should be installed and enabled - otherwise
> font smooth won't be affected.
> Better implementation with g_settings_get_range() introspection to get
> enum nicks requires GIO 2.28+ - I need approval on this.

2.28 is too new, 2.26 is the newest version we can require given
the various distros we want to support. Note there is no need to do
conditionally enable the code based on 2.26 being there and too support
even older glib versions. 2.26 as a requirement is fine, newer is not.

>
> Please note patches 2, 3 are for review mostly, the feature isn't
> complete yet: user doesn't have convenient means to restore the
> effects once they're disabled. I see 2 potential solutions (better
> ideas are welcome!):
>
> (i) Introduce '--spice-reset-effects' option.
> We don't want to change protocol, and there is one possibility to
> explore - send Display Config with empty flags to indicate the reset
> is required.
> Right now Display Config is sent regardles of --spice-reset-effects
> and --spice-color-depth options - i.e. empty one is sent when the
> options aren't set. I want to make this empty Display Config to be
> sent only when --spice-reset-effects option is enabled (need to check
> whether this is acceptable at Windows agent). I've added handling code
> of this case to vdagent: reset all the settings we change to default
> (it is commented out for now). There are following limitations I know
> about:
> 1. Inability to set color depth and reset effects in one connection
> (not that bad - reset can be done once, then re-connect with desired
> color depth; also color depth change isn't supported on Linux guests
> yet)
> 2. If new flags are added to Display Config, all them need to be
> treated the same way, i.e. reset should reset them all (there can be
> only 1 reset message, flags=0).

I would prefer to have a VD_AGENT_DISPLAY_CONFIG_FLAG_RE_ENABLE_ALL or
some such rather then an empty 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?

I also wonder how the windows agent handles this, does it maybe see the
lack of a VD_AGENT_DISPLAY_CONFIG_FLAG_DISABLE_* flag as indication to
enable things ?

<snip>

 > Note1: Fedora 19 with Spice graphics at Host-1 crashes at startup,
 > haven't tried at Host-2.

Sounds like a known issue, have you installed all updates for Fedora-19 ?

 > 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?

Regards,

Hans



Regards,

Hans


More information about the Spice-devel mailing list