from:"Fedor Lyakhov"

Re: [Spice-devel] Building Spice in an IDE

2014-02-25 Thread Fedor Lyakhov

Hi,

While Eclipse has support for C/C++ development, IMHO it is fairly
poor compared to other IDEs designed for C/C++ only. Personally I use
KDevelop, and haven't seen any issues with using it for Spice
development. Probably Qt Creator will work as well...

On Mon, Feb 24, 2014 at 7:06 PM, Alon Levy al...@redhat.com wrote:
 On 02/01/2014 12:54 AM, Wade Johnson wrote:
 Hi, I am trying to build Spice in Eclipse and make a test environment, but
 I am having some issues mostly with some dependencies not being resolved,
 and some constant definitions not being found. Are there any pointers or
 build guides to getting Spice set up in Eclipse that you guys have?

 I haven't tried doing that. If you are building spice-server you need to
 do git submodule init; git submodule update and you need to install
 some dependencies - pixman mainly, opus.

 In summary, if you post a specific error message it would help. The wiki
 has the development instructions here:
 http://www.spice-space.org/page/Building_Instructions (pointed to from
 main page via http://www.spice-space.org/page/DeveloperStartPage)


 Thanks,
 Wade Johnson



 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel



-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Meeting at FOSDEM'14

2014-02-01 Thread Fedor Lyakhov

I have missed the meeting unfortunately... have you decided where to meet
and talk a bit?
-Fedor
31 янв. 2014 г. 15:52 пользователь Christophe Fergeau cferg...@redhat.com
написал:

 On Tue, Jan 28, 2014 at 10:04:52AM -0600, Jeremy White wrote:
  So, say 10:45 in h1308?  For those of us that don't know most of the
  relevant faces, could we have a sign or some way of knowing which
  group of people are the Spice ones?

 There probably won't be too many people in the room at 10.45. I'll be
 wearing my red guadec tshirt (if I remember...) and will most likely be
 in the first rows.

 Christophe

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Meeting at FOSDEM'14

2014-01-20 Thread Fedor Lyakhov

Ok, so we need to meet on Saturday. Need to decide when and where. We
need a place for 5-10ppl probably. What about using BoF room?
(https://fosdem.org/2014/news/2014-01-17-bof-rooms/) I'm new to
FOSDEM, don't know whether it would be good for such a meeting...

Another seemingly good location - Desktops room
(https://fosdem.org/2014/schedule/track/desktops/,
https://fosdem.org/2014/schedule/room/h1308_rolin/) - it starts at
11:00 - will it be opened earlier? And I'm going to attend GStreamer
talk there for sure...

On Mon, Jan 20, 2014 at 6:45 PM, Jeremy White jwh...@codeweavers.com wrote:
 I'll be around too, though probably not a the beer event (too crowded for
 me ;) But we definitely have to meet!


 I'll be there too.  Sadly, I can't make the talk, as I'll be in the Wine dev
 room all day Sunday.

 Could another time work?

 Cheers,

 Jeremy
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel



-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] Add reference manual

2014-01-16 Thread Fedor Lyakhov

BTW, where the compiled manual can be looked at? It seems to be
extremely useful as there is little up-to-date Spice documentation...

On Thu, Jan 16, 2014 at 3:41 PM, Alon Levy al...@redhat.com wrote:
 On 01/13/2014 10:26 PM, Christophe Fergeau wrote:

 Ack!

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH server] Associate org.spice-space.webdav.0 port to webdav channel

2014-01-13 Thread Fedor Lyakhov

May be better to avoid hardcoding the port name there using e.g.
static const char * instead?

On Sun, Jan 12, 2014 at 9:34 PM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
 For example, with qemu, a webdav channel can be created this way:

  -chardev spiceport,name=org.spice-space.webdav.0,...

 And redirected to a virtio port:

  -device virtserialport,...,name=org.spice-space.webdav.0
 ---
  server/reds.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

 diff --git a/server/reds.c b/server/reds.c
 index 2a0002b..2c63154 100644
 --- a/server/reds.c
 +++ b/server/reds.c
 @@ -3668,7 +3668,11 @@ static int 
 spice_server_char_device_add_interface(SpiceServer *s,
  dev_state = spicevmc_device_connect(char_device, 
 SPICE_CHANNEL_USBREDIR);
  }
  else if (strcmp(char_device-subtype, SUBTYPE_PORT) == 0) {
 -dev_state = spicevmc_device_connect(char_device, SPICE_CHANNEL_PORT);
 +if (strcmp(char_device-portname, org.spice-space.webdav.0) == 0) {
 +dev_state = spicevmc_device_connect(char_device, 
 SPICE_CHANNEL_WEBDAV);
 +} else {
 +dev_state = spicevmc_device_connect(char_device, 
 SPICE_CHANNEL_PORT);
 +}
  }

  if (dev_state) {
 @@ -4206,6 +4210,7 @@ SPICE_GNUC_VISIBLE int 
 spice_server_set_channel_security(SpiceServer *s, const c
  [ SPICE_CHANNEL_SMARTCARD] = smartcard,
  #endif
  [ SPICE_CHANNEL_USBREDIR ] = usbredir,
 +[ SPICE_CHANNEL_WEBDAV ] = webdav,
  };
  int i;

 --
 1.8.4.2

 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel



-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects

2014-01-12 Thread Fedor Lyakhov

Ping...

On Tue, Dec 31, 2013 at 2:28 AM, Fedor Lyakhov fedor.lyak...@gmail.com wrote:
 Hi all,

 I've sent a preview patch of this work. Please confirm
 1) the names of the bus, interface, object path
 2) the interface itself (currently 3 read-only properties: Connected,
 Type and Speed)
 3) I'm not sure whether lazy generation of GDBusNodeInfo from
 introspection XML (as static char *) is acceptable - or should I use
 gdbus-codegen?

 My next steps include:
 1. Implement export of actual properties, i.e. connection status,
 connection type (local/remote) and speed (in kbps). The idea is that
 clients are expected to use Speed to judge upon disabling some
 features like animations.
 2. Implement signal on properties changed
 3. Other TODOs (GIO 2.32 thread API change, error handling, doc  comments 
 etc.)


 On Mon, Dec 16, 2013 at 2:12 PM, Marc-André Lureau mlur...@redhat.com wrote:
 Hi

 - Original Message -
 Hi everyone,

 As we've decided a while ago (ITT), I'm looking into implementing a
 DBus interface for spice-vdagent (session-level) using GDbus API from
 GIO, and have run into following shortcomings:

 1. vdagent is single-threaded and blocks on select() for udscs I/O
 2. vdagent isn't GLib-based

 A simplest solution I'm going to try first:
 1. Add GLib main loop in the vdagent main thread
 2. Create a separate GThread for all current I/O

 Will such change be acceptable?

 Next steps I can think of:
 1. Use GSource to attach current udscs I/O to GMainLoop
 2. Move most of current udscs messages to DBus - probably need to keep
 using udscs for xfer for performance reasons.

 What do you think?

 Using GLib for main loop would be a good step forward.

 I am not sure using a separate thread for current IO is needed, but it might 
 make it easier for a first step?

 thanks!



 --
 Best regards,
 Fedor



-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH linux vdagent] Bug62033: export ConnectionInfo interface of vdagent via D-Bus

2013-12-30 Thread Fedor Lyakhov

This is RFC/preview-only patch - initial work of adding D-Bus
interface for vdagent.

---
 Makefile.am|  12 +++--
 configure.ac   |   3 +-
 src/vdagent-dbus.c | 126 +
 src/vdagent-dbus.h |  27 
 src/vdagent.c  |  30 +
 5 files changed, 194 insertions(+), 4 deletions(-)
 create mode 100644 src/vdagent-dbus.c
 create mode 100644 src/vdagent-dbus.h

diff --git a/Makefile.am b/Makefile.am
index 74cc313..c61a0dd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4,9 +4,14 @@ NULL =
 bin_PROGRAMS = src/spice-vdagent
 sbin_PROGRAMS = src/spice-vdagentd

-src_spice_vdagent_CFLAGS = $(X_CFLAGS) $(SPICE_CFLAGS) $(GLIB2_CFLAGS)
-src_spice_vdagent_LDADD = $(X_LIBS) $(SPICE_LIBS) $(GLIB2_LIBS)
-src_spice_vdagent_SOURCES = src/vdagent.c src/vdagent-x11.c
src/vdagent-x11-randr.c src/vdagent-file-xfers.c src/udscs.c
+src_spice_vdagent_CFLAGS = $(X_CFLAGS) $(SPICE_CFLAGS)
$(GLIB2_CFLAGS) ${GIO2_CFLAGS}
+src_spice_vdagent_LDADD = $(X_LIBS) $(SPICE_LIBS) $(GLIB2_LIBS) ${GIO2_LIBS}
+src_spice_vdagent_SOURCES = src/vdagent.c \
+src/vdagent-x11.c \
+src/vdagent-x11-randr.c \
+src/vdagent-file-xfers.c \
+src/udscs.c \
+src/vdagent-dbus.c

 src_spice_vdagentd_CFLAGS = $(DBUS_CFLAGS) $(LIBSYSTEMD_LOGIN_CFLAGS) \
   $(PCIACCESS_CFLAGS) $(SPICE_CFLAGS) $(GLIB2_CFLAGS) $(PIE_CFLAGS)
@@ -34,6 +39,7 @@ noinst_HEADERS = src/glib-compat.h \
  src/vdagent-virtio-port.h \
  src/vdagent-x11.h \
  src/vdagent-x11-priv.h \
+ src/vdagent-dbus.h \
  src/vdagentd-proto.h \
  src/vdagentd-proto-strings.h \
  src/vdagentd-uinput.h \
diff --git a/configure.ac b/configure.ac
index 79905a8..2d98c43 100644
--- a/configure.ac
+++ b/configure.ac
@@ -76,7 +76,8 @@ AC_ARG_ENABLE([static-uinput],
   [enable_static_uinput=$enableval],
   [enable_static_uinput=no])

-PKG_CHECK_MODULES([GLIB2], [glib-2.0 = 2.12])
+PKG_CHECK_MODULES([GLIB2], [glib-2.0 = 2.26])
+PKG_CHECK_MODULES([GIO2], [gio-2.0 = 2.26])
 PKG_CHECK_MODULES(X, [xfixes xrandr = 1.3 xinerama x11])
 PKG_CHECK_MODULES(SPICE, [spice-protocol = 0.12.5])

diff --git a/src/vdagent-dbus.c b/src/vdagent-dbus.c
new file mode 100644
index 000..47f1d31
--- /dev/null
+++ b/src/vdagent-dbus.c
@@ -0,0 +1,126 @@
+/*  vdagent-dbus.c vdagent dbus interface
+
+Copyright 2013 Fedor Lyakhov
+
+Authors:
+Fedor Lyakhov fedor.lyak...@gmail.com
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program.  If not, see http://www.gnu.org/licenses/.
+*/
+
+#include stdio.h
+#include syslog.h
+#include glib.h
+#include gio/gio.h
+
+#include spice/vd_agent.h
+#include vdagent-dbus.h
+
+static const char *vdagent_dbus_name = com.redhat.spice.vdagent;
+static guint vdagent_dbus_name_owner_id = 0;
+static const char *vdagent_dbus_connection_info_object_path =
+/com/redhat/spice/vdagent/ConnectionInfo;
+
+/* Introspection data for vdagent service */
+/* TODO: document the interface */
+static const gchar *vdagent_dbus_introspection_xml =
+  node
+interface name='com.redhat.spice.vdagent.ConnectionInfo'
+  property type='b' name='Connected' access='read' /
+  property type='s' name='Type' access='read' / /* local, remote */
+  property type='u' name='Speed' access='read' / /* In kbps,
e.g. 512K, 1024K = 1M etc. */
+/interface
+  /node;
+
+static GDBusNodeInfo *vdagent_dbus_introspection_data = NULL;
+
+static GVariant *vdagent_dbus_handle_get_property(GDBusConnection
*connection, const gchar *sender,
+const gchar *object_path, const gchar *interface_name, const
gchar *property_name,
+GError **error, gpointer user_data)
+{
+GVariant *ret = NULL;
+
+syslog(LOG_DEBUG, Handling D-Bus get property);
+
+/* TODO: implement actual handlers */
+if (g_strcmp0(property_name, Connected) == 0)
+{
+ret = g_variant_new_boolean(TRUE);
+}
+else if (g_strcmp0 (property_name, Type) == 0)
+{
+ret = g_variant_new_string(remote);
+}
+else if (g_strcmp0 (property_name, Speed) == 0)
+{
+ret = g_variant_new_uint32(512);
+}
+return ret;
+}
+
+static const GDBusInterfaceVTable vdagent_dbus_interface_vtable =
+{
+  NULL

Re: [Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects

2013-12-30 Thread Fedor Lyakhov

Hi all,

I've sent a preview patch of this work. Please confirm
1) the names of the bus, interface, object path
2) the interface itself (currently 3 read-only properties: Connected,
Type and Speed)
3) I'm not sure whether lazy generation of GDBusNodeInfo from
introspection XML (as static char *) is acceptable - or should I use
gdbus-codegen?

My next steps include:
1. Implement export of actual properties, i.e. connection status,
connection type (local/remote) and speed (in kbps). The idea is that
clients are expected to use Speed to judge upon disabling some
features like animations.
2. Implement signal on properties changed
3. Other TODOs (GIO 2.32 thread API change, error handling, doc  comments etc.)


On Mon, Dec 16, 2013 at 2:12 PM, Marc-André Lureau mlur...@redhat.com wrote:
 Hi

 - Original Message -
 Hi everyone,

 As we've decided a while ago (ITT), I'm looking into implementing a
 DBus interface for spice-vdagent (session-level) using GDbus API from
 GIO, and have run into following shortcomings:

 1. vdagent is single-threaded and blocks on select() for udscs I/O
 2. vdagent isn't GLib-based

 A simplest solution I'm going to try first:
 1. Add GLib main loop in the vdagent main thread
 2. Create a separate GThread for all current I/O

 Will such change be acceptable?

 Next steps I can think of:
 1. Use GSource to attach current udscs I/O to GMainLoop
 2. Move most of current udscs messages to DBus - probably need to keep
 using udscs for xfer for performance reasons.

 What do you think?

 Using GLib for main loop would be a good step forward.

 I am not sure using a separate thread for current IO is needed, but it might 
 make it easier for a first step?

 thanks!



-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects

2013-12-15 Thread Fedor Lyakhov

Hi everyone,

As we've decided a while ago (ITT), I'm looking into implementing a
DBus interface for spice-vdagent (session-level) using GDbus API from
GIO, and have run into following shortcomings:

1. vdagent is single-threaded and blocks on select() for udscs I/O
2. vdagent isn't GLib-based

A simplest solution I'm going to try first:
1. Add GLib main loop in the vdagent main thread
2. Create a separate GThread for all current I/O

Will such change be acceptable?

Next steps I can think of:
1. Use GSource to attach current udscs I/O to GMainLoop
2. Move most of current udscs messages to DBus - probably need to keep
using udscs for xfer for performance reasons.

What do you think?

-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] RFC: Media redirection for Spice remote computing solution, an event for FOSDEM'14, Virtualization dev room

2013-12-02 Thread Fedor Lyakhov

Thanks, David!

We have an internal proof of concept based on private VoIP softphone,
Thrift over TCP as RPC and Google WebRTC as Media Engine - and the
softphone is capable of audio calls and remote control of audio
devices. So now we're confident it can work.

We hope to create open-source prototype for a demo GStreamer-based
audio player by the end of January. Depending on how it goes, we will
add basic integration with Spice as well.


On Mon, Dec 2, 2013 at 3:26 PM, David Jaša dj...@redhat.com wrote:
 The slides are very nice and if you already have some prototype
 finished, it would be cool to see it in action!

 David


 Fedor Lyakhov píše v So 30. 11. 2013 v 17:11 +0400:
 Hello Spice developers and users,

 I'm going to apply for FOSDEM'14 Virtualization dev room with event
 Media Redirection for Spice remote computing solution (deadline is
 tomorrow...). The event would include a 20-minute lecture, 5-minute
 demo of a prototype and 10-minute QA session.

 Before I apply, I'd like to hear your comments on the proposed event
 (and you're the main audience of it!). I'd appreciate any comments
 about title, abstract, outline and the presentation drafts
 (http://www.spice-space.org/wiki/images/b/b9/Fosdem2014-lyakhov-v2.pdf).
 Hope that with your comments I can get this application better and get
 it accepted.

 Title: Media redirection for Spice remote computing solution
 Subtitle: Optimizing media stream processing for media players and
 VoIP clients in virtual desktop infrastructures

 Abstract:
 Handling of media streams is suboptimal in virtual desktop
 infrastructures if it is done at virtual machines. Consider two main
 use case:
 * Playback of a media stream from remote server e.g. user watches Youtube
 * IP telephony e.g. user makes a video call
 In both cases media streams are not delivered to the user's device
 directly but transcoded at the virtualization server. This results in
 increased network load, server CPU load (less VM density), quality
 loss of media streams. A solution for this problem, Media Redirection
 for Red Hat Spice remote computing system is proposed
 (www.spice-space.org/page/Features/MediaRedirection).

 Solution concept introduces following components: Media Engine and
 RPC-like service at user's device, Media Engine stubs and RPC-like
 client at Guest OS. To integrate the solution with Spice, new Spice
 APIs are proposed: API for establishing virtual channels and API for
 overlay rendering.

 A working Media Redirection prototype will be demonstrated using a
 demo audio player, Apache Thrift as RPC system, GStreamer as Media
 Engine.

 The event will be interesting for remote computing system developers
 and users (in particular, Red Hat Spice), RPC system developers and
 users, media engine developers, media player and IP telephony client
 developers.

 Note: the authors are NOT working for Red Hat, this work is being done
 by volunteers in their spare time.

 Outline:
 * Common media processing usecases
 * Red Hat Spice overview
 * Description of media stream processing problem in VDI
 * Media redirection concept description
 * Media redirection prototype description and demo
 * Feature evolution plan
 Discussion topics:
 * architecture  design considerations
 * new Spice APIs for virtual channels and overlay rendering
 * fault-tolerance practices (crash, disconnect)


 --

 David Jaša, RHCE

 SPICE QE based in Brno
 GPG Key: 22C33E24
 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] RFC: Media redirection for Spice remote computing solution, an event for FOSDEM'14, Virtualization dev room

2013-12-02 Thread Fedor Lyakhov

Hi Steven,

On Mon, Dec 2, 2013 at 7:14 PM, Steven Newbury st...@snewbury.org.uk wrote:
 On Mon, 2013-12-02 at 18:16 +0400, Fedor Lyakhov wrote:
 Thanks, David!

 We have an internal proof of concept based on private VoIP softphone,
 Thrift over TCP as RPC and Google WebRTC as Media Engine - and the
 softphone is capable of audio calls and remote control of audio
 devices. So now we're confident it can work.

 We hope to create open-source prototype for a demo GStreamer-based
 audio player by the end of January. Depending on how it goes, we will
 add basic integration with Spice as well.
 Wouldn't it be possible to implement this at the acceleration layer
 within the guest by providing a VDPAU or VA-API (and Windows API
 equivalent) driver which offloads the hw decoding of the media stream to
 the Spice client?


I'm by no means an expert in video acceleration, so I may be wrong,
but there are following considerations:
1. If I understand correctly, you're talking about video pass-through
feature. It is different from media redirection. This implementation
via acceleration layer implies the video stream is processed at
virtual machine; it may be not transcoded, just sent to the client,
but this is still suboptimal for our targeted use cases. We want to
completely off-load the media processing to the client, so the stream
doesn't even reach virtualization server at all. It must go P2P.

But I must admit this possible implementation via VAAPI can be really
the best for 2 use cases:
a) a video file is already available at the virtual machine
b) media redirection doesn't work for some reason (e.g. not supported engine)
So this is certainly useful feature...

2. What about audio? Is it just kept as is now? That may be Ok for
video playback use case, but certainly not acceptable from VoIP PoV.


-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] RFC: Media redirection for Spice remote computing solution, an event for FOSDEM'14, Virtualization dev room

2013-11-30 Thread Fedor Lyakhov

Hello Spice developers and users,

I'm going to apply for FOSDEM'14 Virtualization dev room with event
Media Redirection for Spice remote computing solution (deadline is
tomorrow...). The event would include a 20-minute lecture, 5-minute
demo of a prototype and 10-minute QA session.

Before I apply, I'd like to hear your comments on the proposed event
(and you're the main audience of it!). I'd appreciate any comments
about title, abstract, outline and the presentation drafts
(http://www.spice-space.org/wiki/images/b/b9/Fosdem2014-lyakhov-v2.pdf).
Hope that with your comments I can get this application better and get
it accepted.

Title: Media redirection for Spice remote computing solution
Subtitle: Optimizing media stream processing for media players and
VoIP clients in virtual desktop infrastructures

Abstract:
Handling of media streams is suboptimal in virtual desktop
infrastructures if it is done at virtual machines. Consider two main
use case:
* Playback of a media stream from remote server e.g. user watches Youtube
* IP telephony e.g. user makes a video call
In both cases media streams are not delivered to the user's device
directly but transcoded at the virtualization server. This results in
increased network load, server CPU load (less VM density), quality
loss of media streams. A solution for this problem, Media Redirection
for Red Hat Spice remote computing system is proposed
(www.spice-space.org/page/Features/MediaRedirection).

Solution concept introduces following components: Media Engine and
RPC-like service at user's device, Media Engine stubs and RPC-like
client at Guest OS. To integrate the solution with Spice, new Spice
APIs are proposed: API for establishing virtual channels and API for
overlay rendering.

A working Media Redirection prototype will be demonstrated using a
demo audio player, Apache Thrift as RPC system, GStreamer as Media
Engine.

The event will be interesting for remote computing system developers
and users (in particular, Red Hat Spice), RPC system developers and
users, media engine developers, media player and IP telephony client
developers.

Note: the authors are NOT working for Red Hat, this work is being done
by volunteers in their spare time.

Outline:
* Common media processing usecases
* Red Hat Spice overview
* Description of media stream processing problem in VDI
* Media redirection concept description
* Media redirection prototype description and demo
* Feature evolution plan
Discussion topics:
* architecture  design considerations
* new Spice APIs for virtual channels and overlay rendering
* fault-tolerance practices (crash, disconnect)

-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk 3/5] Add SpiceVMC GIOStream

2013-11-17 Thread Fedor Lyakhov

Marc,

What does VMC stand for here? Is it related to my idea of virtual
media controller, or just a coincidence?
Looks like it is related, as it is a transport API to be used for
anyone wanting to pass arbitrary data through additional Spice channel
- correct?
If so, I suggest renaming this component so it has more generic and
clear name - as VMC may be confusing for others... I don't have good
proposals right now though, only semi-good like data_stream,
custom_stream, generic_stream, transport_stream... Also, having a
comment inside the header describing the purpose of the API would
help.

Small update from us: we are doing an internal VMC proof of concept,
it is based on closed and open-source software we're familiar with -
to speed the things up. For this initial PoC, we're using our own
wrapper over Google WebRTC media engine (instead of GStreamer, which
we need to learn) and Apache Thrift RPC transported over TCP socket.
Things look good so far - remote control of speakers and mic work
fine, working on an IP call now...

After that, I'm planning to work on a GStreamer-based prototype - and
later use this VmcStream to implement Thrift transport interface.
Actually, what do you think about using Thrift for RPC? It looks like
suiting our needs better than Google Protocol Buffers - at least it is
a complete RPC solution while protobuf provides only marshaling, the
whole RPC needs to be added on top of it...


On Sat, Nov 16, 2013 at 1:15 AM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
 From: Marc-André Lureau marcandre.lur...@redhat.com

 This allows to use conveniently GIOStream APIs without caring about
 coroutine and Spice messages details.
 ---
  gtk/Makefile.am  |   2 +
  gtk/channel-base.c   |  48 ++
  gtk/channel-port.c   |  33 +---
  gtk/spice-channel-priv.h |   8 +
  gtk/vmcstream.c  | 436 
 +++
  gtk/vmcstream.h  |  69 
  6 files changed, 566 insertions(+), 30 deletions(-)
  create mode 100644 gtk/vmcstream.c
  create mode 100644 gtk/vmcstream.h

 diff --git a/gtk/Makefile.am b/gtk/Makefile.am
 index f82e614..7b38d1c 100644
 --- a/gtk/Makefile.am
 +++ b/gtk/Makefile.am
 @@ -253,6 +253,8 @@ libspice_client_glib_2_0_la_SOURCES = 
   \
 usbutil.c   \
 usbutil.h   \
 $(USB_ACL_HELPER_SRCS)  \
 +   vmcstream.c \
 +   vmcstream.h \
 \
 decode.h\
 decode-glz.c\
 diff --git a/gtk/channel-base.c b/gtk/channel-base.c
 index 646042d..363dda5 100644
 --- a/gtk/channel-base.c
 +++ b/gtk/channel-base.c
 @@ -232,3 +232,51 @@ void spice_channel_set_handlers(SpiceChannelClass *klass,
  spice_channel_add_base_handlers(klass);
  set_handlers(klass, handlers, n);
  }
 +
 +static void
 +vmc_write_free_cb(uint8_t *data, void *user_data)
 +{
 +GSimpleAsyncResult *result = user_data;
 +
 +g_simple_async_result_complete_in_idle(result);
 +g_object_unref(result);
 +}
 +
 +G_GNUC_INTERNAL
 +void spice_vmc_write_async(SpiceChannel *self,
 +   const void *buffer, gsize count,
 +   GCancellable *cancellable,
 +   GAsyncReadyCallback callback,
 +   gpointer user_data)
 +{
 +SpiceMsgOut *msg;
 +GSimpleAsyncResult *simple;
 +
 +simple = g_simple_async_result_new(G_OBJECT(self), callback, user_data,
 +   spice_port_write_async);
 +g_simple_async_result_set_op_res_gssize(simple, count);
 +
 +msg = spice_msg_out_new(SPICE_CHANNEL(self), SPICE_MSGC_SPICEVMC_DATA);
 +spice_marshaller_add_ref_full(msg-marshaller, (uint8_t*)buffer, count,
 +  vmc_write_free_cb, simple);
 +spice_msg_out_send(msg);
 +}
 +
 +G_GNUC_INTERNAL
 +gssize spice_vmc_write_finish(SpiceChannel *self,
 +  GAsyncResult *result, GError **error)
 +{
 +GSimpleAsyncResult *simple;
 +
 +g_return_val_if_fail(result != NULL, -1);
 +
 +simple = (GSimpleAsyncResult *)result;
 +
 +if (g_simple_async_result_propagate_error(simple, error))
 +return -1;
 +
 +g_return_val_if_fail(g_simple_async_result_is_valid(result, 
 G_OBJECT(self),
 +
 spice_port_write_async), -1);
 +
 +return g_simple_async_result_get_op_res_gssize(simple);
 +}
 diff --git a/gtk/channel-port.c b/gtk/channel-port.c
 index 11948bb..ec3de86 100644
 --- a/gtk/channel-port.c
 +++ b/gtk/channel-port.c
 @@ -286,14 +286,6 @@ static void port_handle_msg(SpiceChannel *channel, 
 SpiceMsgIn *in)
  emit_main_context(channel,

Re: [Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects

2013-11-07 Thread Fedor Lyakhov

OK, got it. Thanks for your patience. I'll CC you once the patch is ready...

I understand reasons behind both of the approaches - this one is
simple. But I'd need to add Spice vdagent D-Bus API for exactly this
one use case... hope that more interface functions will need to be
exposed in future.

Also this approach won't make the
--spice-disable-effects=wallpaper,font-smooth,animation,all option
to work (and implementing it using just gio's gsettings interface
looks unreliable... that's why inhibitor-styled API was proposed
actually). But we can live without it.

On Thu, Nov 7, 2013 at 10:32 PM, Bastien Nocera had...@hadess.net wrote:
 On Thu, 2013-11-07 at 22:25 +0400, Fedor Lyakhov wrote:
 Hi Bastein,

 On Mon, Nov 4, 2013 at 4:27 PM, Hans de Goede hdego...@redhat.com wrote:
  Hi,
 
 
  On 11/02/2013 05:50 PM, Fedor Lyakhov wrote:
 
  Bastein, Hans,
 
  We need an agreement on this topic so I can implement something - and
  have it accepted in both Spice and Gnome eventually.
 
  There are 2 possible approaches conflicting here:
  (i) (spice-proposed) DEs to export API for toggling effects
  (preferable inhibitor-styled). Spice to actively use this API as it
  sees fit.
  (ii) (gnome-proposed) Spice to export API about its internal state,
  DEs to recognize Spice and use that API as they want (e.g. disable
  effects).
 
  Both approaches can work, and second one seems to be easier to
  implement for Spice/Gnome stack.
  Main arguments pro (i):
  1. It seems right for Spice to be in an active position, deciding what
  to do. DEs are merely environments providing APIs and means for
  applications to achieve their goals.
  2. Spice aims to support many DEs, not only Gnome (mainly under
  freedesktop, ofc). Making other DEs to recognize Spice usage and
  implement appropriate logic seems to be incorrect approach, which may
  be not acceptable from their PoV.
 
  To address Bastein's concern about new inhibitors: we want them to be
  system ones, similar to existing idle and other inhibitors. Not
  something in the user space of Spice. They should be useful for other
  remoting applications like VNC, and maybe some other apps (cannot
  think up other real use cases right now).
 
 
  Either way works for me, with a slight preferences for having inhibitors.
 
  Regards,
 
  Hans

 Bastein, how much are you against Spice-proposed approach? If I can
 reduce your concerns, I'm willing to do so...

 I'm not interested in adding a layer of inhibitors on top of something
 that supposed to be simple. As long as I have something that exports the
 whether or not SPICE is being used and/or too slow, I can implement the
 necessary code in gnome-settings-daemon.

 FWIW, this is the API that g-s-d uses for VNC connections, when Vino is
 used:
 $ gdbus introspect --session --dest org.gnome.Vino --object-path 
 /org/gnome/vino/screens/0
 snip
   interface org.gnome.VinoScreen {
 methods:
 signals:
 properties:
   readonly s ExternalHost = '';
   readonly q ExternalPort = 0;
   readonly s AvahiHost = 'nuvo.local';
   readonly s Host = '192.168.0.14';
   readonly q Port = 5900;
   readonly b Connected = false;
   };
 snip

 We just look at the Connected value. I'm looking for something
 just about as simple for Spice.

 Cheers




-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects

2013-11-02 Thread Fedor Lyakhov

Bastein, Hans,

We need an agreement on this topic so I can implement something - and
have it accepted in both Spice and Gnome eventually.

There are 2 possible approaches conflicting here:
(i) (spice-proposed) DEs to export API for toggling effects
(preferable inhibitor-styled). Spice to actively use this API as it
sees fit.
(ii) (gnome-proposed) Spice to export API about its internal state,
DEs to recognize Spice and use that API as they want (e.g. disable
effects).

Both approaches can work, and second one seems to be easier to
implement for Spice/Gnome stack.
Main arguments pro (i):
1. It seems right for Spice to be in an active position, deciding what
to do. DEs are merely environments providing APIs and means for
applications to achieve their goals.
2. Spice aims to support many DEs, not only Gnome (mainly under
freedesktop, ofc). Making other DEs to recognize Spice usage and
implement appropriate logic seems to be incorrect approach, which may
be not acceptable from their PoV.

To address Bastein's concern about new inhibitors: we want them to be
system ones, similar to existing idle and other inhibitors. Not
something in the user space of Spice. They should be useful for other
remoting applications like VNC, and maybe some other apps (cannot
think up other real use cases right now).


On Thu, Oct 31, 2013 at 9:31 PM, Bastien Nocera had...@hadess.net wrote:
 On Thu, 2013-10-31 at 14:44 +0400, Fedor Lyakhov wrote:
 Hi Bastien,

 I'm working on a bug/enhancement for Spice reported by Zeeshan:
 https://bugs.freedesktop.org/show_bug.cgi?id=62033 (Means to detect
 local-only). It is related to Gnome bug
 https://bugzilla.gnome.org/show_bug.cgi?id=680195 (Disable animations
 when on slow VNC or spice)

 We've discussed possible solutions for this issue in the spice-devel
 mailing list (the last message in the thread -
 http://lists.freedesktop.org/archives/spice-devel/2013-September/014562.html).

 Summary of the issue:
 Need to disable desktop effects (animation, wallpaper, font smoothing)
 when user is connected via Spice over slow network.

 Proposed solution:
 (i) Use existing --spice-disable-effects option which works for
 Windows guests already: implement such functionality for Linux guests.
 The feature can be invoked from oVirt, so it will be useful.
 (ii) Implement the feature via inhibitors: Spice vdagent to call
 DE-provided inhibitor-styled D-Bus API to inhibit animation, wallpaper
 and font smoothing. This way the feature will be supported at any DE
 which provides such API - hopefully we can get support for Gnome3, KDE
 (5?) and Unity (minimum list).

 Does the solution seem reasonable for you? Any comments would be appreciated.

 The only thing that spice needs to do is export the fact that it's
 running on a slow link. gnome-settings-daemon will take care of reading
 that and acting accordingly.

 There's no need for spice to know what the desktop environment will make
 of it.

 I have few additional questions:
 1. I know you have been involved into Inhibitor API discussions with
 KDE folks about a year ago (I've seen only
 http://lists.freedesktop.org/pipermail/xdg/2012-November/012580.html
 thread). Could you please summarize the current status of this API in
 Gnome and maybe KDE (including all inhibitors, not only screen saver)?
 I cannot find any relevant documentation about this...

 The specification website is currently broken, but that's what I had:
 http://people.freedesktop.org/~hadess/idle-inhibition-spec/index.html

 It's only for enabling idle inhibition, nothing else.

 2. What do you think about adding new inhibitors for our needs? Where
 should I start from? Is the implementation need to be added to
 gnome-desktop-settings?

 It's a system plumbing issue, and inhibitors are for applications, so
 I'd be against it.

 Cheers




-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects

2013-10-31 Thread Fedor Lyakhov

Hi Bastien,

I'm working on a bug/enhancement for Spice reported by Zeeshan:
https://bugs.freedesktop.org/show_bug.cgi?id=62033 (Means to detect
local-only). It is related to Gnome bug
https://bugzilla.gnome.org/show_bug.cgi?id=680195 (Disable animations
when on slow VNC or spice)

We've discussed possible solutions for this issue in the spice-devel
mailing list (the last message in the thread -
http://lists.freedesktop.org/archives/spice-devel/2013-September/014562.html).

Summary of the issue:
Need to disable desktop effects (animation, wallpaper, font smoothing)
when user is connected via Spice over slow network.

Proposed solution:
(i) Use existing --spice-disable-effects option which works for
Windows guests already: implement such functionality for Linux guests.
The feature can be invoked from oVirt, so it will be useful.
(ii) Implement the feature via inhibitors: Spice vdagent to call
DE-provided inhibitor-styled D-Bus API to inhibit animation, wallpaper
and font smoothing. This way the feature will be supported at any DE
which provides such API - hopefully we can get support for Gnome3, KDE
(5?) and Unity (minimum list).

Does the solution seem reasonable for you? Any comments would be appreciated.

I have few additional questions:
1. I know you have been involved into Inhibitor API discussions with
KDE folks about a year ago (I've seen only
http://lists.freedesktop.org/pipermail/xdg/2012-November/012580.html
thread). Could you please summarize the current status of this API in
Gnome and maybe KDE (including all inhibitors, not only screen saver)?
I cannot find any relevant documentation about this...

2. What do you think about adding new inhibitors for our needs? Where
should I start from? Is the implementation need to be added to
gnome-desktop-settings?


-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] RFC: Virtual Media Controller (VMC) concept: enhancing IP telephony systems in Spice VDI

2013-10-15 Thread Fedor Lyakhov

Marc-André,

Thanks for the comments! I'll certainly follow your advice. About wiki
- how to create account there? Tried
http://www.spice-space.org/wiki/index.php?title=Special:UserLoginreturnto=Main_Page
but it returns empty page for me...

Few comments below.


