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.lyak...@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 <mlur...@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 >> > >
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
