Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
I agree about animations, apparently the setting doesn't affect
gnome-shell... I'll consider a feature request of something like a
setting 'bells-and-whistles', so, when disabled, Gnome accepts that
user is serious about disabling all this stuff :) It shouldn't be
accessible with dconf-editor though because it isn't good to scare
users with such powerfull settings (just look at KDE.. boo!)
On a serious note, the bug I'm trying to fix is
https://bugs.freedesktop.org/show_bug.cgi?id=62033, requested by
Zeeshan within context of
https://bugzilla.gnome.org/show_bug.cgi?id=680195 in
gnome-settings-daemon. And there was some work related to animations
as well.
Revisiting this I now start thinking originators won't like our
approach of changing settings directly, as they already do this in
gnome-settings-daemon, and just wanted an interface from
spice-vdagent...
On Thu, Jul 25, 2013 at 4:52 AM, Marc-André Lureau mlur...@redhat.com wrote:
- Mensaje original -
Thanks for the answer, Marc-André!
Few comments inline.
On Tue, Jul 23, 2013 at 4:27 PM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
Hi
On Mon, Jul 22, 2013 at 10:28 PM, Fedor Lyakhov fedor.lyak...@gmail.com
wrote:
Hi everyone,
I've made a bit of progress on this issue - disable wallpaper and
disable
animations somewhat work with Gnome3. The code is very simple:
static void disable_animation()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.interface);
g_settings_set_boolean(desktop_settings, enable-animations, FALSE);
}
static void disable_wallpaper()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.background);
g_settings_set_boolean(desktop_settings, draw-background, FALSE);
}
But looks like this isn't enough. This implementation of
disable_wallpaper
actually freezes current background, it is still displayed just isn't
scaled
properly when e.g. resolution changes. I'd love some input from anyone
with
Gnome3 knowledge... What's expected behavior for Spice client in this
case?
I think it is to have a solid background.
I see. Turns out this is not that easy to implement with Gnome3
settings, but looks like I've got somewhat acceptable behavior today.
Disable_animations seems to not changing things much - at least I still
see
some animations when opening menu or pressing Action button (top left
corner).
That doesn't surprise me. If you think that some shell animations are
superflous, you may want to open a bug to GNOME.
Sarcasm?) Personally I find Gnome3 not practically useful, at least
3.6 in Fedora 18... But let's not dive into this holywar :)
No no, I usually find GNOME3 animations quite pleasant or useful.
I mean that in some constrained/remote environment, we may want to disable
more animations in gnome-shell etc.
Perhaps, although in general, you use your VM either over WAN or
local, but not so much switching between the two all the time. And if
it is the case, there are chances you prefer to have the same look and
feel for both cases, so not doing any changes is probably ok.
I think that if we implement such intrusive behavior (changing
lookfeel of DE), we should provide a user with similar means to
revert that...
Perhaps it should be reverted for some users or use case. The use case I have
in mind (mostly remote usage, and work environment), I believe it is not so
important. ymmv
Imho, you could win much more performance gains by getting back to
means to detect local only and tuning spice settings itself
(disabling image compression etc), not tweaking the desktop settings,
but hey, do what you want! :)
Agree. I just don't feel too confident to dive in the internals now.
I'm trying to address Bug62033, but looks like Gnome/Boxes guys aren't
very interested in the solution now. It was their request for means to
detect 'spice local or remote' - that's why I started with DBus way in
the first place...
bgo #62033? not gnome-boxes (btw, the are some people behinds Boxes here :-)
--
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
- Mensaje original -
Thanks for the answer, Marc-André!
Few comments inline.
On Tue, Jul 23, 2013 at 4:27 PM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
Hi
On Mon, Jul 22, 2013 at 10:28 PM, Fedor Lyakhov fedor.lyak...@gmail.com
wrote:
Hi everyone,
I've made a bit of progress on this issue - disable wallpaper and
disable
animations somewhat work with Gnome3. The code is very simple:
static void disable_animation()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.interface);
g_settings_set_boolean(desktop_settings, enable-animations, FALSE);
}
static void disable_wallpaper()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.background);
g_settings_set_boolean(desktop_settings, draw-background, FALSE);
}
But looks like this isn't enough. This implementation of
disable_wallpaper
actually freezes current background, it is still displayed just isn't
scaled
properly when e.g. resolution changes. I'd love some input from anyone
with
Gnome3 knowledge... What's expected behavior for Spice client in this
case?
I think it is to have a solid background.
I see. Turns out this is not that easy to implement with Gnome3
settings, but looks like I've got somewhat acceptable behavior today.
Disable_animations seems to not changing things much - at least I still
see
some animations when opening menu or pressing Action button (top left
corner).
That doesn't surprise me. If you think that some shell animations are
superflous, you may want to open a bug to GNOME.
Sarcasm?) Personally I find Gnome3 not practically useful, at least
3.6 in Fedora 18... But let's not dive into this holywar :)
No no, I usually find GNOME3 animations quite pleasant or useful.
I mean that in some constrained/remote environment, we may want to disable more
animations in gnome-shell etc.
Perhaps, although in general, you use your VM either over WAN or
local, but not so much switching between the two all the time. And if
it is the case, there are chances you prefer to have the same look and
feel for both cases, so not doing any changes is probably ok.
I think that if we implement such intrusive behavior (changing
lookfeel of DE), we should provide a user with similar means to
revert that...
Perhaps it should be reverted for some users or use case. The use case I have
in mind (mostly remote usage, and work environment), I believe it is not so
important. ymmv
Imho, you could win much more performance gains by getting back to
means to detect local only and tuning spice settings itself
(disabling image compression etc), not tweaking the desktop settings,
but hey, do what you want! :)
Agree. I just don't feel too confident to dive in the internals now.
I'm trying to address Bug62033, but looks like Gnome/Boxes guys aren't
very interested in the solution now. It was their request for means to
detect 'spice local or remote' - that's why I started with DBus way in
the first place...
bgo #62033? not gnome-boxes (btw, the are some people behinds Boxes here :-)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi
On Mon, Jul 22, 2013 at 10:28 PM, Fedor Lyakhov fedor.lyak...@gmail.com wrote:
Hi everyone,
I've made a bit of progress on this issue - disable wallpaper and disable
animations somewhat work with Gnome3. The code is very simple:
static void disable_animation()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.interface);
g_settings_set_boolean(desktop_settings, enable-animations, FALSE);
}
static void disable_wallpaper()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.background);
g_settings_set_boolean(desktop_settings, draw-background, FALSE);
}
But looks like this isn't enough. This implementation of disable_wallpaper
actually freezes current background, it is still displayed just isn't scaled
properly when e.g. resolution changes. I'd love some input from anyone with
Gnome3 knowledge... What's expected behavior for Spice client in this case?
I think it is to have a solid background.
Disable_animations seems to not changing things much - at least I still see
some animations when opening menu or pressing Action button (top left
corner).
That doesn't surprise me. If you think that some shell animations are
superflous, you may want to open a bug to GNOME.
Another question is about --spice-disable-effects=font-smooth. While this
can be changed via GSettings, I think it should be changed at X level,
correct? Leading to subsequent question of supporting Wayland/Weston... Also
I don't really see any use case for disabling anti-aliasing... Maybe
configuring anti-aliasing level makes sense...
There is a Antialias = None setting in gnome-tweek-tool, so there must
be a corresponding GSettings key.
Next question is about --spice-color-depth. Right now it supports
Windows-specific values of 16 and 32, for Linux we'd need to support 16 and
24. I think this setting should be adjusted at X level, similarly to
anti-aliasing.
Apparently, this is not possible with randr gnome, and might need a
server restart. Also, I am not convinced this is the right approach,
it would be nice to have actual numbers for different use cases..
There is another level of complexity: changing these settings takes
permanent effect, and user doesn't have any means to reset them except
dconf-editor (not user friendly at all).
So looks like we'd need an '--spice-enable-effects' option (and by default,
when enable/disable isn't set, use local-only detection - to be
implemented). What do you think?
Perhaps, although in general, you use your VM either over WAN or
local, but not so much switching between the two all the time. And if
it is the case, there are chances you prefer to have the same look and
feel for both cases, so not doing any changes is probably ok.
And finally, I haven't looked into KDE settings counterpart yet, but the
question is already here - how should we bind to KDE settings API. Late
binding via dlopen/dlsym - to be used only if KDE detected? Also,
GSettings/Gnome3 support relies on GIO - and currently vdagent isn't
dependent on this library (only on GLib). Should we not favor Gnome3 over
KDE here and implement this feature symmetrically?
I would say it's fine to link with kde low-level counterpart. But in
general, favour DBus services usage if possible.
I'm really sorry for so much questions about this tiny feature...
Implementing DE-specifics within a client doesn't seem so easy or proper way
for me now...
Imho, you could win much more performance gains by getting back to
means to detect local only and tuning spice settings itself
(disabling image compression etc), not tweaking the desktop settings,
but hey, do what you want! :)
--
Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi everyone,
I've made a bit of progress on this issue - disable wallpaper and
disable animations somewhat work with Gnome3. The code is very simple:
static void disable_animation()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.interface);
g_settings_set_boolean(desktop_settings, enable-animations, FALSE);
}
static void disable_wallpaper()
{
GSettings *desktop_settings =
g_settings_new(org.gnome.desktop.background);
g_settings_set_boolean(desktop_settings, draw-background, FALSE);
}
But looks like this isn't enough. This implementation of disable_wallpaper
actually freezes current background, it is still displayed just isn't
scaled properly when e.g. resolution changes. I'd love some input from
anyone with Gnome3 knowledge... What's expected behavior for Spice client
in this case?
Disable_animations seems to not changing things much - at least I still see
some animations when opening menu or pressing Action button (top left
corner).
Another question is about --spice-disable-effects=font-smooth. While this
can be changed via GSettings, I think it should be changed at X level,
correct? Leading to subsequent question of supporting Wayland/Weston...
Also I don't really see any use case for disabling anti-aliasing... Maybe
configuring anti-aliasing level makes sense...
Next question is about --spice-color-depth. Right now it supports
Windows-specific values of 16 and 32, for Linux we'd need to support 16 and
24. I think this setting should be adjusted at X level, similarly to
anti-aliasing.
There is another level of complexity: changing these settings takes
permanent effect, and user doesn't have any means to reset them except
dconf-editor (not user friendly at all).
So looks like we'd need an '--spice-enable-effects' option (and by default,
when enable/disable isn't set, use local-only detection - to be
implemented). What do you think?
And finally, I haven't looked into KDE settings counterpart yet, but the
question is already here - how should we bind to KDE settings API. Late
binding via dlopen/dlsym - to be used only if KDE detected? Also,
GSettings/Gnome3 support relies on GIO - and currently vdagent isn't
dependent on this library (only on GLib). Should we not favor Gnome3 over
KDE here and implement this feature symmetrically?
I'm really sorry for so much questions about this tiny feature...
Implementing DE-specifics within a client doesn't seem so easy or proper
way for me now...
On Fri, Jul 5, 2013 at 9:45 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 07/05/2013 06:07 PM, Fedor Lyakhov wrote:
Thanks for your answers!
Looks like the issue is more complicated than I originally thought. But
I'm still excited to continue working on it.
Ok, I'm going to follow Hans' view now.
Good.
One thing I don't understand: why would we want to apply these 'effects'
settings via vdagentd (system level)? For me they belong to session level.
And they do, the suggestion to use the system dbus was related to your
proposal where the agent would advertise
settings and the session(s) settings manager would query them. If you
follow my proposal the agent will be
actively making the changes, and that certainly belongs in the session
part of the agent.
Before the session is started there is no way for us to know will it be
Gnome or KDE or w/e - it is decided upon login...
Correct, but if the session's settings manager will query the agent (the
old design) there is no need to know
the session type.
Also how this will work when Spice supports multiple client connections
to one guest?
A good question, this is something which is best left for later.
I'll investigate current ways of toggling 'effects' in Gnome and KDE - to
understand how far we are from common standard way for doing this. Assuming
there is no common way, what would you prefer:
1. Implement DE-specific code within vdagent/vdagentd
2. Introduce something like 'draft standard dbus interface for
controlling DE effects', and add sample Gnome and KDE implementations
(which would hide DE-specifics from vdagent).
I would prefer 1. You could also do 2 in parallel as a proof of concept,
when starting
a discussion about a unified dbus API for this, it helps to have some
example code, but I
believe that to get results quickly we should do 1 (we can still pursue 2
in parallel to
work to a better solution in the future).
Regards,
Hans
--
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
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 GLibGIO 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.comwrote: 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 bandwidthlatency 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.comwrote: 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 GnomeKDE 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
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
hi On Fri, Jul 5, 2013 at 2:40 PM, Fedor Lyakhov fedor.lyak...@gmail.com wrote: 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...) Instead of forwarding the event to the session via udscs and then emiting signal, I would use a dbus at system level and emit those dbus property change from there (not signals). 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 GLibGIO 2.26+ (current dependency is 2.12 afaik). Unfortunately I think Hans would prefer to avoid glib/gio usage in spice-vdagent... RHEL6 is updating to glib 2.26, we should be able to bump dep without issue. 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... Let's avoid dbus-1-glib ;) 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? It's not so hard, but if we can use GObject/GIO DBus, it will be much easier to implement and maintain. -- Marc-André Lureau ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi, On 07/05/2013 03:08 PM, Marc-André Lureau wrote: hi On Fri, Jul 5, 2013 at 2:40 PM, Fedor Lyakhov fedor.lyak...@gmail.com wrote: 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...) Instead of forwarding the event to the session via udscs and then emiting signal, I would use a dbus at system level and emit those dbus property change from there (not signals). ACK for using the system bus, if we use dbus at all, see below. 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 GLibGIO 2.26+ (current dependency is 2.12 afaik). I seem to have missed the whole discussion deciding to make this a spice-vdagent dbus interface. The agent is not offering a service here, as typical dbus services are, instead it is offering information in the hope others will pick it up. This feels the wrong way around. To me, how this should work is like this: 1) spice-vdagentd forwards info to spice-vdagent in the X-session 2) spice-vdagent connects to the desktop environments settings daemon and changes the settings (after which the settings daemon will notify interested parties). Yes this means having a per desktop-environment implementation for this in spice-vdagent. But the current proposal does not avoid having to do per desktop-environment work, it just moves that work to inside the desktop-environment. I believe getting spice specific patches accepted into the various desktop environments, is going to be an uphill battle, and if we need to write per de code anyways, it is best to keep it inside the agent, were we at least have control over if and when to merge the code. Now ideally there would be a generic dbus interface for all this, so that it can be used for example by the vmware linux agent, vnc / rdp agents, etc. too. I suggest working on creating a standard interface for this under the freedesktop.org umbrella. And in the mean time simply add de specific code to the X-session spice-vdagent to forward these settings in a de specific manner. Then once we've a standard we can slowly mover over to that. IMHO creating a spice-specific interface for this, is not acceptable, it is not generic enough to warrant the effort of teaching all desktop-environments about it. Unfortunately I think Hans would prefer to avoid glib/gio usage in spice-vdagent... Since the addition of file-xfer support the X-session agent already uses glib. RHEL6 is updating to glib 2.26, we should be able to bump dep without issue. 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... Let's avoid dbus-1-glib ;) +1 Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Thanks for your answers! Looks like the issue is more complicated than I originally thought. But I'm still excited to continue working on it. Ok, I'm going to follow Hans' view now. One thing I don't understand: why would we want to apply these 'effects' settings via vdagentd (system level)? For me they belong to session level. Before the session is started there is no way for us to know will it be Gnome or KDE or w/e - it is decided upon login... Also how this will work when Spice supports multiple client connections to one guest? I'll investigate current ways of toggling 'effects' in Gnome and KDE - to understand how far we are from common standard way for doing this. Assuming there is no common way, what would you prefer: 1. Implement DE-specific code within vdagent/vdagentd 2. Introduce something like 'draft standard dbus interface for controlling DE effects', and add sample Gnome and KDE implementations (which would hide DE-specifics from vdagent). On Fri, Jul 5, 2013 at 5:22 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 07/05/2013 03:08 PM, Marc-André Lureau wrote: hi On Fri, Jul 5, 2013 at 2:40 PM, Fedor Lyakhov fedor.lyak...@gmail.com wrote: 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...) Instead of forwarding the event to the session via udscs and then emiting signal, I would use a dbus at system level and emit those dbus property change from there (not signals). ACK for using the system bus, if we use dbus at all, see below. 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 GLibGIO 2.26+ (current dependency is 2.12 afaik). I seem to have missed the whole discussion deciding to make this a spice-vdagent dbus interface. The agent is not offering a service here, as typical dbus services are, instead it is offering information in the hope others will pick it up. This feels the wrong way around. To me, how this should work is like this: 1) spice-vdagentd forwards info to spice-vdagent in the X-session 2) spice-vdagent connects to the desktop environments settings daemon and changes the settings (after which the settings daemon will notify interested parties). Yes this means having a per desktop-environment implementation for this in spice-vdagent. But the current proposal does not avoid having to do per desktop-environment work, it just moves that work to inside the desktop-environment. I believe getting spice specific patches accepted into the various desktop environments, is going to be an uphill battle, and if we need to write per de code anyways, it is best to keep it inside the agent, were we at least have control over if and when to merge the code. Now ideally there would be a generic dbus interface for all this, so that it can be used for example by the vmware linux agent, vnc / rdp agents, etc. too. I suggest working on creating a standard interface for this under the freedesktop.org umbrella. And in the mean time simply add de specific code to the X-session spice-vdagent to forward these settings in a de specific manner. Then once we've a standard we can slowly mover over to that. IMHO creating a spice-specific interface for this, is not acceptable, it is not generic enough to warrant the effort of teaching all desktop-environments about it. Unfortunately I think Hans would prefer to avoid glib/gio usage in spice-vdagent... Since the addition of file-xfer support the X-session agent already uses glib. RHEL6 is updating to glib 2.26, we should be able to bump dep without
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi, On 07/05/2013 06:07 PM, Fedor Lyakhov wrote: Thanks for your answers! Looks like the issue is more complicated than I originally thought. But I'm still excited to continue working on it. Ok, I'm going to follow Hans' view now. Good. One thing I don't understand: why would we want to apply these 'effects' settings via vdagentd (system level)? For me they belong to session level. And they do, the suggestion to use the system dbus was related to your proposal where the agent would advertise settings and the session(s) settings manager would query them. If you follow my proposal the agent will be actively making the changes, and that certainly belongs in the session part of the agent. Before the session is started there is no way for us to know will it be Gnome or KDE or w/e - it is decided upon login... Correct, but if the session's settings manager will query the agent (the old design) there is no need to know the session type. Also how this will work when Spice supports multiple client connections to one guest? A good question, this is something which is best left for later. I'll investigate current ways of toggling 'effects' in Gnome and KDE - to understand how far we are from common standard way for doing this. Assuming there is no common way, what would you prefer: 1. Implement DE-specific code within vdagent/vdagentd 2. Introduce something like 'draft standard dbus interface for controlling DE effects', and add sample Gnome and KDE implementations (which would hide DE-specifics from vdagent). I would prefer 1. You could also do 2 in parallel as a proof of concept, when starting a discussion about a unified dbus API for this, it helps to have some example code, but I believe that to get results quickly we should do 1 (we can still pursue 2 in parallel to work to a better solution in the future). Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
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 GnomeKDE 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
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi Fedor, I'd personally prefer to: 1) monitor bandwidth and latency continuously - there's a long-standing RFE for it and IIRC Yonit has posted some proof-of-concept patches in recent months (as a part of her streamlining of video streams) 2) set the options on-the fly as the conditions allow to get at the right position in b/w-saving --- cpu saving scale The reason for this preference of mine is two-fold: * idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN behaviour, especially with decreasing stream resolution * such behaviour would be consistent with the rest of the spice protocol I'm also not sure if I follow what you want to do with an agent: 1) the agent runs in the guest OS and communicates already with the client through using spice means - i.e. agent - virtio-serial/qemu - spice-server - spice client. You shouldn't need to invent any other client -- agent connection, and I can't get how such thing should help you... 2) agent has no connection of what happens with display, and it has a limited knowledge of network conditions as it handles just a subset of all the traffic. spice-server and spice client actually do have complete picture of what happens on the wire David Fedor Lyakhov píše v Ne 23. 06. 2013 v 02:26 +0400: Hello Zeeshan, Marc-André and other Spice developers, I think about implementing a solution for this bug 62033 ( https://bugs.freedesktop.org/show_bug.cgi?id=62033). First of all, need to clarify what is requested and what is really needed in this request. Zeeshan suggests as a simple yet acceptable solution for vdagent to report 'local-only' connection non-dynamically.. as I understand this means reporting only once, at startup (?). I think it isn't enough because this connection state may change easily during X session lifetime - in general user is free to connect locally and then re-connect from remote host, and vise versa. So I propose more generic approach, when vdagent reports current connection state dynamically when state is changed. It will be up to gnome-settings-daemon to act on this signal and toggle animations accordingly. If this is acceptable, we need to decide on the interface. I think there are 2 appropriate technologies: 1. raw socket [or something like this] 2. D-Bus I'm not an expert in D-Bus and freedesktop in general (good opportunity for me to learn!) but looks like it is appropriate to use it here. 2 questions arise: 1. vdagentd and vdagent daemons already communicate via socket using simple homebrew protocol (at least afaik). Probably this was done on purpose. So is it true vdagent wants to avoid dependency on D-Bus? 2. It seems to better use some higher-level D-Bus bindings (GLib, Qt...) instead of its low-level API. So is it acceptable to add a dependency of GLib to vdagent? Or are you aware of some other D-Bus bindings to be used in vdagent to avoid this extra dependency? BTW, reporting of connection state can be implemented independently of the actual transport (socket/D-Bus): 1. Client app (e.g. gnome-settings-daemon) establishes connection to vdagent being a server (e.g. listening at the socket, or providing D-Bus interface method RegisterConnectionStateObserver or w/e we name it) 2. vdagent sends the state to registered clients (e.g. D-Bus signal); and continues to do so each time the state is changed. So we can even have 2 back-ends for this (additional work, unfortunately). And last question: while this isn't needed on Windows version of vdagent right now, additional use cases of this vdagent interface in guest userspace may arise [e.g. I'm thinking about remote media engine provided by spice client]. So I think we should target for similar extendable interface at both Windows and Linux guests (as much as possible). I haven't looked in vdagent for Windows code yet but guess D-Bus won't be the best choice there (while D-Bus reportedly works on Windows as well...). Something like socket and D-Bus and native DCOM would be the best and future-proof.. What do you think? [Note: I haven't talked about implementation of new messages between vdagent and vdagentd, and spice-server, and the actual local/remote detection code - will ask questions later] ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 smime.p7s Description: S/MIME cryptographic signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi David, Thanks for your answer. Please see my comments below. On Mon, Jun 24, 2013 at 3:47 PM, David Jaša dj...@redhat.com wrote: Hi Fedor, I'd personally prefer to: 1) monitor bandwidth and latency continuously - there's a long-standing RFE for it and IIRC Yonit has posted some proof-of-concept patches in recent months (as a part of her streamlining of video streams) 2) set the options on-the fly as the conditions allow to get at the right position in b/w-saving --- cpu saving scale The reason for this preference of mine is two-fold: * idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN behaviour, especially with decreasing stream resolution * such behaviour would be consistent with the rest of the spice protocol [FL] I agree with your points. So implementation will be based on continuous bandwidth and latency monitoring and reporting. This means we'd need a heuristic algorithm to detect a threshold for 'bad' and 'good' connection (and reporting the threshold has been crossed in one or another direction). I'm also not sure if I follow what you want to do with an agent: 1) the agent runs in the guest OS and communicates already with the client through using spice means - i.e. agent - virtio-serial/qemu - spice-server - spice client. You shouldn't need to invent any other client -- agent connection, and I can't get how such thing should help you... 2) agent has no connection of what happens with display, and it has a limited knowledge of network conditions as it handles just a subset of all the traffic. spice-server and spice client actually do have complete picture of what happens on the wire [FL] I do understand all this. Sorry for my previous bloated e-mail giving you wrong picture of what I'm suggesting. New functionality for vdagent is required: an interface for applications running at guest OS. In particular, gnome-settings-daemon needs to know whether the connection is good or bad, and toggle animations accordingly. I see following options for interface vdagent-guest-apps: 1. D-Bus (low-level API, or GLib bindings) 2. Raw socket with custom protocol (similar to vdagent - vdagentd) Personally I'd prefer D-Bus, since looks like this is the best interface for freedesktop-based environments. This is interface facing users (apps at guest); for internals I'm going to reuse current vdagent-vdagentd communication mechanism, and vdagentd -virtio-serial/qemu - spice-server (which will provide the actual state, 'good' or 'bad', and report the metrics probably). If D-Bus is approved, I can think of enhancing vdagent-vdagentd communication from socket to D-Bus as well. -Fedor ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi, On 06/24/2013 02:44 PM, Fedor Lyakhov wrote: Hi David, Thanks for your answer. Please see my comments below. On Mon, Jun 24, 2013 at 3:47 PM, David Jaša dj...@redhat.com mailto:dj...@redhat.com wrote: Hi Fedor, I'd personally prefer to: 1) monitor bandwidth and latency continuously - there's a long-standing RFE for it and IIRC Yonit has posted some proof-of-concept patches in recent months (as a part of her streamlining of video streams) 2) set the options on-the fly as the conditions allow to get at the right position in b/w-saving --- cpu saving scale The reason for this preference of mine is two-fold: * idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN behaviour, especially with decreasing stream resolution * such behaviour would be consistent with the rest of the spice protocol [FL] I agree with your points. So implementation will be based on continuous bandwidth and latency monitoring and reporting. This means we'd need a heuristic algorithm to detect a threshold for 'bad' and 'good' connection (and reporting the threshold has been crossed in one or another direction). Although I agree with doing continuous bandwidth + latency monitoring, this is something which will not be trivial. I would prefer to see a simple local / non local detection too. Low hanging fruit first. And since in the future we hope to have 3d pass-through too, this will be useful for determine settings there too. Since we sometimes get passed file-descriptors rather then opening sockets our-selves, we cannot simply check for localhost or some such for local detection. So we will likely need to fallback to checking if the spice-server and spice-client share a filesystem. One possible way to do this would be to create a shared memory segment with a unique name from one side and have the other side also open this. See for example how pulseaudio does this. This may seem like overkill for just local detection, but we will likely want a shared-memory segment in the future anyways to use to speedup the local use case (by avoiding sending pixmaps over a socket), so it seems like a good idea to create one now, even if just gets used for local detection for now. I'm also not sure if I follow what you want to do with an agent: 1) the agent runs in the guest OS and communicates already with the client through using spice means - i.e. agent - virtio-serial/qemu - spice-server - spice client. You shouldn't need to invent any other client -- agent connection, and I can't get how such thing should help you... 2) agent has no connection of what happens with display, and it has a limited knowledge of network conditions as it handles just a subset of all the traffic. spice-server and spice client actually do have complete picture of what happens on the wire [FL] I do understand all this. Sorry for my previous bloated e-mail giving you wrong picture of what I'm suggesting. New functionality for vdagent is required: an interface for applications running at guest OS. In particular, gnome-settings-daemon needs to know whether the connection is good or bad, and toggle animations accordingly. I see following options for interface vdagent-guest-apps: 1. D-Bus (low-level API, or GLib bindings) 2. Raw socket with custom protocol (similar to vdagent - vdagentd) Personally I'd prefer D-Bus, since looks like this is the best interface for freedesktop-based environments. This is interface facing users (apps at guest); for internals I'm going to reuse current vdagent-vdagentd communication mechanism, and vdagentd -virtio-serial/qemu - spice-server (which will provide the actual state, 'good' or 'bad', and report the metrics probably). If D-Bus is approved, I can think of enhancing vdagent-vdagentd communication from socket to D-Bus as well. I don't think that any dbus api will be needed the agent can simply change the gsettings for these, and then gnome-shell will notice the change and react accordingly, at least I assume this is how the control-center settings work and get applied. Even if I'm wrong about the gsettings bit, there has to be an API between the control-center and gnome-shell, and rather then inventing a new one it would be good for the agent to re-use the existing one to talk to gnome-shell / gsd Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hans, Thanks for the comments and clarifications! OK, I'll start with more simple solution of 'local/remote' detection first. As for gsettings - I see your point, this will solve the issue for Gnome3 as requested. But I think this is too limited - e.g. what if KDE5 wants this in future? On Mon, Jun 24, 2013 at 5:54 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 06/24/2013 02:44 PM, Fedor Lyakhov wrote: Hi David, Thanks for your answer. Please see my comments below. On Mon, Jun 24, 2013 at 3:47 PM, David Jaša dj...@redhat.com mailto: dj...@redhat.com wrote: Hi Fedor, I'd personally prefer to: 1) monitor bandwidth and latency continuously - there's a long-standing RFE for it and IIRC Yonit has posted some proof-of-concept patches in recent months (as a part of her streamlining of video streams) 2) set the options on-the fly as the conditions allow to get at the right position in b/w-saving --- cpu saving scale The reason for this preference of mine is two-fold: * idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN behaviour, especially with decreasing stream resolution * such behaviour would be consistent with the rest of the spice protocol [FL] I agree with your points. So implementation will be based on continuous bandwidth and latency monitoring and reporting. This means we'd need a heuristic algorithm to detect a threshold for 'bad' and 'good' connection (and reporting the threshold has been crossed in one or another direction). Although I agree with doing continuous bandwidth + latency monitoring, this is something which will not be trivial. I would prefer to see a simple local / non local detection too. Low hanging fruit first. And since in the future we hope to have 3d pass-through too, this will be useful for determine settings there too. Since we sometimes get passed file-descriptors rather then opening sockets our-selves, we cannot simply check for localhost or some such for local detection. So we will likely need to fallback to checking if the spice-server and spice-client share a filesystem. One possible way to do this would be to create a shared memory segment with a unique name from one side and have the other side also open this. See for example how pulseaudio does this. This may seem like overkill for just local detection, but we will likely want a shared-memory segment in the future anyways to use to speedup the local use case (by avoiding sending pixmaps over a socket), so it seems like a good idea to create one now, even if just gets used for local detection for now. I'm also not sure if I follow what you want to do with an agent: 1) the agent runs in the guest OS and communicates already with the client through using spice means - i.e. agent - virtio-serial/qemu - spice-server - spice client. You shouldn't need to invent any other client -- agent connection, and I can't get how such thing should help you... 2) agent has no connection of what happens with display, and it has a limited knowledge of network conditions as it handles just a subset of all the traffic. spice-server and spice client actually do have complete picture of what happens on the wire [FL] I do understand all this. Sorry for my previous bloated e-mail giving you wrong picture of what I'm suggesting. New functionality for vdagent is required: an interface for applications running at guest OS. In particular, gnome-settings-daemon needs to know whether the connection is good or bad, and toggle animations accordingly. I see following options for interface vdagent-guest-apps: 1. D-Bus (low-level API, or GLib bindings) 2. Raw socket with custom protocol (similar to vdagent - vdagentd) Personally I'd prefer D-Bus, since looks like this is the best interface for freedesktop-based environments. This is interface facing users (apps at guest); for internals I'm going to reuse current vdagent-vdagentd communication mechanism, and vdagentd -virtio-serial/qemu - spice-server (which will provide the actual state, 'good' or 'bad', and report the metrics probably). If D-Bus is approved, I can think of enhancing vdagent-vdagentd communication from socket to D-Bus as well. I don't think that any dbus api will be needed the agent can simply change the gsettings for these, and then gnome-shell will notice the change and react accordingly, at least I assume this is how the control-center settings work and get applied. Even if I'm wrong about the gsettings bit, there has to be an API between the control-center and gnome-shell, and rather then inventing a new one it would be good for the agent to re-use the existing one to talk to gnome-shell / gsd Regards, Hans -- Best regards, Fedor ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi, For the purpose of disabling guest desktop effects, we already have a spice-gtk option which we use for Windows guests, and can be used for Linux guests as well. The Linux agent should support VD_AGENT_DISPLAY_CONFIG for this. However, for local usage, we would also like to disable bitmap/audio compression, and video compression on the server side (I believe there is already an opened bug for decoupling lipsync from video compression). In addition, when using spice for local usage, you also have the overhead of redundant rendering on both server side (when required), and client side. We also need to consider rendering everything on the server side. IMHO, as a first stage, we can start by adding an explicit option to spice-gtk for local, or more specific options for disabling compression (e.g., --disable-compression=audio/video/bitmaps/all). We can then send the settings to the server upon connection. As a second stage, I would continue with an automatic detection, something like hans suggested. Regards, Yonit. On 06/24/2013 09:54 AM, Hans de Goede wrote: Hi, On 06/24/2013 02:44 PM, Fedor Lyakhov wrote: Hi David, Thanks for your answer. Please see my comments below. On Mon, Jun 24, 2013 at 3:47 PM, David Jaša dj...@redhat.com mailto:dj...@redhat.com wrote: Hi Fedor, I'd personally prefer to: 1) monitor bandwidth and latency continuously - there's a long-standing RFE for it and IIRC Yonit has posted some proof-of-concept patches in recent months (as a part of her streamlining of video streams) 2) set the options on-the fly as the conditions allow to get at the right position in b/w-saving --- cpu saving scale The reason for this preference of mine is two-fold: * idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN behaviour, especially with decreasing stream resolution * such behaviour would be consistent with the rest of the spice protocol [FL] I agree with your points. So implementation will be based on continuous bandwidth and latency monitoring and reporting. This means we'd need a heuristic algorithm to detect a threshold for 'bad' and 'good' connection (and reporting the threshold has been crossed in one or another direction). Although I agree with doing continuous bandwidth + latency monitoring, this is something which will not be trivial. I would prefer to see a simple local / non local detection too. Low hanging fruit first. And since in the future we hope to have 3d pass-through too, this will be useful for determine settings there too. Since we sometimes get passed file-descriptors rather then opening sockets our-selves, we cannot simply check for localhost or some such for local detection. So we will likely need to fallback to checking if the spice-server and spice-client share a filesystem. One possible way to do this would be to create a shared memory segment with a unique name from one side and have the other side also open this. See for example how pulseaudio does this. This may seem like overkill for just local detection, but we will likely want a shared-memory segment in the future anyways to use to speedup the local use case (by avoiding sending pixmaps over a socket), so it seems like a good idea to create one now, even if just gets used for local detection for now. I'm also not sure if I follow what you want to do with an agent: 1) the agent runs in the guest OS and communicates already with the client through using spice means - i.e. agent - virtio-serial/qemu - spice-server - spice client. You shouldn't need to invent any other client -- agent connection, and I can't get how such thing should help you... 2) agent has no connection of what happens with display, and it has a limited knowledge of network conditions as it handles just a subset of all the traffic. spice-server and spice client actually do have complete picture of what happens on the wire [FL] I do understand all this. Sorry for my previous bloated e-mail giving you wrong picture of what I'm suggesting. New functionality for vdagent is required: an interface for applications running at guest OS. In particular, gnome-settings-daemon needs to know whether the connection is good or bad, and toggle animations accordingly. I see following options for interface vdagent-guest-apps: 1. D-Bus (low-level API, or GLib bindings) 2. Raw socket with custom protocol (similar to vdagent - vdagentd) Personally I'd prefer D-Bus, since looks like this is the best interface for freedesktop-based environments. This is interface facing users (apps at guest); for internals I'm going to reuse current vdagent-vdagentd communication mechanism, and vdagentd -virtio-serial/qemu - spice-server (which will provide the actual state, 'good' or 'bad', and report the metrics probably). If D-Bus is approved, I can think of enhancing vdagent-vdagentd communication from socket to D-Bus as well. I don't think that any dbus api will be needed the
Re: [Spice-devel] Questions regarding Bug 62033 - Means to detect local-only
Hi, On 06/24/2013 05:32 PM, Yonit Halperin wrote: Hi, For the purpose of disabling guest desktop effects, we already have a spice-gtk option which we use for Windows guests, and can be used for Linux guests as well. The Linux agent should support VD_AGENT_DISPLAY_CONFIG for this. However, for local usage, we would also like to disable bitmap/audio compression, and video compression on the server side (I believe there is already an opened bug for decoupling lipsync from video compression). In addition, when using spice for local usage, you also have the overhead of redundant rendering on both server side (when required), and client side. We also need to consider rendering everything on the server side. Yes, and when we decide to render everything on the server side, then having shared memory becomes really useful... :) IMHO, as a first stage, we can start by adding an explicit option to spice-gtk for local, or more specific options for disabling compression (e.g., --disable-compression=audio/video/bitmaps/all). We can then send the settings to the server upon connection. As a second stage, I would continue with an automatic detection, something like hans suggested. Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