On Tue, Oct 15, 2013 at 2:09 PM, Marc-André Lureau mlur...@redhat.com wrote:


 - Original Message -
 Hello Spice developers,

 I want to introduce my idea of Virtual Media Controller (VMC),
 enhancing support for IP telephony in Spice-based VDI. Hope for your
 feedback!
 This is a concept only, very high level and without any Proof of
 Concept implemented yet. The concept is divided into 3 levels: VMC
 API, VMC Advanced and VMC Ultimate. The level of unknown increases
 with them. VMC API seems to be fairly straightforward and doable,
 others are more risky and already have known open issues questioning a
 possibility to implement them (and probably much more I'm not aware of
 yet).

 *Why VMC is needed?*
 Main problem of IP telephony software running in VDI is media stream
 hairpinning at VDI server. Let we have Alice and Bob working in office
 O2, they're connecting to their virtual desktops at VDI server in a
 main office O1. They're using softphones running at the VMs to make a
 p2p audio call (video part behaves similarly, just adds unnecessary
 complication to this example). Let's look at the route of Alice's
 outgoing audio stream. Audio is captured from microphone at her
 PC/thin client, then encoded by Spice client and sent over Spice
 channel to VM, where it is decoded to PCM and presented as a source
 for virtual microphone. Softphone then encodes it once again and sends
 it to a peer, softphone of Bob running at another VM of the same VDI
 server. The stream is decoded once again, played into virtual speaker,
 which in turn encodes it and sends over Spice channel to Spice client
 at Bob's PC, where it is decoded and finally played out in a real
 headset.

 We can see 2 major issues with this scheme:
 1. Media stream is traveling via VDI server, not p2p. So even if 2
 people in office O2 are making a call, the traffic goes through VDI
 server at office O1. This introduces extra delay into the
 conversation, potentially increases jitter and packet loss (depends on
 network), and this results in extra network load.
 2. Media stream is transcoded (decoded and then encoded) at VDI server
 twice (if count Bob's stream, 4 times!). This means extra CPU usage of
 VDI server, effectively reducing VM density. This also means
 degradation of quality if lossy codecs are used.

 *VMC Solution*
 The most adequate solution to both issues is to make the conversation
 p2p, remove VDI server from the route entirely. So the question is
 only how to actually make it.
 First part of the VMC idea is to introduce a media engine at client
 side, and API for softphone developers to manipulate this engine. We
 may think about following components:
 1. VMC Agent - a component providing media-handling API for
 applications running at this virtual machine. [Probably would need to
 work through Spice agent, or via similar means - adding new virtual
 device to qemu]
 2. VMC Engine - media engine running at user's client/PC. It provides
 actual media handling and is controlled with commands from VMC Agent.
 3. VMC Transport - a component implementing connection between the
 agent and the engine. Actual design is TBD. This is some sort of RPC
 over Spice connection.
 4. VMC OverlayRenderer - this advanced component is needed for video
 support only. It integrates local video rendering inside virtual
 session window.

 Softphone developers would need to use VMC Agent API as a media engine
 for their application - so changes in the softphone are required.

 Although I don't know in details Telepathy, it looks like what you describe. 
 Except that audio/video stream is proxyed, and decoded directly in client. Is 
 that correct?


What do you mean saying 'media stream is proxyed'? We need P2P
connections, avoiding any proxy servers (within an IP network, that
is). So the stream is delivered directly and decoded in the client,
totally by-passing VDI server.

 1. agent: telepathy session  API

I have a generic agent in mind, not tied to particular softphone...
What about D-Bus-based common API and GStreamer, VLC and Google WebRTC
VoEViE wrappers as shared libraries? At start of softphone/media app,
it just links to our .so instead of its normal media engine - and gets
everything working, not even knowing that media is processed at the
client...

 2. engine: gstreamer
 3. tbd (rtp?), dedicated spice channel

Not RTP certainly, as this channel isn't for media transfer but for
RPC - agent calling functions of remote media engine.

 4. internal of spice client

Agree.

 *VMC Advanced*
 More general problem can be set: make arbitrary softphones running at
 VMs work without VDI hairpinning. Arbitrary means without code changes
 in these softphones. Solution of this

[Spice-devel] RFC: Virtual Media Controller (VMC) concept: enhancing IP telephony systems in Spice VDI

2013-10-14 Thread Fedor Lyakhov

Hello Spice developers,

I want to introduce my idea of Virtual Media Controller (VMC),
enhancing support for IP telephony in Spice-based VDI. Hope for your
feedback!
This is a concept only, very high level and without any Proof of
Concept implemented yet. The concept is divided into 3 levels: VMC
API, VMC Advanced and VMC Ultimate. The level of unknown increases
with them. VMC API seems to be fairly straightforward and doable,
others are more risky and already have known open issues questioning a
possibility to implement them (and probably much more I'm not aware of
yet).

*Why VMC is needed?*
Main problem of IP telephony software running in VDI is media stream
hairpinning at VDI server. Let we have Alice and Bob working in office
O2, they're connecting to their virtual desktops at VDI server in a
main office O1. They're using softphones running at the VMs to make a
p2p audio call (video part behaves similarly, just adds unnecessary
complication to this example). Let's look at the route of Alice's
outgoing audio stream. Audio is captured from microphone at her
PC/thin client, then encoded by Spice client and sent over Spice
channel to VM, where it is decoded to PCM and presented as a source
for virtual microphone. Softphone then encodes it once again and sends
it to a peer, softphone of Bob running at another VM of the same VDI
server. The stream is decoded once again, played into virtual speaker,
which in turn encodes it and sends over Spice channel to Spice client
at Bob's PC, where it is decoded and finally played out in a real
headset.

We can see 2 major issues with this scheme:
1. Media stream is traveling via VDI server, not p2p. So even if 2
people in office O2 are making a call, the traffic goes through VDI
server at office O1. This introduces extra delay into the
conversation, potentially increases jitter and packet loss (depends on
network), and this results in extra network load.
2. Media stream is transcoded (decoded and then encoded) at VDI server
twice (if count Bob's stream, 4 times!). This means extra CPU usage of
VDI server, effectively reducing VM density. This also means
degradation of quality if lossy codecs are used.

*VMC Solution*
The most adequate solution to both issues is to make the conversation
p2p, remove VDI server from the route entirely. So the question is
only how to actually make it.
First part of the VMC idea is to introduce a media engine at client
side, and API for softphone developers to manipulate this engine. We
may think about following components:
1. VMC Agent - a component providing media-handling API for
applications running at this virtual machine. [Probably would need to
work through Spice agent, or via similar means - adding new virtual
device to qemu]
2. VMC Engine - media engine running at user's client/PC. It provides
actual media handling and is controlled with commands from VMC Agent.
3. VMC Transport - a component implementing connection between the
agent and the engine. Actual design is TBD. This is some sort of RPC
over Spice connection.
4. VMC OverlayRenderer - this advanced component is needed for video
support only. It integrates local video rendering inside virtual
session window.

Softphone developers would need to use VMC Agent API as a media engine
for their application - so changes in the softphone are required.

*VMC Advanced*
More general problem can be set: make arbitrary softphones running at
VMs work without VDI hairpinning. Arbitrary means without code changes
in these softphones. Solution of this problem adds much more value to
Spice VDI, as any third-party applications, including commercial ones
like Skype, would be supported. Skype may be bad example... But modern
enterprise SIP or H.323-based softphones may be a good one (MS Lync to
name one).

But first of all, let's look into an interesting yet mostly
non-commercial case - Linux VM. For this case there is a chance of
implementing Agent API to follow APIs of widespread media engines -
GStreamer, VLC (what else?). This way we'd be able to support
arbitrary media apps based on these engines.
[Notes:
1. If we add Google WebRTC media engine bindings, softphone developers
who use this API should be able to add support for our system fairly
straightforwardly.
2. GStreamer, VLC, WebRTC are cross-platform, so implementing their
API may help with enabling support of some softphones at Windows VMs
as well]

One major part that needs additional work is signaling. The issue is
following: when a communication channel is established between 2
parties, they exchange their IP addresses in the signaling messages.
Softphone at VM will advertise its virtual IP address in such
situation - but we need to make the client to be the receiving end, so
we need client's IP address to appear in softphone's message. And we
want our solution to be as signaling protocol agnostic as possible,
i.e. parsing and changing IP address in signaling messages isn't an
option (and signaling traffic is usually guarded by

Re: [Spice-devel] Bug62033 Add support for --spice-disable-effects client option to spice-vdagent on Linux guests with Gnome3

2013-09-16 Thread Fedor Lyakhov

Hans,

Thanks for such a quick reply! I agree with your comments. Thanks for
pointing to inhibitors interface - I wasn't aware of it, need to study
it and see what KDE (and Unity) have in place.


On Mon, Sep 16, 2013 at 11:34 AM, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 09/15/2013 09:33 PM, Fedor Lyakhov wrote:

 Hello Hans,

 Finally I've found time to continue with this topic. Have sought for
 better solution and only come to improved previous one.

 *Requirements*


 Let's start with clarifying requirements.
 req-1. As a user I want to have my desktop effect settings untouched if
 connected under normal conditions.
 req-2. As a user I want to have a few desktop effect settings disabled if
 connected under bad conditions.
 The list of settings shall be configurable (as of now - wallpaper,
 animations, font smoothing) - if this isn't true in oVirt, I'd need work on
 it as well, because disabling all of them may reduce user experience to
 unacceptable level, resulting in feature becoming useless for many users.
 Bad conditions can be identified by the user himself (via UI), or
 automatically - to be implemented later.

 Both these stories taken together implicitly require:
 req-3. After connecting under bad conditions and having effects disabled
 and then connecting under good conditions, as a user I want my desktop
 effect settings restored to their normal (previous) values.

 Non-functional requirements:
 req-4. Robustness. Crash-proof solution: upon vdagent crash, qemu crash or
 forced guest shutdown, correct state of effect settings must be restored for
 next session.
 req-5. Simplicity. KISS, Choose simplest possible implementation.

 DEs to support:
 req-6. Main: Gnome3, KDE4, Unity; Stretch goal: XFce, LXDE

 digression {
 Or do we need to talk about Window Managers here? Or display servers?
 req-7. Solution shall be display server agnostic (X.Org, Wayland, XMir,
 Mir...).
 req-8. Solution shall be window manager/shell agnostic (Mutter/Gnome
 Shell, KWin/Plasma, Compiz/Unity, Cinnamon probably - if we even bother of
 Ubutu, why don't respect Mint... etc).

 Seems my lack of expertise in display system stacks in Linux is blocking
 me here; probably solution cannot be fully WM/shell agnostic. I'm going to
 try using DE abstraction level over WM specifics... if this makes sense.

 All this profusion of DE/WM/Display servers nowadays results in a fact
 that without some standard implemented by them, it won't be possible to
 support all of them (and EWMH isn't even near the level of required
 interop...).
 }

 I know you'd like to weaken functional requirements if higher simplicity
 is possible. Could you please try specifying these weakened requirements - I
 cannot think up them myself.


 My main reasons for weakening the functional requirements are not
 simplicity,
 but keeping things in out own hand. IOW do this without making changes
 outside
 of spice components.

 However now that this has had some time to settle, I think that it is best
 to not
 weaken the requirements, but instead do this right (which will likely turn
 out
 simpler then trying to use existing API-s in ways they were not really
 intended).


 Given the fact there are so many different display systems in Linux, it
 isn't practically possible to support all of them. On the other hand,
 supporting only few and not providing any means for developers of other
 systems to add similar support themselves doesn't make sense to me. So I
 suggest following architecture:
 vdagent --DBus-- DE-specific display effects daemon -- DE API for
 effects
 Basically vdagent (session, not system one) is to use DBus interface for
 toggling effects. The feature will be available only if the interface is
 implemented in the system.


 Agreed.


 And this implementation should be DE-specific and maybe even part of DE.
 But as we (Spice) are concerned with major DEs, sample implementation will
 be provided for Gnome3, KDE4 and Unity.


 More likely patches will provided for, as this will likely be part of
 existing code in the DE.
 Could be you already meant to say as much, just making sure, that this
 sample implementation
 will not necessarily be a standalone thing.


 Eventually I'm going to open tickets for these systems to include the new
 DBus interface implementation in their systems (like gnome-desktop-daemon).
 This should generate a good feedback upon interface itself (i.e. need to
 create an
 interface acceptable for all these DEs).

 Interface (subject to renames):

 bool SetMinimumDesktopBackground() // if already minimum, do nothing; save
 current desktop background settings; set solid background, saved color (if
 none, use default)
 bool RestoreDesktopBackground() // if nothing is saved, do nothing; if
 solid desktop background, save the color; restore desktop background
 settings

 bool SetMinimumFontSmooth() // if already minimum, do nothing; save
 current font smoothing settings; set antialiasing and hinting to the minimum

Re: [Spice-devel] Bug62033 Add support for --spice-disable-effects client option to spice-vdagent on Linux guests with Gnome3

2013-09-15 Thread Fedor Lyakhov

 is achieved as it is stateless and crashes can affect
only current session. After vdagent restart (e.g. user re-login), correct
state will be restored.

Robustness of display-effects-daemon is achieved via storing all the
settings to DE-specific settings storage (persistent, like a file). The
issues may arise only when crash/failure happens mid-transition. Correct
recovery is achieved using 'transition started' and 'transition
successfully ended' flags, IsRestored and IsMinimum, saved to the same
storage as a first and last steps of transition. For example, when
SetMinimumDesktopBackground() is called:
1)if (storage.get(MinimumDesktopBackground, IsMinimum)) // check last
transition status
  return true;
2)if (!storage.set(StashedDesktopBackground, IsRestored, false)) //
indicate start of transition
  return false;
3)if (!storage.copy(StashedDesktopBackground, DE.GetDesktopBackground()) //
save current settings
   return false;
4)if (!DE.SetDesktopBackground(storage.get(MinimumDesktopBackground)) { //
apply minimum settings
  if(DE.SetDesktopBackground(storage.get(StashedDesktopBackground))) //
restore previous state if possible
storage.set(StashedDesktopBackground, IsRestored, true);
  return false;
}
5)if(!storage.set(MinimumDesktopBackground, IsMinimum, true)) // finalize
the transition status
  return false;
retrun true;

So in case of crash in any of steps 1-5, the next call of
SetMinimumDesktopBackground() will be executed normally, and restore the
correct state.
In case of failure to set new desktop background, attempt to restore to
saved one will be made (if fails, state will be corrupted -
IsMinimum=false, IsRestored=false, so any next call of SetMinimum or
Restore will be fully executed again, restoring the state if possible).

Same for RestoreDesktopBackground():
1)if (storage.get(StashedDesktopBackground, IsRestored) // check last
transaction status; by default, IsRestored == true, to catch the case when
SetMinimum is never called.
  return true;
2)if (!storage.set(MinimumDesktopBackground, IsMinimum, false)) // indicate
start of transaction
  return false;
3)if (!storage.set(MinimumDesktopBackground, color,
DE.GetSolidDesktopBackgroundColor())) // save current background color
   return false;
4)if (!DE.SetDesktopBackground(storage.get(StashedDesktopBackground)) { //
apply desktop background settings from stash
  if (DE.SetDesktopBackground(storage.get(MinimumDesktopBackground))) //
restore previous state if possible
storage.set(MinimumDesktopBackground, IsMinimum, true);
  return false;
}
5)if(!storage.set(StashedDesktopBackground, IsRestored, true)) // finalize
the transaction status
  return false;
retrun true;

Note: I'm by no means an expert in transition failure and recovery
scenarios, I'd love your comments on this approach and welcome better
solutions (mine is just an ad-hoc one).

-- 
Best regards,
Fedor


On Tue, Aug 6, 2013 at 10:16 AM, Hans de Goede hdego...@redhat.com wrote:

 Hi,


 On 08/06/2013 12:47 AM, Fedor Lyakhov wrote:

 Hi,

 I've finally looked in vdagent for Windows and find out that it works
 differently. From a quick grasp I get following:
 Vdagent for Windows applies settings listed --disable-effects=... to
 current session via WinAPI call
 For settings not listed there, a reload is done - settings are
 restored to values from Windows registry of current active user (looks
 like API call that disables them doesn't affect register, at least
 that place).


 This windows behavior sounds good, but not something we can easily do
 ...



 So my question is - should I stick with the plan (i), or go for the
 approach as at Windows vdagent (similar to my previous idea (ii))?
 Instead of implementing '--reset-effects' option I need to store
 values of settings somewhere before disabling them and restore them
 back when connected without setting listed in --disable-effects.
 Preserving user changes is a challenge. I think it should be doable
 though - at least via implementing similar environment to Windows case
 - vdagent will need to maintain an analog of Windows register storage
 for effect settings and track user changes of their real counterparts
 of Gnome settings... Seems doable using GSettings.


 Doable yes, but what if the agent crashes, or the machine is forced off
 while agent settings are in force, will the agent detects it has crashed
 and restore the user settings from some sort of non volatile storage?

 This is likely doable (ignoring possible races wrt crash scenarios), but
 not very KISS. I would like to see a much more KISS solution if possible,
 even if that means it will be less nice.

 Regards,

 Hans

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] FOSDEM'14

2013-09-06 Thread Fedor Lyakhov

Thanks for the answers!

On Wed, Sep 4, 2013 at 1:15 PM, Christophe Fergeau cferg...@redhat.com wrote:
 Hey Fedor,

 On Tue, Sep 03, 2013 at 01:06:18PM +0400, Fedor Lyakhov wrote:
 Hello Spice developers,

 I'm planning to visit FOSDEM this year, hope to meet you in 'real
 life'. As I'm a newbie, there are few questions which bother me:

 1. Do you know whether Virtualization devroom will be hosted at this
 FOSDEM as it was in 2013? Will any Spice-related topics be discussed
 there?
 [snip]
 3. Right now I'm working on a media redirection idea for VoIP
 applications for Spice, there is a chance I'd have something to show
 and discuss with you at that time - so how should I arrange this talk?
 As part of Virtualization devroom, when it is confirmed? Or lightning
 talk? Right now FOSDEM calls for main tracks and devrooms, no info
 about other talk forms is published - guess I just need to wait? Don't
 want to miss the opportunity...

 Yup, for now you just need to wait, currently people can apply to organize
 a devroom about their topic of interest, then FOSDEM organizers will
 accept/reject these applications. Once the accepted devrooms are known,
 then the organizers of these devrooms will start looking for speakers, then
 you can apply. I'd recommend applying for both a talk in the (hypothetical)
 Virtualization devroom, and for a lightning talk (dunno how these ones are
 organized).
 I expect to be attending FOSDEM this year again.

 Hope that helps,

 Christophe


-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] FOSDEM'14

2013-09-03 Thread Fedor Lyakhov

Hello Spice developers,

I'm planning to visit FOSDEM this year, hope to meet you in 'real
life'. As I'm a newbie, there are few questions which bother me:

1. Do you know whether Virtualization devroom will be hosted at this
FOSDEM as it was in 2013? Will any Spice-related topics be discussed
there?
2. Red Hat was cornerstone sponsor of the event in 2013, but now it
isn't even listed... I cannot find any clarification in the Internet.
Any news?
3. Right now I'm working on a media redirection idea for VoIP
applications for Spice, there is a chance I'd have something to show
and discuss with you at that time - so how should I arrange this talk?
As part of Virtualization devroom, when it is confirmed? Or lightning
talk? Right now FOSDEM calls for main tracks and devrooms, no info
about other talk forms is published - guess I just need to wait? Don't
want to miss the opportunity...

-- 
Best regards,
Fedor

P.S. I continue working on Bug 62033, just came back from vacation -
will send my current ideas later this week.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Bug62033 Add support for --spice-disable-effects client option to spice-vdagent on Linux guests with Gnome3

2013-08-05 Thread Fedor Lyakhov

Hi,

I've finally looked in vdagent for Windows and find out that it works
differently. From a quick grasp I get following:
Vdagent for Windows applies settings listed --disable-effects=... to
current session via WinAPI call
For settings not listed there, a reload is done - settings are
restored to values from Windows registry of current active user (looks
like API call that disables them doesn't affect register, at least
that place).

So my question is - should I stick with the plan (i), or go for the
approach as at Windows vdagent (similar to my previous idea (ii))?
Instead of implementing '--reset-effects' option I need to store
values of settings somewhere before disabling them and restore them
back when connected without setting listed in --disable-effects.
Preserving user changes is a challenge. I think it should be doable
though - at least via implementing similar environment to Windows case
- vdagent will need to maintain an analog of Windows register storage
for effect settings and track user changes of their real counterparts
of Gnome settings... Seems doable using GSettings.

Maybe developers of vdagent for Windows can step in? We need your advise!

Also looks like oVirt use case should be of our primary concern - and
with (i) we need to update code there as well (to support new option,
--reset-effects). For (ii) no changes in oVirt are required (seems
so).

On Tue, Jul 30, 2013 at 1:57 AM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 07/29/2013 10:50 PM, Fedor Lyakhov wrote:

 snip


 I would prefer to have a VD_AGENT_DISPLAY_CONFIG_FLAG_RE_ENABLE_ALL or
 some such rather then an empty message.


 My idea was based on preserving current protocol - if it  is OK to
 introduce new message, I'm willing to do so.


 Not a new message, just a new flag inside the existing message.




 (ii) Make vdagent stateful - remember that previous connection was
 disabling some effects, and if current one isn't disabling these
 effects, reset them. No need for '--spice-reset-effects' option in
 this case. We can even remember previous states of effects and restore
 them instead of resetting them to default. This seems to be the most
 user-friendly approach, but it is harder to implement. If this
 approach is selected, I see implementation via GSettings (afaik there
 is no config for vdagent right now, correct?)



 I would not go here, --spice-disable-effects is mostly used by the
 ovirt user-portal which does this without the user knowing, so the user
 is not really aware this is happening, what if the user changes some
 settings after the agent has made its changes, then the client
 disconnecting
 will restore the wrong settings?


 Ok, I'll go with (i).
 I don't have experience with ovirt user-portal - need to look into it
 probably. One concern: I find --spice-disable-effects=font-smooth
 really annoying - font quality is extremely degraded (even without
 setting hinting to none)... As a user I wouldn't like this to happen
 behind the scenes without my opinion asked - guess I need to check
 ovirt workflow here. Is --spice-disable-effects usage in ovirt
 configurable by e.g. administrator?


 AFAIK it is enabled automatically when the user indicates he is on
 a slow (wan) connection.

 snip


 Note2: I've got 100% reproducible crash at Host-1 Guest1.1: qemu
 crashes in following scenario1:
 1. Start VM, connect with Spice client, open System
 settings-Background, select new background [or just open
 dconf-editor], close it
 2. Re-connect client
 3. Open System settings-Background-select background [or open
 dconf-editor] - VM crashes
 Scenario2:
 1. Start VM, connect with Spice client, open System
 settings-Background-select new background (do not close the window)
 2. Re-connect client - VM crashes
 It seems to be unrelated to my changes though, because it is
 reproducible even without vdagentd/vdagent running. Does anybody know
 whether it is
 already reported?


 This sounds like a new bug, can you file a bug for this please?

 OK, sure. What do I need to do to collect enough debug information
 about the crash? I've never debugged qemu/spice server...


 Just step-by-step reproduction instructions is enough for now, if
 this is reproducable we should be able to reproduce ourselves, and
 then we can get all the info we need.

 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] Bug62033 Add support for --spice-disable-effects client option to spice-vdagent on Linux guests with Gnome3

2013-07-29 Thread Fedor Lyakhov

Hans,

Thanks for such quick review! Few comments/questions below.

On Mon, Jul 29, 2013 at 10:26 AM, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 07/28/2013 10:43 PM, Fedor Lyakhov wrote:

 Hi,

 Bug62033 is a request by Gnome3 developers. They need means to detect
 that spice client runs locally so they shouldn't disable any desktop
 effects on the guest running Gnome3. On the other hand, for slow
 remote connections, they want to disable the effects.

 My solution approaches the question from another side: allow user to
 decide whether he needs the effects or not. Sure, he can configure the
 guest manually as he wants, but it isn't very convenient.


 Many thanks for working on this!



 The user interface for this task already exists in Spice GTK client,
 this is CLI option '--spice-disable-effects=wallpaper, font-smooth,
 animation, all. Right now this options works for Windows guest only.
 In next patch series I add following:
 0001. Unrelated small fix


 Added to my local repo and pushed to the official repo.


 0002. Announce capabilities of Display Config in spice-vdagentd system
 daemon, handle Display Config message in spice-vdagentd - send it to
 spice-vdagent session daemon


 Looks good.


 0003. Handle Display Config message in spice-vdagent - implementation
 uses GSettings API from GIO 2.26+; at run-time: xsettings plugin for
 gnome-settings-manager should be installed and enabled - otherwise
 font smooth won't be affected.
 Better implementation with g_settings_get_range() introspection to get
 enum nicks requires GIO 2.28+ - I need approval on this.


 2.28 is too new, 2.26 is the newest version we can require given
 the various distros we want to support. Note there is no need to do
 conditionally enable the code based on 2.26 being there and too support
 even older glib versions. 2.26 as a requirement is fine, newer is not.

Ok, I see.




 Please note patches 2, 3 are for review mostly, the feature isn't
 complete yet: user doesn't have convenient means to restore the
 effects once they're disabled. I see 2 potential solutions (better
 ideas are welcome!):

 (i) Introduce '--spice-reset-effects' option.
 We don't want to change protocol, and there is one possibility to
 explore - send Display Config with empty flags to indicate the reset
 is required.
 Right now Display Config is sent regardles of --spice-reset-effects
 and --spice-color-depth options - i.e. empty one is sent when the
 options aren't set. I want to make this empty Display Config to be
 sent only when --spice-reset-effects option is enabled (need to check
 whether this is acceptable at Windows agent). I've added handling code
 of this case to vdagent: reset all the settings we change to default
 (it is commented out for now). There are following limitations I know
 about:
 1. Inability to set color depth and reset effects in one connection
 (not that bad - reset can be done once, then re-connect with desired
 color depth; also color depth change isn't supported on Linux guests
 yet)
 2. If new flags are added to Display Config, all them need to be
 treated the same way, i.e. reset should reset them all (there can be
 only 1 reset message, flags=0).


 I would prefer to have a VD_AGENT_DISPLAY_CONFIG_FLAG_RE_ENABLE_ALL or
 some such rather then an empty message.

