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