<div dir="ltr"><div><div><div>Hello everyone,<br><br>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.<br>
</div>My plan is:<br></div>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]<br>
</div><div>2. Use current GLib/GIO bindings for DBus in vdagent:<br></div><div>a) add new thread for GLib loop [In Progress]<br></div><div>b) take ownership of 'com.redhat.spice.vdagent' name at session bus [Done]<br>
</div><div>c) provide signals: effects_changed, color_depth_changed (need better names and signatures - maybe we should split wallpaper, animation and font smooth here...)<br></div><div>d) provide interface methods to complement signals: get_effects_state, get_color_depth; <br>
</div><div>3. Emit g_signals in handler of VDAgentDisplayConfig message<br></div><div>4. Implement getters<br><br></div><div>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)<br>
</div><div><br></div><div>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).<br>
<br></div><div>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...<br></div><div>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?<br>
</div><div><br><br>--<br></div><div>Best regards,<br>Fedor<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 25, 2013 at 4:15 PM, Fedor Lyakhov <span dir="ltr"><<a href="mailto:fedor.lyakhov@gmail.com" target="_blank">fedor.lyakhov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>1. Yes, exactly, I meant to use this option.<br><br></div>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.<br>
<br></div>So we have following separate enhancements:<br></div><div>1) Detect local-only<br></div><div>2) Monitor bandwidth&latency<br></div>3) If local-only, disable many internal features meant for remote (i.e. compression, double rendering etc)<br>
</div>4) If requested to disable effects, notify guest's DE (already implemented in vdagent for Windows, needs something similar for Linux)<br><div><div><div><div><div>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?)<br>
<br></div><div>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.<br></div><div><br>
--<br></div><div>Thanks,<br></div><div>Fedor<br><br></div></div></div></div></div><div><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 25, 2013 at 2:16 PM, Marc-André Lureau <span dir="ltr"><<a href="mailto:mlureau@redhat.com" target="_blank">mlureau@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi<br>
<br>
----- Mensaje original -----<br>
<div>> OK, so first implementation will work via --spice-disable-effects option. As<br>
> far as I understand, this user-provided option flags should already be<br>
> available at the agent, need to handle appropriate message as in Windows<br>
> vdagent, correct?<br>
<br>
</div>There is already:<br>
--spice-disable-effects=<wallpaper,font-smooth,animation,all><br>
--spice-color-depth=<16,32><br>
<div><br>
> Anyway, I still don't understand how we can control these effects on Linux<br>
> desktops correctly - supporting only Gnome and not providing any means for<br>
> other DEs to catch up seems to be bad design (I'm using KDE, for example;<br>
> and even supporting both Gnome&KDE isn't solving this as there are a few<br>
> more, fairly popular - Unity, XFce...). Also how interaction with this Gnome<br>
> settings should be implemented? If via function call from some shared API,<br>
> this adds on vdagent dependency (probably undesired by any other DE users) -<br>
> so usage of dload() is expected?<br>
<br>
</div>I don't think there is a standard to handle those settings, so it will be likely a per-desktop implementation.<br>
<br>
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)<br>
<br>
Cheers<br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br><br></div></div>