My idea was based on preserving current protocol - if it  is OK to
introduce new message, I'm willing to do so.


 (ii) Make vdagent stateful - remember that previous connection was
 disabling some effects, and if current one isn't disabling these
 effects, reset them. No need for '--spice-reset-effects' option in
 this case. We can even remember previous states of effects and restore
 them instead of resetting them to default. This seems to be the most
 user-friendly approach, but it is harder to implement. If this
 approach is selected, I see implementation via GSettings (afaik there
 is no config for vdagent right now, correct?)


 I would not go here, --spice-disable-effects is mostly used by the
 ovirt user-portal which does this without the user knowing, so the user
 is not really aware this is happening, what if the user changes some
 settings after the agent has made its changes, then the client disconnecting
 will restore the wrong settings?

Ok, I'll go with (i).
I don't have experience with ovirt user-portal - need to look into it
probably. One concern: I find --spice-disable-effects=font-smooth
really annoying - font quality is extremely degraded (even without
setting hinting to none)... As a user I wouldn't like this to happen
behind the scenes without my opinion asked - guess I need to check
ovirt workflow here. Is --spice-disable-effects usage in ovirt
configurable by e.g. administrator?

Just to elaborate on (ii): you're right, wrong settings will be
restored - if we accept user has only one set of settings. But if we
consider user has 2 profiles - normal and disabled (with effects
disabled), it isn't so bad:
On connect with disabled

Re: [Spice-devel] [PATCH 2/3] Handle VDAgentDisplayConfig message in vdagentd, send it to active vdagent

2013-07-29 Thread Fedor Lyakhov

Hi, Dunrong

Thanks for the review, my comments inline.

On Mon, Jul 29, 2013 at 6:58 AM, Dunrong Huang riegama...@gmail.com wrote:
 Hi,


 On Mon, Jul 29, 2013 at 4:43 AM, Fedor Lyakhov fedor.lyak...@gmail.com
 wrote:

 ---
  src/vdagentd-proto-strings.h |  1 +
  src/vdagentd-proto.h |  3 ++-
  src/vdagentd.c   | 38 ++
  3 files changed, 41 insertions(+), 1 deletion(-)

 diff --git a/src/vdagentd-proto-strings.h b/src/vdagentd-proto-strings.h
 index e76cb3b..7ea7195 100644
 --- a/src/vdagentd-proto-strings.h
 +++ b/src/vdagentd-proto-strings.h
 @@ -34,6 +34,7 @@ static const char * const vdagentd_messages[] = {
  file xfer status,
  file xfer data,
  client disconnected,
 +display config

 Adding a comma at the end will be better, so next time someone don't need to
 change this line when they add something.

OK, will add it. But won't compiler give a warning on this extra comma actually?


  };

  #endif
 diff --git a/src/vdagentd-proto.h b/src/vdagentd-proto.h
 index 25e6a36..6a09e49 100644
 --- a/src/vdagentd-proto.h
 +++ b/src/vdagentd-proto.h
 @@ -39,7 +39,8 @@ enum {
  VDAGENTD_FILE_XFER_START,
  VDAGENTD_FILE_XFER_STATUS,
  VDAGENTD_FILE_XFER_DATA,
 -VDAGENTD_CLIENT_DISCONNECTED,  /* daemon - client */
 +VDAGENTD_CLIENT_DISCONNECTED,  /* daemon - client */
 +VDAGENTD_DISPLAY_CONFIG, /* daemon - client, VDAgentDisplayConfig */
  VDAGENTD_NO_MESSAGES /* Must always be last */
  };

 diff --git a/src/vdagentd.c b/src/vdagentd.c
 index f4cea44..c9df401 100644
 --- a/src/vdagentd.c
 +++ b/src/vdagentd.c
 @@ -91,6 +91,7 @@ static void send_capabilities(struct
 vdagent_virtio_port *vport,
  caps-request = request;
  VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_MOUSE_STATE);
  VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_MONITORS_CONFIG);
 +VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_DISPLAY_CONFIG);
  VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_REPLY);
  VD_AGENT_SET_CAPABILITY(caps-caps,
 VD_AGENT_CAP_CLIPBOARD_BY_DEMAND);
  VD_AGENT_SET_CAPABILITY(caps-caps,
 VD_AGENT_CAP_CLIPBOARD_SELECTION);
 @@ -151,6 +152,38 @@ static void do_client_monitors(struct
 vdagent_virtio_port *vport, int port_nr,
(uint8_t *)reply, sizeof(reply));
  }

 +static void do_client_display(struct vdagent_virtio_port *vport, int
 port_nr,
 +VDAgentMessage *message_header, VDAgentDisplayConfig *disp)
 +{
 +VDAgentReply reply;
 +VDAgentDisplayConfig *display_config;
 +uint32_t size;
 +
 +size = sizeof(VDAgentDisplayConfig);
 +if (message_header-size != size) {
 +syslog(LOG_ERR, invalid message size for VDAgentDisplayConfig);
 +return;
 +}
 +
 +display_config = malloc(size);

 +if (!display_config) {
 +syslog(LOG_ERR, oom allocating display config);
 +size = 0;
 +}
 +memcpy(display_config, disp, size);
 +
 +/* Send display config to currently active agent */
 +if (active_session_conn)
 +udscs_write(active_session_conn, VDAGENTD_DISPLAY_CONFIG, 0, 0,
 +(uint8_t *)display_config, size);

 display_config will be leaked, why not just use the disp?

Agree. Thanks for finding this. Bad copy of code from do_client_monitors().


 +
 +/* Acknowledge reception of display config to spice server / client
 */
 +reply.type  = VD_AGENT_DISPLAY_CONFIG;
 +reply.error = VD_AGENT_SUCCESS;
 +vdagent_virtio_port_write(vport, port_nr, VD_AGENT_REPLY, 0,
 +  (uint8_t *)reply, sizeof(reply));
 +}
 +
  static void do_client_capabilities(struct vdagent_virtio_port *vport,
  VDAgentMessage *message_header,
  VDAgentAnnounceCapabilities *caps)
 @@ -330,6 +363,11 @@ int virtio_port_read_complete(
  do_client_monitors(vport, port_nr, message_header,
  (VDAgentMonitorsConfig *)data);
  break;
 +case VD_AGENT_DISPLAY_CONFIG:
 +if (message_header-size  sizeof(VDAgentDisplayConfig))
 +goto size_error;
 +do_client_display(vport, port_nr, message_header,
 +(VDAgentDisplayConfig *)data);
  case VD_AGENT_ANNOUNCE_CAPABILITIES:
  if (message_header-size  sizeof(VDAgentAnnounceCapabilities))
  goto size_error;
 --
 1.8.1.4
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel




 --
 Best Regards,

 Dunrong Huang

 Homepage: http://mathslinux.org



-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH 3/3] Handle VDAgentDisplayConfig in vdagent for Gnome3 using GSettings API from GIO 2.26+

2013-07-29 Thread Fedor Lyakhov

Yeah, probably doing autodetect is the best possible way, but as
rhel6.x is upgrading to 2.26, I'm allowed to depend on it.

On Mon, Jul 29, 2013 at 7:18 AM, Dunrong Huang riegama...@gmail.com wrote:



 On Mon, Jul 29, 2013 at 4:43 AM, Fedor Lyakhov fedor.lyak...@gmail.com
 wrote:

 ---
  Makefile.am  |  12 +++-
  configure.ac |   3 +-
  src/vdagent-display-config.c | 153
 +++
  src/vdagent-display-config.h |  27 
  src/vdagent.c|   8 +++
  5 files changed, 199 insertions(+), 4 deletions(-)
  create mode 100644 src/vdagent-display-config.c
  create mode 100644 src/vdagent-display-config.h

 diff --git a/Makefile.am b/Makefile.am
 index 74cc313..fa87420 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -4,9 +4,14 @@ NULL =
  bin_PROGRAMS = src/spice-vdagent
  sbin_PROGRAMS = src/spice-vdagentd

 -src_spice_vdagent_CFLAGS = $(X_CFLAGS) $(SPICE_CFLAGS) $(GLIB2_CFLAGS)
 -src_spice_vdagent_LDADD = $(X_LIBS) $(SPICE_LIBS) $(GLIB2_LIBS)
 -src_spice_vdagent_SOURCES = src/vdagent.c src/vdagent-x11.c
 src/vdagent-x11-randr.c src/vdagent-file-xfers.c src/udscs.c
 +src_spice_vdagent_CFLAGS = $(X_CFLAGS) $(SPICE_CFLAGS)
 $(GLIB2_CFLAGS) ${GIO2_CFLAGS}
 +src_spice_vdagent_LDADD = $(X_LIBS) $(SPICE_LIBS) $(GLIB2_LIBS)
 ${GIO2_LIBS}
 +src_spice_vdagent_SOURCES = src/vdagent.c \
 +src/vdagent-x11.c \
 +src/vdagent-x11-randr.c \
 +src/vdagent-file-xfers.c \
 +src/udscs.c \
 +src/vdagent-display-config.c

  src_spice_vdagentd_CFLAGS = $(DBUS_CFLAGS) $(LIBSYSTEMD_LOGIN_CFLAGS) \
$(PCIACCESS_CFLAGS) $(SPICE_CFLAGS) $(GLIB2_CFLAGS) $(PIE_CFLAGS)
 @@ -34,6 +39,7 @@ noinst_HEADERS = src/glib-compat.h \
   src/vdagent-virtio-port.h \
   src/vdagent-x11.h \
   src/vdagent-x11-priv.h \
 + src/vdagent-display-config.h \
   src/vdagentd-proto.h \
   src/vdagentd-proto-strings.h \
   src/vdagentd-uinput.h \
 diff --git a/configure.ac b/configure.ac
 index a1ce6c0..93ddbda 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -76,7 +76,8 @@ AC_ARG_ENABLE([static-uinput],
[enable_static_uinput=$enableval],
[enable_static_uinput=no])

 -PKG_CHECK_MODULES([GLIB2], [glib-2.0 = 2.12])
 +PKG_CHECK_MODULES([GLIB2], [glib-2.0 = 2.26])

 What if glib2 version is less than 2.26, e.g. centos6.4/rhel6.4, will
 vdagent not support them anymore? I think we should detect glib2 version in
 configure.ac, then
 decide whether to enable VDAgentDisplayConfig feature or not.

 +PKG_CHECK_MODULES([GIO2], [gio-2.0 = 2.26])
  PKG_CHECK_MODULES(X, [xfixes xrandr = 1.3 xinerama x11])
  PKG_CHECK_MODULES(SPICE, [spice-protocol = 0.12.5])


 --
 Best Regards,

 Dunrong Huang

 Homepage: http://mathslinux.org



-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH 1/3] Fix vdagent-x11.h header guard name

2013-07-28 Thread Fedor Lyakhov

---
 src/vdagent-x11.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/vdagent-x11.h b/src/vdagent-x11.h
index baa4ce8..a2a2485 100644
--- a/src/vdagent-x11.h
+++ b/src/vdagent-x11.h
@@ -19,8 +19,8 @@
 along with this program.  If not, see http://www.gnu.org/licenses/.
 */

-#ifndef __VDAGENT_H
-#define __VDAGENT_H
+#ifndef __VDAGENT_X11_H
+#define __VDAGENT_X11_H

 #include stdio.h
 #include spice/vd_agent.h
-- 
1.8.1.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] Bug62033 Add support for --spice-disable-effects client option to spice-vdagent on Linux guests with Gnome3

2013-07-28 Thread Fedor Lyakhov

Hi,

Bug62033 is a request by Gnome3 developers. They need means to detect
that spice client runs locally so they shouldn't disable any desktop
effects on the guest running Gnome3. On the other hand, for slow
remote connections, they want to disable the effects.

My solution approaches the question from another side: allow user to
decide whether he needs the effects or not. Sure, he can configure the
guest manually as he wants, but it isn't very convenient.

The user interface for this task already exists in Spice GTK client,
this is CLI option '--spice-disable-effects=wallpaper, font-smooth,
animation, all. Right now this options works for Windows guest only.
In next patch series I add following:
0001. Unrelated small fix
0002. Announce capabilities of Display Config in spice-vdagentd system
daemon, handle Display Config message in spice-vdagentd - send it to
spice-vdagent session daemon
0003. Handle Display Config message in spice-vdagent - implementation
uses GSettings API from GIO 2.26+; at run-time: xsettings plugin for
gnome-settings-manager should be installed and enabled - otherwise
font smooth won't be affected.
Better implementation with g_settings_get_range() introspection to get
enum nicks requires GIO 2.28+ - I need approval on this.

Please note patches 2, 3 are for review mostly, the feature isn't
complete yet: user doesn't have convenient means to restore the
effects once they're disabled. I see 2 potential solutions (better
ideas are welcome!):

(i) Introduce '--spice-reset-effects' option.
We don't want to change protocol, and there is one possibility to
explore - send Display Config with empty flags to indicate the reset
is required.
Right now Display Config is sent regardles of --spice-reset-effects
and --spice-color-depth options - i.e. empty one is sent when the
options aren't set. I want to make this empty Display Config to be
sent only when --spice-reset-effects option is enabled (need to check
whether this is acceptable at Windows agent). I've added handling code
of this case to vdagent: reset all the settings we change to default
(it is commented out for now). There are following limitations I know
about:
1. Inability to set color depth and reset effects in one connection
(not that bad - reset can be done once, then re-connect with desired
color depth; also color depth change isn't supported on Linux guests
yet)
2. If new flags are added to Display Config, all them need to be
treated the same way, i.e. reset should reset them all (there can be
only 1 reset message, flags=0).

(ii) Make vdagent stateful - remember that previous connection was
disabling some effects, and if current one isn't disabling these
effects, reset them. No need for '--spice-reset-effects' option in
this case. We can even remember previous states of effects and restore
them instead of resetting them to default. This seems to be the most
user-friendly approach, but it is harder to implement. If this
approach is selected, I see implementation via GSettings (afaik there
is no config for vdagent right now, correct?)

Testing
I've got few test cases for new feature:
1.1. Test --spice-disable-effects=wallpaper on default Gnome3 guest
Steps:
* Start VM
* Connect Spice client with --spice-disable-effects set
* Log in Gnome3 session
Observe:
* Desktop background is of default color (bright blue)
* In dconf-editor:
picture-options='none'
color-shading-type='solid'
primary-color=default
secondary-color=default

1.2. Test --spice-disable-effects=wallpaper on Gnome3 guest with
selected color background
Steps: Test1.1, then
* System settings - Background - Click on image - Color, select a color
Observe:
* Desktop background is of selected color (probably with texture)
* In dconf-editor:
primary-color=selected color
secondary-color=selected color
Steps:
* Re-connect
Observe:
* Desktop background is of selected color without textures
* In dconf-editor:
picture-options='none'
color-shading-type='solid'
primary-color=selected color
secondary-color=selected color
Steps:
* Restart the VM, login again
Observe: same as above.

1.3. Test --spice-disable-effects=wallpaper on Gnome3 guest with
selected wallpaper
Steps: Test1.1, then
* System Settings - Background - Click on image - select a wallpaper
Observe:
* Desktop background is of selected wallpaper
* In dconf-editor (may be specific of Gnome 3.6 at Fedora 18):
primary-color=#ff
secondary-color=#00
Steps:
* Re-connect
Observe:
* Desktop background is of default color (bright blue)
* In dconf-editor:
picture-options='none'
color-shading-type='solid'
primary-color=default
secondary-color=default
Steps:
* Restart the VM, login again
Observe: same as above.

1.4. Test without --spice-disable-effects on Gnome3 guest
Steps: Test1.1, then
* Connect without option
Observe: same as Test1.1
Steps:
* Change background to wallpaper
* Re-connect without option
Observe:
* Desktop background is selected wallpaper

2.1. Test with --spice-disable-effects=font-smooth on default Gnome3

[Spice-devel] [PATCH 2/3] Handle VDAgentDisplayConfig message in vdagentd, send it to active vdagent

2013-07-28 Thread Fedor Lyakhov

---
 src/vdagentd-proto-strings.h |  1 +
 src/vdagentd-proto.h |  3 ++-
 src/vdagentd.c   | 38 ++
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/src/vdagentd-proto-strings.h b/src/vdagentd-proto-strings.h
index e76cb3b..7ea7195 100644
--- a/src/vdagentd-proto-strings.h
+++ b/src/vdagentd-proto-strings.h
@@ -34,6 +34,7 @@ static const char * const vdagentd_messages[] = {
 file xfer status,
 file xfer data,
 client disconnected,
+display config
 };

 #endif
diff --git a/src/vdagentd-proto.h b/src/vdagentd-proto.h
index 25e6a36..6a09e49 100644
--- a/src/vdagentd-proto.h
+++ b/src/vdagentd-proto.h
@@ -39,7 +39,8 @@ enum {
 VDAGENTD_FILE_XFER_START,
 VDAGENTD_FILE_XFER_STATUS,
 VDAGENTD_FILE_XFER_DATA,
-VDAGENTD_CLIENT_DISCONNECTED,  /* daemon - client */
+VDAGENTD_CLIENT_DISCONNECTED,  /* daemon - client */
+VDAGENTD_DISPLAY_CONFIG, /* daemon - client, VDAgentDisplayConfig */
 VDAGENTD_NO_MESSAGES /* Must always be last */
 };

diff --git a/src/vdagentd.c b/src/vdagentd.c
index f4cea44..c9df401 100644
--- a/src/vdagentd.c
+++ b/src/vdagentd.c
@@ -91,6 +91,7 @@ static void send_capabilities(struct
vdagent_virtio_port *vport,
 caps-request = request;
 VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_MOUSE_STATE);
 VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_MONITORS_CONFIG);
+VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_DISPLAY_CONFIG);
 VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_REPLY);
 VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_CLIPBOARD_BY_DEMAND);
 VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_CLIPBOARD_SELECTION);
@@ -151,6 +152,38 @@ static void do_client_monitors(struct
vdagent_virtio_port *vport, int port_nr,
   (uint8_t *)reply, sizeof(reply));
 }

+static void do_client_display(struct vdagent_virtio_port *vport, int port_nr,
+VDAgentMessage *message_header, VDAgentDisplayConfig *disp)
+{
+VDAgentReply reply;
+VDAgentDisplayConfig *display_config;
+uint32_t size;
+
+size = sizeof(VDAgentDisplayConfig);
+if (message_header-size != size) {
+syslog(LOG_ERR, invalid message size for VDAgentDisplayConfig);
+return;
+}
+
+display_config = malloc(size);
+if (!display_config) {
+syslog(LOG_ERR, oom allocating display config);
+size = 0;
+}
+memcpy(display_config, disp, size);
+
+/* Send display config to currently active agent */
+if (active_session_conn)
+udscs_write(active_session_conn, VDAGENTD_DISPLAY_CONFIG, 0, 0,
+(uint8_t *)display_config, size);
+
+/* Acknowledge reception of display config to spice server / client */
+reply.type  = VD_AGENT_DISPLAY_CONFIG;
+reply.error = VD_AGENT_SUCCESS;
+vdagent_virtio_port_write(vport, port_nr, VD_AGENT_REPLY, 0,
+  (uint8_t *)reply, sizeof(reply));
+}
+
 static void do_client_capabilities(struct vdagent_virtio_port *vport,
 VDAgentMessage *message_header,
 VDAgentAnnounceCapabilities *caps)
@@ -330,6 +363,11 @@ int virtio_port_read_complete(
 do_client_monitors(vport, port_nr, message_header,
 (VDAgentMonitorsConfig *)data);
 break;
+case VD_AGENT_DISPLAY_CONFIG:
+if (message_header-size  sizeof(VDAgentDisplayConfig))
+goto size_error;
+do_client_display(vport, port_nr, message_header,
+(VDAgentDisplayConfig *)data);
 case VD_AGENT_ANNOUNCE_CAPABILITIES:
 if (message_header-size  sizeof(VDAgentAnnounceCapabilities))
 goto size_error;
-- 
1.8.1.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH 3/3] Handle VDAgentDisplayConfig in vdagent for Gnome3 using GSettings API from GIO 2.26+

2013-07-28 Thread Fedor Lyakhov

---
 Makefile.am  |  12 +++-
 configure.ac |   3 +-
 src/vdagent-display-config.c | 153 +++
 src/vdagent-display-config.h |  27 
 src/vdagent.c|   8 +++
 5 files changed, 199 insertions(+), 4 deletions(-)
 create mode 100644 src/vdagent-display-config.c
 create mode 100644 src/vdagent-display-config.h

diff --git a/Makefile.am b/Makefile.am
index 74cc313..fa87420 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4,9 +4,14 @@ NULL =
 bin_PROGRAMS = src/spice-vdagent
 sbin_PROGRAMS = src/spice-vdagentd

-src_spice_vdagent_CFLAGS = $(X_CFLAGS) $(SPICE_CFLAGS) $(GLIB2_CFLAGS)
-src_spice_vdagent_LDADD = $(X_LIBS) $(SPICE_LIBS) $(GLIB2_LIBS)
-src_spice_vdagent_SOURCES = src/vdagent.c src/vdagent-x11.c
src/vdagent-x11-randr.c src/vdagent-file-xfers.c src/udscs.c
+src_spice_vdagent_CFLAGS = $(X_CFLAGS) $(SPICE_CFLAGS)
$(GLIB2_CFLAGS) ${GIO2_CFLAGS}
+src_spice_vdagent_LDADD = $(X_LIBS) $(SPICE_LIBS) $(GLIB2_LIBS) ${GIO2_LIBS}
+src_spice_vdagent_SOURCES = src/vdagent.c \
+src/vdagent-x11.c \
+src/vdagent-x11-randr.c \
+src/vdagent-file-xfers.c \
+src/udscs.c \
+src/vdagent-display-config.c

 src_spice_vdagentd_CFLAGS = $(DBUS_CFLAGS) $(LIBSYSTEMD_LOGIN_CFLAGS) \
   $(PCIACCESS_CFLAGS) $(SPICE_CFLAGS) $(GLIB2_CFLAGS) $(PIE_CFLAGS)
@@ -34,6 +39,7 @@ noinst_HEADERS = src/glib-compat.h \
  src/vdagent-virtio-port.h \
  src/vdagent-x11.h \
  src/vdagent-x11-priv.h \
+ src/vdagent-display-config.h \
  src/vdagentd-proto.h \
  src/vdagentd-proto-strings.h \
  src/vdagentd-uinput.h \
diff --git a/configure.ac b/configure.ac
index a1ce6c0..93ddbda 100644
--- a/configure.ac
+++ b/configure.ac
@@ -76,7 +76,8 @@ AC_ARG_ENABLE([static-uinput],
   [enable_static_uinput=$enableval],
   [enable_static_uinput=no])

-PKG_CHECK_MODULES([GLIB2], [glib-2.0 = 2.12])
+PKG_CHECK_MODULES([GLIB2], [glib-2.0 = 2.26])
+PKG_CHECK_MODULES([GIO2], [gio-2.0 = 2.26])
 PKG_CHECK_MODULES(X, [xfixes xrandr = 1.3 xinerama x11])
 PKG_CHECK_MODULES(SPICE, [spice-protocol = 0.12.5])

