Hello Hans,
Finally I've found time to continue with this topic. Have sought for better solution and only come to improved previous one.
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.
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.
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
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 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@xxxxxxxxxx> wrote:
Hi,This windows behavior sounds good, but not something we can easily do
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).
...Doable yes, but what if the agent crashes, or the machine is forced off
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.
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
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel