[Spice-devel] Questions regarding Bug 62033 - Means to detect local-only

[Yonit Halperin]

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 at redhat.com
>> <mailto:djasa at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel