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
