<div dir="ltr"><div>Hans,<br><br>Thanks for the comments and clarifications! OK, I'll start with more simple solution of 'local/remote' detection first.<br><br></div>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?<br> <div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 24, 2013 at 5:54 PM, Hans de Goede <span dir="ltr"><<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div class="im"><br> <br> On 06/24/2013 02:44 PM, Fedor Lyakhov wrote:<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> <br> Hi David,<br> <br> Thanks for your answer. Please see my comments below.<br> <br> <br></div><div class="im"> On Mon, Jun 24, 2013 at 3:47 PM, David Jaša <<a href="mailto:djasa@redhat.com" target="_blank">djasa@redhat.com</a> <mailto:<a href="mailto:djasa@redhat.com" target="_blank">djasa@redhat.com</a>>> wrote:<br> <br> Hi Fedor,<br> <br> I'd personally prefer to:<br> 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)<br> 2) set the options on-the fly as the conditions allow to get at the right position in b/w-saving <---> cpu saving scale<br> <br> The reason for this preference of mine is two-fold:<br> * idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN behaviour, especially with decreasing stream resolution<br> * such behaviour would be consistent with the rest of the spice protocol<br> <br> <br> [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).<br> </div></blockquote> <br> Although I agree with doing continuous bandwidth + latency monitoring, this is something which<br> will not be trivial. I would prefer to see a "simple" local / non local detection too. Low hanging<br> fruit first.<br> <br> And since in the future we hope to have 3d pass-through too, this will be useful for determine<br> settings there too.<br> <br> Since we sometimes get passed file-descriptors rather then opening sockets our-selves, we cannot<br> simply check for localhost or some such for local detection. So we will likely need to fallback<br> to checking if the spice-server and spice-client share a filesystem. One possible way to do<br> this would be to create a shared memory segment with a unique name from one side and have the<br> other side also open this. See for example how pulseaudio does this.<br> <br> This may seem like overkill for just "local" detection, but we will likely want a shared-memory<br> segment in the future anyways to use to speedup the local use case (by avoiding sending pixmaps<br> over a socket), so it seems like a good idea to create one now, even if just gets used for<br> local detection for now.<div class="im"><br> <br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I'm also not sure if I follow what you want to do with an agent:<br> 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...<br> 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<br> <br> <br> [FL] I do understand all this. Sorry for my previous bloated e-mail giving you wrong picture of what I'm suggesting.<br> 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:<br> 1. D-Bus (low-level API, or GLib bindings)<br> 2. Raw socket with custom protocol (similar to vdagent <-> vdagentd)<br> <br> Personally I'd prefer D-Bus, since looks like this is the best interface for freedesktop-based environments.<br> <br> 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).<br> <br> If D-Bus is approved, I can think of enhancing vdagent<->vdagentd communication from socket to D-Bus as well.<br> </blockquote> <br></div> I don't think that any dbus api will be needed the agent can simply change the gsettings for these, and then<br> gnome-shell will notice the change and react accordingly, at least I assume this is how the control-center<br> settings work and get applied. Even if I'm wrong about the gsettings bit, there has to be an API between<br> the control-center and gnome-shell, and rather then inventing a new one it would be good for the agent to<br> re-use the existing one to talk to gnome-shell / gsd<br> <br> Regards,<br> <br> Hans<br> <br> </blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Fedor </div>