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

[Fedor Lyakhov]

Hello Hans,

Finally I've found time to continue with this topic. Have sought for better
solution and only come to improved previous one.

*Requirements*

Let's start with clarifying requirements.
req-1. As a user I want to have my desktop effect settings untouched if
connected under normal conditions.
req-2. As a user I want to have a few desktop effect settings disabled if
connected under bad conditions.
The list of settings shall be configurable (as of now - wallpaper,
animations, font smoothing) - if this isn't true in oVirt, I'd need work on
it as well, because disabling all of them may reduce user experience to
unacceptable level, resulting in feature becoming useless for many users.
Bad conditions can be identified by the user himself (via UI), or
automatically - to be implemented later.

Both these stories taken together implicitly require:
req-3. After connecting under bad conditions and having effects disabled
and then connecting under good conditions, as a user I want my desktop
effect settings restored to their normal (previous) values.

Non-functional requirements:
req-4. Robustness. Crash-proof solution: upon vdagent crash, qemu crash or
forced guest shutdown, correct state of effect settings must be restored
for next session.
req-5. Simplicity. KISS, "Choose simplest possible implementation".

DEs to support:
req-6. Main: Gnome3, KDE4, Unity; Stretch goal: XFce, LXDE

digression {
Or do we need to talk about Window Managers here? Or display servers?
req-7. Solution shall be display server agnostic (X.Org, Wayland, XMir,
Mir...).
req-8. Solution shall be window manager/shell agnostic (Mutter/Gnome Shell,
KWin/Plasma, Compiz/Unity, Cinnamon probably - if we even bother of Ubutu,
why don't respect Mint... etc).

Seems my lack of expertise in display system stacks in Linux is blocking me
here; probably solution cannot be fully WM/shell agnostic. I'm going to try
using DE abstraction level over WM specifics... if this makes sense.

All this profusion of DE/WM/Display servers nowadays results in a fact that
without some standard implemented by them, it won't be possible to support
all of them (and EWMH isn't even near the level of required interop...).
 }

I know you'd like to weaken functional requirements if higher simplicity is
possible. Could you please try specifying these weakened requirements - I
cannot think up them myself.

*Solution.*

Given the fact there are so many different display systems in Linux, it
isn't practically possible to support all of them. On the other hand,
supporting only few and not providing any means for developers of other
systems to add similar support themselves doesn't make sense to me. So I
suggest following architecture:
<vdagent> --DBus-- <DE-specific display effects daemon> -- <DE API for
effects>
Basically vdagent (session, not system one) is to use DBus interface for
toggling effects. The feature will be available only if the interface is
implemented in the system. And this implementation should be DE-specific
and maybe even part of DE. But as we (Spice) are concerned with major DEs,
sample implementation will be provided for Gnome3, KDE4 and Unity.
Eventually I'm going to open tickets for these systems to include the new
DBus interface implementation in their systems (like gnome-desktop-daemon).
This should generate a good feedback upon interface itself (i.e. need to
create an interface acceptable for all these DEs).

Interface (subject to renames):

bool SetMinimumDesktopBackground() // if already minimum, do nothing; save
current desktop background settings; set solid background, saved color (if
none, use default)
bool RestoreDesktopBackground() // if nothing is saved, do nothing; if
solid desktop background, save the color; restore desktop background
settings

bool SetMinimumFontSmooth() // if already minimum, do nothing; save current
font smoothing settings; set antialiasing and hinting to the minimum yet
acceptable level
bool RestoreFontSmooth() // if nothing is saved, do nothing; restore font
smoothing settings

bool SetMinimumAnimations() // if already minimum, do nothing; save current
animation settings; disable all decorative window animation effects, but
keep meaningful animations like spinnings enabled (if possible)
bool RestoreAnimations() // if nothing is saved, do nothing; restore
animation settings


To satisfy functional requirements, vdagent is going to use the interface
in following way:
1. If received VDAgentDisplayConfig with flag to disable an effect, call
appropriate SetMinimumXXX()
2. If received VDAgentDisplayConfig without flag for an effect, call
appropriate RestoreXXX()
One of these is always executed upon user's re-connect (unless failures in
other system parts prevent delivery of VDAgentDisplayConfig message).
This is the same logic VDAgent for Windows is following currently.

This approach makes the implementation in vdagent very simple and
stateless. All effects managing logic is moved to DE-specific module.
Robustness of vdagent is achieved as it is stateless and crashes can affect
only current session. After vdagent restart (e.g. user re-login), correct
state will be restored.

Robustness of display-effects-daemon is achieved via storing all the
settings to DE-specific settings storage (persistent, like a file). The
issues may arise only when crash/failure happens mid-transition. Correct
recovery is achieved using 'transition started' and 'transition
successfully ended' flags, IsRestored and IsMinimum, saved to the same
storage as a first and last steps of transition. For example, when
SetMinimumDesktopBackground() is called:
1)if (storage.get(MinimumDesktopBackground, IsMinimum)) // check last
transition status
  return true;
2)if (!storage.set(StashedDesktopBackground, IsRestored, false)) //
indicate start of transition
  return false;
3)if (!storage.copy(StashedDesktopBackground, DE.GetDesktopBackground()) //
save current settings
   return false;
4)if (!DE.SetDesktopBackground(storage.get(MinimumDesktopBackground)) { //
apply minimum settings
  if(DE.SetDesktopBackground(storage.get(StashedDesktopBackground))) //
restore previous state if possible
    storage.set(StashedDesktopBackground, IsRestored, true);
  return false;
}
5)if(!storage.set(MinimumDesktopBackground, IsMinimum, true)) // finalize
the transition status
  return false;
retrun true;

So in case of crash in any of steps 1-5, the next call of
SetMinimumDesktopBackground() will be executed normally, and restore the
correct state.
In case of failure to set new desktop background, attempt to restore to
saved one will be made (if fails, state will be corrupted -
"IsMinimum=false, IsRestored=false", so any next call of SetMinimum or
Restore will be fully executed again, restoring the state if possible).

Same for RestoreDesktopBackground():
1)if (storage.get(StashedDesktopBackground, IsRestored) // check last
transaction status; by default, IsRestored == true, to catch the case when
SetMinimum is never called.
  return true;
2)if (!storage.set(MinimumDesktopBackground, IsMinimum, false)) // indicate
start of transaction
  return false;
3)if (!storage.set(MinimumDesktopBackground, color,
DE.GetSolidDesktopBackgroundColor())) // save current background color
   return false;
4)if (!DE.SetDesktopBackground(storage.get(StashedDesktopBackground)) { //
apply desktop background settings from stash
  if (DE.SetDesktopBackground(storage.get(MinimumDesktopBackground))) //
restore previous state if possible
    storage.set(MinimumDesktopBackground, IsMinimum, true);
  return false;
}
5)if(!storage.set(StashedDesktopBackground, IsRestored, true)) // finalize
the transaction status
  return false;
retrun true;

Note: I'm by no means an expert in transition failure and recovery
scenarios, I'd love your comments on this approach and welcome better
solutions (mine is just an ad-hoc one).

-- 
Best regards,
Fedor


On Tue, Aug 6, 2013 at 10:16 AM, Hans de Goede <hdegoede at redhat.com> wrote:

> Hi,
>
>
> On 08/06/2013 12:47 AM, Fedor Lyakhov wrote:
>
>> 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).
>>
>
> This windows behavior sounds good, but not something we can easily do
> ...
>
>
>
>> 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.
>>
>
> Doable yes, but what if the agent crashes, or the machine is forced off
> while agent settings are in force, will the agent detects it has crashed
> and restore the user settings from some sort of non volatile storage?
>
> This is likely doable (ignoring possible races wrt crash scenarios), but
> not very KISS. I would like to see a much more KISS solution if possible,
> even if that means it will be less nice.
>
> Regards,
>
> Hans
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130915/1736c035/attachment.html>