diff --git a/src/vdagent-display-config.c b/src/vdagent-display-config.c
new file mode 100644
index 000..27e349f
--- /dev/null
+++ b/src/vdagent-display-config.c
@@ -0,0 +1,153 @@
+/*  vdagent-display-config.c vdagent display configuration code
+
+Copyright 2013 Red Hat, Inc.
+
+Authors:
+Fedor Lyakhov fedor.lyak...@gmail.com
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program.  If not, see http://www.gnu.org/licenses/.
+*/
+
+#include syslog.h
+#include gio/gio.h
+#include glib/gprintf.h
+#include spice/vd_agent.h
+
+#include vdagent-display-config.h
+
+/* TODO: Use get_settings_get_range to get correct enum nicks and values
+   This API function requires GIO 2.28 */
+
+/**
+ * Changes wallpaper settings
+ *
+ * Enable: reset related settings to default
+ *
+ * Disable:
+ * 1. Set picture-options to 'none' (to remove wallpaper)
+ * 2. Set color-shading-type to 'solid' (to remove possible gradients)
+ * This makes desktop background to be solid color, the actual color
is determined by
+ * primary-color field. It is set to #ff in case a wallpaper was
used before. This function
+ * detects such case and resets the color to default. As drawing
background isn't disabled,
+ * user can select a color via System settings.
+ */
+static void set_wallpaper(gboolean enable)
+{
+syslog(LOG_DEBUG, %s wallpaper, (enable) ? Resetting : Disabling);
+GSettings *desktop_background_settings =
g_settings_new(org.gnome.desktop.background);
+if (!desktop_background_settings) {
+syslog(LOG_ERR, No access to Gnome background settings);
+return;
+}
+
+if (enable) {
+g_settings_reset(desktop_background_settings, picture-options);
+g_settings_reset(desktop_background_settings, color-shading-type);
+g_settings_reset(desktop_background_settings, primary-color);
+g_settings_reset(desktop_background_settings, secondary-color);
+} else {
+/* value 0 corresponds to 'none' */
+if (!g_settings_set_enum(desktop_background_settings,
picture-options, 0))
+syslog(LOG_ERR

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

2013-07-25 Thread Fedor Lyakhov

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

2013-07-22 Thread Fedor Lyakhov

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

2013-07-05 Thread Fedor Lyakhov

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

2013-07-05 Thread Fedor Lyakhov

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

2013-06-24 Thread Fedor Lyakhov

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

2013-06-24 Thread Fedor Lyakhov

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

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

2013-06-22 Thread Fedor Lyakhov

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]

-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Looking for help to start learning Spice through bugfix/design

2013-06-18 Thread Fedor Lyakhov

On Tue, Jun 18, 2013 at 1:51 AM, Marc-André Lureau mlur...@redhat.comwrote:



 - Mensaje original -
  Thanks for the answer, Marc-Andr é !
 
  I'll think about these areas of enhancements you've suggested. They need
 a
  bit of clarification though - because it isn't clear for a newcomer what
 and
  how to improve :)
 
  As for OS preferences, I'm a cross-platform guy, though giving a favor to
  Linux naturally. This may be considered as a minus as I'm used to
  cross-platform frameworks which do so much low-level work and hide
  OS-specifics behind nice interfaces... I want to mention that I'm used to
  C++, so getting in mostly C-written components would be harder for me.
 What
  Spice parts are more C++-friendly actually?

 Iirc, the browser plugins (only XPI is public atm), and win-vdagent are
 C++.

 The rest is in C. The Spice client is sharing 99% of the code, while the
 platform-specific bits are handled at lower levels: gdk/cairo etc..
 The code is quite portable, thanks to libraries like GLib/GIO/Gtk+.

 But there are still platform-specific components that are not portable
 (this situation could still be improved).

  BTW, right now I've come across 2 tickets in the tracker:
  https://bugs.freedesktop.org/show_bug.cgi?id=63807( No way to filter
  devices) and https://bugs.freedesktop.org/show_bug.cgi?id=62033 ( Means
 to
  detect local-only, and related
  https://bugs.freedesktop.org/show_bug.cgi?id=62187 ,
  https://bugs.freedesktop.org/show_bug.cgi?id=62188 ). Are they relevant
 to
  work on? I need an advice on how to actually fix them (I've added some
  initial suggestions/questions in comments).

 There is a lot of improvements possible for local-only, and this is very
 relevant for desktop applications like Boxes. It is not so relevant for VDI
 in general, so it's not highest priority. It's indeed a good bug to work on.


OK, I'm going to start with this one. As I understand, following changes
are needed:
1. Add local/remote detection function to server code [based on what?
compare own src IP address and dst of the client?]
2. Add new interface at vdagent level [How vdagent can/should provide this
information to the user? what kind interface should be added? Shared
library? Adding it only for this purpose doesn't seem to make sense; but if
some other functionality is needed at the guest, it maybe a good way to do
this...]
3. Add a communication between these new parts [guess it should be done via
some virtual device; should this be a request from vdagent to server? Or
notification from server?]



 Regarding USB filtering, the bug was has a solution and was reopened.
 Imho, this is quite out of scope of Spice client libraries, so it should be
 handled at a different level, either libusb* or in the application.
 Probably in the application until a good API is found.


OK...



 
  For my future work I'm thinking about particular features useful for
  enhancing VoIP clients performance/quality within VDI. One of them is
 listed
  at the wiki, http://spice-space.org/page/Features/CodecPassthrough .
 While
  it is useful(and probably should be done at first, or alongside), I think
  there are even better possibilities - when the traffic doesn't go to VM
 at
  all. How to implement this - it is another question:) One of the most
  obvious ways is to implement something like 'remote media engine'
 capability
  for spice client, and provide an API to apps running at guest via
 extending
  vdagent. It should be easier for audio-only solution, for video-capable
  another level of integration would be needed, when this media engine
 would
  be rendering video in the app-provided window from the guest... Some
 sort of
  such 'window overlay' APIs are part of Citrix HDX and VMWare Horizon View
  suites actually.

 Do applications need to be aware of those API? Perhaps we could implement
 that? Tbh, I think a Linux solution using GStreamer elements should work.
 But adapting Windows directshow/media/whatever API to use that framework
 under the hood might be difficult. We lack of Windows experience to tell
 what is the best level or API to hook into.

 This API makes sense for VDI-only users, when the local system isn't used
for anything except remote viewer (e.g. thin client). This is a common use
case for enterprise VDI, and probably irrelevant for most non-enterprise
users... I don't know what Windows framework would be the best for this
task; afaik GStreamer is available for Windows as well. Also there is a
cross-platform free/open-source media engine - Google WebRTC, specifically
targeting VoIP communications - I think it should be considered too.


-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Looking for help to start learning Spice through bugfix/design

2013-06-17 Thread Fedor Lyakhov

Thanks for the answer, Marc-André!

I'll think about these areas of enhancements you've suggested. They need a
bit of clarification though - because it isn't clear for a newcomer what
and how to improve :)

As for OS preferences, I'm a cross-platform guy, though giving a favor to
Linux naturally. This may be considered as a minus as I'm used to
cross-platform frameworks which do so much low-level work and hide
OS-specifics behind nice interfaces... I want to mention that I'm used to
C++, so getting in mostly C-written components would be harder for me. What
Spice parts are more C++-friendly actually?

BTW, right now I've come across 2 tickets in the tracker:
https://bugs.freedesktop.org/show_bug.cgi?id=63807(No way to filter devices)and
https://bugs.freedesktop.org/show_bug.cgi?id=62033 (Means to detect
local-only, and related https://bugs.freedesktop.org/show_bug.cgi?id=62187,
https://bugs.freedesktop.org/show_bug.cgi?id=62188). Are they relevant to
work on? I need an advice on how to actually fix them (I've added some
initial suggestions/questions in comments).

For my future work I'm thinking about particular features useful for
enhancing VoIP clients performance/quality within VDI. One of them is
listed at the wiki, http://spice-space.org/page/Features/CodecPassthrough.
While it is useful(and probably should be done at first, or alongside), I
think there are even better possibilities - when the traffic doesn't go to
VM at all. How to implement this - it is another question:) One of the most
obvious ways is to implement something like 'remote media engine'
capability for spice client, and provide an API to apps running at guest
via extending vdagent. It should be easier for audio-only solution, for
video-capable another level of integration would be needed, when this media
engine would be rendering video in the app-provided window from the
guest... Some sort of such 'window overlay' APIs are part of Citrix HDX and
VMWare Horizon View suites actually.

Suggested simple scheme above requires re-write of media subsystems of
VoIP/media consumer applications at the guests - not very feasible... Next
step would be introducing something to support the same for unchanged or
only very slightly changed applications. I have some ideas on this topic as
well, though looking hard/unrealistic/unclear (specific virtual network for
targeted applications, where network traffic is heuristically analyzed and
audio/video isn't transferred but used to control clients' media; signaling
traffic pass-through).

All this seems to be very exciting topic to me, with many different
approaches and directions actually possible. I'd like to hear your opinions
about it, discuss it.

-- 
Best regards,
Fedor

On Mon, Jun 17, 2013 at 1:32 PM, Marc-André Lureau mlur...@redhat.comwrote:

 Hi!

 - Mensaje original -
  Hello Spice developers,
 
  First of all, let me thank you for your great software! I'm using it
 daily
  since recently and I'm very excited about it. Certainly the best in class
  for Linux guests (at minimum)!
 
  I want to contribute to the Spice project and currently I'm seeking for a
  starting point aside of reading manuals. I'm not quite tough a developer
 to
  get in and confirm my seriousness with a set of patches or a new
 feature, so
  I hope for your guidance.

 Welcome!

 [...]
  As of now I'm looking for some fairly easy work for a Spice newcomer -
 to get
  started and learn some basics of Spice.

 Spice is composed of many components, and support several guest OS and
 several client OS. Do you have a particular feature or OS in mind? There is
 a lot improvements possible on server code itself to make it more readable
 and maintainable. The integration with qemu could be improved, perhaps
 using a separate main loop, or a different process to increase stability
 and security. It could be worthwhile adding on-disk cache to the client.
 This is not so easy but probably a good way to learn more about Spice :)
 Another interesting way to learn about Spice is to improve the HTML5
 client, or the experimental Weston backend.

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] Looking for help to start learning Spice through bugfix/design

2013-06-13 Thread Fedor Lyakhov

Hello Spice developers,

First of all, let me thank you for your great software! I'm using it daily
since recently and I'm very excited about it. Certainly the best in class
for Linux guests (at minimum)!

I want to contribute to the Spice project and currently I'm seeking for a
starting point aside of reading manuals. I'm not quite tough a developer to
get in and confirm my seriousness with a set of patches or a new feature,
so I hope for your guidance.

A few words about me and my interests. I don't have any experience in
contributing to free/opensource project yet, though I'm using GNU/Linux
since early 200x and watching related news etc. Hope I can finally
contribute back to this wonderful ecosystem...

I have about 10+ years exp in C++, but I'm not a 'senior' developer or guru
(yet). At the moment I'm a leader of a dev team responsible for a Unified
Communications for Virtual Desktop Infrastructure product from one
well-known enterprise vendor (if interested, watch this fairly good 3 min
video describing what it is, http://www.youtube.com/watch?v=ZsvUDF827R8;
the name is in video, not providing it here to not advertise it - you can
google up some more info, not so much as this is enterprise product without
any free/trial version unfortunately). Basically it is cross-platform
(thanks to QtBoost) SIP phone with proprietary SIP stack and extensions,
and with Google WebRTC media (slightly tunedfixed for this role).
Supported VDI - VMWare (with its View Horizon) and Citrix (XenDesktop).
This is fairly new project and, unfortunately, Spice isn't included in the
supported list (M$ RemoteFX as well) - probably due to enterprise nature
and customers/sales chain specifics (banks, govmnt etc).

I have a few points of interest in Spice growing from my professional
interest in VoIP solutions for VDI (virtual desktop infrastructure; not
referring to virtual device interface in this mail). I'm thinking about how
to improve VDI components to allow VoIP application working with best
possible quality without much specific work from its developers - unlike
our approach of additional VoIP client (and this can be applied to any
media-consuming application actually). I'll share my ideas in a separate
mail later, maybe someone has similar thoughts or even works on this in
Spice project.

As of now I'm looking for some fairly easy work for a Spice newcomer - to
get started and learn some basics of Spice.

-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] client viewer - not able to connect

2013-05-07 Thread Fedor Lyakhov

Hi,

I've been struggling with the very same problem today (host - latest CentOS
6.4, guest - Fedora 18). Certainly there is a strong need for user guide
covering such basics...
I've solved it with 2 steps:
1. At virt-manager remove Graphics device and add new Spice graphics,
select 'Listen on all public interfaces' - by default it listens at
127.0.0.1 only! After that you should be able to connect to VM at the host
via 'spicec -h public IP address of host -p 5900' (first used port by
default, if this is the first machine running at the host...)

2. Add iptables rule to allow connection to this port (not sure what
protocol to use, udp or tcp or both? I've added all). Need to make sure
this new rule is above default REJECT rule (this note applicable to CentOS
at least).

-Fedor



On Tue, May 7, 2013 at 6:49 PM, Marian Krcmarik mkrcm...@redhat.com wrote:



 - Original Message -
  From: Frank Fraijo frank.fra...@state.or.us
  To: spice-devel@lists.freedesktop.org
  Sent: Wednesday, April 24, 2013 6:24:09 PM
  Subject: [Spice-devel] client viewer - not able to connect
 
  I have RH Desktop Virt 6.4 running on a physical server.  I'm able to get
  spice running on it with no issue.  At my local windowsXP work station,
 I've
  installed the latest Virtviewer ( spice windows download ).
 
  I'm not able to connect.   I've tried several login attempts with no joy:
 
   spice://admin@IP:PORT
  spice://IP:PORT  ( 5900,5901,5902..etc)
 spice://IP
 Difficult to say, but spice://IP:PORT should be a correct format where IP
 is the IP of HOST (where the qemu-kvm instance is running) and PORT is the
 port where spice-server listens which must be accessible (firewall?), If
 you telnet the port, does it reply?
 
  Nothing works.  Any guidance is greatly appreciated.
 
  thanks
 
 
 
  Frank Fraijo, DBA/SA, Sybase Professional, USMC Res. MSgt
  Oregon Liquor Control Commission
  9079 SE McLoughlin BLVD
  Milwaukie, 0R 97222
  Tel: (503) 872-5046
 
 
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel




-- 
Best regards,
Fedor
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

41 matches

Mail list logo