[Spice-devel] Questions regarding Bug 62033 - Means to detect local-only

[Fedor Lyakhov]

Hello everyone,

I continue working on this "bug62033 means to detect local only" issue, and
want to confirm whether I'm going in the right direction so the result can
be committed into Spice.
My plan is:
1. Announce capability of DisplayConfig by vdagentd, then receive
VDAgentDisplayConfig message in vdagentd (set via --spice-disable-effects
and --spice-color-depth for client), send it to vdagent (via new udscs
message). [Done]
2. Use current GLib/GIO bindings for DBus in vdagent:
a) add new thread for GLib loop [In Progress]
b) take ownership of 'com.redhat.spice.vdagent' name at session bus [Done]
c) provide signals: effects_changed, color_depth_changed (need better names
and signatures - maybe we should split wallpaper, animation and font smooth
here...)
d) provide interface methods to complement signals: get_effects_state,
get_color_depth;
3. Emit g_signals in handler of VDAgentDisplayConfig message
4. Implement getters

Guest desktop management software (e.g. gnome-settings-daemon) should be
able to subscribe to our signals and act accordingly - and also should be
able to request current values (I'm going to implement test app handling
these signals, and maybe even propose a patch for Gnome, and then
investigate KDE opportunities)

Is it acceptable solution? Weak spot seems to be introduction of DBus via
GLib. While GLib is already linked by vdagent, it isn't used to full extent
(i.e. there is no GLib loop); also DBus bindings are available via libgio -
a new dependency; and this will work with GLib&GIO 2.26+ (current
dependency is 2.12 afaik).

I considered using dbus-1-glib bindings, but they're marked as obsolete at
DBus website, so we shouldn't use them for new code...
I haven't really considered using low-level DBus API instead, to avoid
dependency on GIO 2.26 - and avoid new thread with GLib loop - this seems
to be much harder to implement DBus support using its low-level API, and
seems not so practical as vdagent already depends on GLib. What do you
think?


--
Best regards,
Fedor


On Tue, Jun 25, 2013 at 4:15 PM, Fedor Lyakhov <fedor.lyakhov at gmail.com>wrote:

> Hi,
>
> 1. Yes, exactly, I meant to use this option.
>
> 2. And yes, that's my point - why vdagent should tweak settings for all
> desktops (it is impossible to support all desktops) - but we need to
> provide some means for desktop developers to take in account the DE is
> viewed via Spice (local or remote client) - at least that is requested in
> bug 62033.
>
> So we have following separate enhancements:
> 1) Detect local-only
> 2) Monitor bandwidth&latency
> 3) If local-only, disable many internal features meant for remote (i.e.
> compression, double rendering etc)
> 4) If requested to disable effects, notify guest's DE (already implemented
> in vdagent for Windows, needs something similar for Linux)
> 5) If remote && ((bandwidth < B) || (latency > L)), by default disable all
> effects (so probably we'd need an --spice-enable-effects=... alternative
> for the user; what about GUI menu in spice-gtk as well?)
>
> Right now I'm trying to start working on 4, as it is what is requested in
> the bug description... Hence this open question: how to notify Linux
> guest's DE? - to support arbitrary DE.
>
> --
> Thanks,
> Fedor
>
>
>
> On Tue, Jun 25, 2013 at 2:16 PM, Marc-André Lureau <mlureau at redhat.com>wrote:
>
>>
>> Hi
>>
>> ----- Mensaje original -----
>> > OK, so first implementation will work via --spice-disable-effects
>> option. As
>> > far as I understand, this user-provided option flags should already be
>> > available at the agent, need to handle appropriate message as in Windows
>> > vdagent, correct?
>>
>> There is already:
>> --spice-disable-effects=<wallpaper,font-smooth,animation,all>
>> --spice-color-depth=<16,32>
>>
>> > Anyway, I still don't understand how we can control these effects on
>> Linux
>> > desktops correctly - supporting only Gnome and not providing any means
>> for
>> > other DEs to catch up seems to be bad design (I'm using KDE, for
>> example;
>> > and even supporting both Gnome&KDE isn't solving this as there are a few
>> > more, fairly popular - Unity, XFce...). Also how interaction with this
>> Gnome
>> > settings should be implemented? If via function call from some shared
>> API,
>> > this adds on vdagent dependency (probably undesired by any other DE
>> users) -
>> > so usage of dload() is expected?
>>
>> I don't think there is a standard to handle those settings, so it will be
>> likely a per-desktop implementation.
>>
>> Probably the best performance improvements will be made by implementing
>> the shared memory suggestions from Hans and Yonit, so I wouldn't worry much
>> about desktop effects. Also, it is not necessarily the agent role to tweak
>> settings like animation for all desktops, the desktop settings daemon could
>> also handle it)
>>
>> Cheers
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130705/ada08ade/attachment.html>