Re: [Spice-devel] [spice-gtk] widget: avoid gdk_seat_grab/ungrab() API temporarily

[Pavel Grunt]

The intention of those commits was to be ready for new things (wayland,
gtk4... wait, actually gtk3). That side effect was not desired...
I'm not sure whether is better to revert it completely and go back to gtk2
api.

Ack,
Pavel

If there is a bug/regression in gtk+, it'd be good to have reference to it
in the commit ;)

Maybe it's easier for you to come up with a simple gtk reproducer since you
analyzed the issue properly.
If the comment is still valid, pity that the gtk+ bug did not get any
reaction (in the bug report).


2018-05-22 8:42 GMT+02:00 Victor Toso :

> From: Victor Toso 
>
> We are using those APIs to avoid the deprecated ones from GTK but
> unexpected events are handled different by them introducing a
> regression that is easy to reproduce when Spice client holds the
> focus and user locks the screen.
>
> We need to better handle the situation where gdk_seat_grab() fails,
> specifically with GDK_GRAB_ALREADY_GRABBED which is the situation
> for the bugs mentioned below. The grab does not fail with older API
> in the same situation.
>
> Note that gdk_seat_grab() returning GDK_GRAB_ALREADY_GRABBED is due
> the locking screen holding the keyboard device which also means that
> remote-viewer isn't visible/show but gdk_window_is_visible() returns
> true till gdk_seat_grab() is called. The failure in gtk+ function
> call sets the visibility to false and the next gdk_seat_grab() call
> does return GDK_GRAB_NOT_VIEWABLE and gdk_window_is_visible() false
> as it should.
>
> So, gtk+ needs to fix some behavior and spice-gtk improve error
> handle but till then, let's avoid the regression for users.
>
> This patch basically avoid the changes introduced by following
> commits:
>
>  | commit 283f41cd289084689fbdf1151da55aa451ba343c
>  | gtk: Use gdk_window_get_device_position
>  |
>  | commit a718aec66658ba6bb3bb45a9af81a3aa2a652d18
>  | widget: Use deprecated function to ungrab device
>  |
>  | commit 3f4c5bcc88ca5db125ec48ebf696cb23a8e6339a
>  | gtk: Avoid deprecated gdk_keyboard_grab
>  |
>  | commit ef7a6fa1798c8e53c0b77330b398a78181cf90e5
>  | gtk: Avoid deprecated gdk_pointer_grab
>
> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1485968
> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1571422
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-widget.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/spice-widget.c b/src/spice-widget.c
> index 72f5334..ec6a197 100644
> --- a/src/spice-widget.c
> +++ b/src/spice-widget.c
> @@ -811,7 +811,7 @@ SpiceGrabSequence 
> *spice_display_get_grab_keys(SpiceDisplay
> *display)
>  return d->grabseq;
>  }
>
> -#if GTK_CHECK_VERSION(3, 20, 0)
> +#if 0 && GTK_CHECK_VERSION(3, 20, 0)
>  static GdkSeat *spice_display_get_default_seat(SpiceDisplay *display)
>  {
>  GdkWindow *window = gtk_widget_get_window(GTK_WIDGET(display));
> @@ -867,7 +867,7 @@ static void try_keyboard_grab(SpiceDisplay *display)
>  GetModuleHandle(NULL), 0);
>  g_warn_if_fail(d->keyboard_hook != NULL);
>  #endif
> -#if GTK_CHECK_VERSION(3, 20, 0)
> +#if 0 && GTK_CHECK_VERSION(3, 20, 0)
>  status = gdk_seat_grab(spice_display_get_default_seat(display),
> gtk_widget_get_window(widget),
> GDK_SEAT_CAPABILITY_KEYBOARD,
> @@ -892,7 +892,7 @@ static void try_keyboard_grab(SpiceDisplay *display)
>  static void ungrab_keyboard(G_GNUC_UNUSED SpiceDisplay *display)
>  {
>  G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> -#if GTK_CHECK_VERSION(3, 20, 0)
> +#if 0 && GTK_CHECK_VERSION(3, 20, 0)
>  /* we want to ungrab just the keyboard - it is not possible using
> gdk_seat_ungrab().
> See also https://bugzilla.gnome.org/show_bug.cgi?id=780133 */
>  GdkDevice *keyboard = gdk_seat_get_keyboard(spice_
> display_get_default_seat(display));
> @@ -1042,7 +1042,7 @@ static gboolean do_pointer_grab(SpiceDisplay
> *display)
>
>  try_keyboard_grab(display);
>  G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> -#if GTK_CHECK_VERSION(3, 20, 0)
> +#if 0 && GTK_CHECK_VERSION(3, 20, 0)
>  status = gdk_seat_grab(spice_display_get_default_seat(display),
> window,
> GDK_SEAT_CAPABILITY_ALL_POINTING,
> @@ -1174,7 +1174,7 @@ static void mouse_wrap(SpiceDisplay *display,
> GdkEventMotion *motion)
>  static void ungrab_pointer(G_GNUC_UNUSED SpiceDisplay *display)
>  {
>  G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> -#if GTK_CHECK_VERSION(3, 20, 0)
> +#if 0 && GTK_CHECK_VERSION(3, 20, 0)
>  /* we want to ungrab just the pointer - it is not possible using
> gdk_seat_ungrab().
> See also https://bugzilla.gnome.org/show_bug.cgi?id=780133 */
>  GdkDevice *pointer = gdk_seat_get_pointer(spice_
> display_get_default_seat(display));
> @@ -2431,7 +2431,7 @@ static GdkDevice 
> *spice_gdk_window_get_pointing_device(GdkWindow
> *window)

Re: [Spice-devel] [spice-space-pages] Don't use absolute URLs for local resources

[Pavel Grunt]

Hi,
does it work well with CI? IIRC there's a linter checking for the validity
of links.

Pavel

Dne po 14. 5. 2018 17:18 uživatel Christophe Fergeau 
napsal:

> When referencing content hosted on spice-space.org, no need to use the
> full URL in our HTML pages
> (ie use /download/ instead of https://www.spice-space.org/download/).
> ---
>  download.rst | 32 
>  usbredir.rst | 32 
>  2 files changed, 32 insertions(+), 32 deletions(-)
>
> diff --git a/download.rst b/download.rst
> index ba95313..40352b4 100644
> --- a/download.rst
> +++ b/download.rst
> @@ -9,9 +9,9 @@ Download
>  .. _virt-viewer:
>  .. _virt-manager download page: http://virt-manager.org/download
>  .. _QEMU: http://www.qemu.org/
> -.. _spice-gtk-0.34.tar.bz2:
> https://www.spice-space.org/download/gtk/spice-gtk-0.34.tar.bz2
> -.. _UsbDk_1.0.19_x64.msi:
> https://www.spice-space.org/download/windows/usbdk/UsbDk_1.0.19_x64.msi
> -.. _UsbDk_1.0.19_x86.msi:
> https://www.spice-space.org/download/windows/usbdk/UsbDk_1.0.19_x86.msi
> +.. _spice-gtk-0.34.tar.bz2: /download/gtk/spice-gtk-0.34.tar.bz2
> +.. _UsbDk_1.0.19_x64.msi: /download/windows/usbdk/UsbDk_1.0.19_x64.msi
> +.. _UsbDk_1.0.19_x86.msi: /download/windows/usbdk/UsbDk_1.0.19_x86.msi
>  .. _aSPICE:
>  .. _aSPICE from play.google.com:
> https://play.google.com/store/apps/details?id=com.iiordanov.freeaSPICE
>  .. _Web client: spice-html5.html
> @@ -20,19 +20,19 @@ Download
>  .. _flexVDI: https://flexvdi.com
>  .. _flexVDI Client at App Store:
> https://itunes.apple.com/us/app/flexvdi-client/id1051361263?mt=8
>  .. _flexVDI Client at Play Store:
> https://play.google.com/store/apps/details?id=com.flexvdi.androidlauncher
> -.. _spice-vdagent-0.17.0.tar.bz2:
> https://www.spice-space.org/download/releases/spice-vdagent-0.17.0.tar.bz2
> +.. _spice-vdagent-0.17.0.tar.bz2:
> /download/releases/spice-vdagent-0.17.0.tar.bz2
>  .. _xf86-video-qxl:
>  .. _xf86-video-qxl-0.1.5.tar.bz2:
> http://xorg.freedesktop.org/releases/individual/driver/xf86-video-qxl-0.1.5.tar.bz2
> -.. _spice-guest-tools:
> https://www.spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-latest.exe
> -.. _Windows QXL driver:
> https://www.spice-space.org/download/windows/qxl/qxl-0.1-24/
> -.. _Windows QXL-WDDM-DOD driver:
> https://www.spice-space.org/download/windows/qxl-wddm-dod/qxl-wddm-dod-0.18/
> +.. _spice-guest-tools:
> /download/windows/spice-guest-tools/spice-guest-tools-latest.exe
> +.. _Windows QXL driver: /download/windows/qxl/qxl-0.1-24/
> +.. _Windows QXL-WDDM-DOD driver:
> /download/windows/qxl-wddm-dod/qxl-wddm-dod-0.18/
>  .. _Changelog:
> https://gitlab.freedesktop.org/spice/win32/qxl-wddm-dod/raw/master/Changelog
> -.. _Windows SPICE agent:
> https://www.spice-space.org/download/windows/vdagent/vdagent-win-0.8.0
> -.. _Spice WebDAV daemon:
> https://www.spice-space.org/download/windows/spice-webdavd/
> -.. _spice-0.12.8.tar.bz2:
> https://www.spice-space.org/download/releases/spice-0.12.8.tar.bz2
> -.. _spice-0.14.0.tar.bz2:
> https://www.spice-space.org/download/releases/spice-0.14.0.tar.bz2
> -.. _spice-protocol-0.12.13.tar.bz2:
> https://www.spice-space.org/download/releases/spice-protocol-0.12.13.tar.bz2
> -.. _usbredir-0.7.1.tar.bz2:
> http://www.spice-space.org/download/usbredir/usbredir-0.7.1.tar.bz2
> +.. _Windows SPICE agent: /download/windows/vdagent/vdagent-win-0.8.0
> +.. _Spice WebDAV daemon: /download/windows/spice-webdavd/
> +.. _spice-0.12.8.tar.bz2: /download/releases/spice-0.12.8.tar.bz2
> +.. _spice-0.14.0.tar.bz2: /download/releases/spice-0.14.0.tar.bz2
> +.. _spice-protocol-0.12.13.tar.bz2:
> /download/releases/spice-protocol-0.12.13.tar.bz2
> +.. _usbredir-0.7.1.tar.bz2: /download/usbredir/usbredir-0.7.1.tar.bz2
>  .. _Xspice: xspice.html
>  .. _README.xspice:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/tree/README.xspice
>  .. _x11spice:
> https://gitlab.com/spice/x11spice/repository/archive.tar.bz2?ref=v1.1
> @@ -56,7 +56,7 @@ The recommended client application is virt-viewer_.
>  Windows installers
>  ^^
>  - virt-viewer Windows installer - can be downloaded from `virt-manager
> download page`_
> -- UsbDk - A Windows filter driver developed for Spice USB redirection
> (windows client side) - `UsbDk_1.0.19_x64.msi`_, `UsbDk_1.0.19_x86.msi`_,
> (`source code <
> https://www.spice-space.org/download/windows/usbdk/spice-usbdk-win-1.0-19-sources.zip
> >`_)
> +- UsbDk - A Windows filter driver developed for Spice USB redirection
> (windows client side) - `UsbDk_1.0.19_x64.msi`_, `UsbDk_1.0.19_x86.msi`_,
> (`source code
> `_)
>
>- https://gitlab.freedesktop.org/spice/win32/usbdk
>
> @@ -163,9 +163,9 @@ Streaming agent (experimental)
>
>  Older releases
>  ++
> -Older source releases can be found here__. Old versions of spice-gtk can
> be found `here `_.
> +Older source releases can be found here__. 

Re: [Spice-devel] spice-vdagent screen resolution auto-adjustment fail

[Pavel Grunt]

Hi, I agree with you about it. User should not be forced to one DE.

Spice server now does not forward messages from spice client to spice
server in case it detects QXL in the guest. I 'm not sure but changing this
line
https://gitlab.com/spice/spice/blob/master/server/agent-msg-filter.c#L107
to return "OK" may have an effect on your DE.

Best regards,
Pavel

Dne 1. 2. 2018 6:09 dop. napsal uživatel "Dmitriy Kormulev" <
kormu...@itsirius.su>:

> Hi,
>
> Thank you for the reply.
> Yeah, I read about Gnome 3 and of course tried it but I just don't like
> the idea of being fasten to a particular desktop environment that is why
> i tried to look into changing program code. It seems that it can be more
> flexible solution...
> Just noticed that i seemed to implement it. I will check how it works with
> several monitors and then write about the result.
>
> Best regards
> Dmitry
>
> --
> *От: *"Pavel Grunt" <pavelgr...@gmail.com>
> *Кому: *"Victor Toso" <victort...@redhat.com>
> *Копия: *"Dmitriy Kormulev" <kormu...@itsirius.su>, "spice-devel" <
> spice-devel@lists.freedesktop.org>
> *Отправленные: *Четверг, 1 Февраль 2018 г 2:15:42
> *Тема: *Re: [Spice-devel] spice-vdagent screen resolution auto-adjustment
> fail
>
> Hello,
>
> I guess in this case the problem is in the guest's desktop environment.
> The auto-adjustment is implemented in Gnome and the recent KDE.
>
> Dmitriy, you can change the environment of your centos 7 guest from Mate
> to Gnome to check out if it works.
>
> Pavel
>
> Dne 31. 1. 2018 5:37 odp. napsal uživatel "Victor Toso" <
> victort...@redhat.com>:
>
> On Sun, Jan 28, 2018 at 06:50:27PM +0400, Dmitriy Kormulev wrote:
> > Hi,
> > Just wonder if there any possible changes to make in
> > spice-vdagent(d) source code ( I am using spice-vdagent 0.14.0
> > ) to make client's screen auto-resizable. I tried but failed.
> >
> > Would be extremely grateful for any clue.
> >
> > The screen resolution is adjusted only once during  - for the
> > first time WM starts, the resolution is not adjusted during the
> > session ( does not follow changes in spice-client window size
> > ).
> >
> > Steps to reproduce:
> > 1. connect to a freshly started guest
> > 2. guest adjust resolution while on login screen
> > 3. log in
> >
> > Expected result:
> > resolution matches window size
> >
> > I am using Mate 1.16 and Centos 7 on VM and Kubuntu 17.10 as a host.
>
> Are you using qxl? Depending on your guest configuration, the
> agent might not play a role in adjusting the resolution anymore.
>
> For more details, you can check the implementation notes at
> https://www.spice-space.org/multiple-monitors.html
>
> Cheers,
> toso
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice-vdagent screen resolution auto-adjustment fail

[Pavel Grunt]

Hello,

I guess in this case the problem is in the guest's desktop environment. The
auto-adjustment is implemented in Gnome and the recent KDE.

Dmitriy, you can change the environment of your centos 7 guest from Mate to
Gnome to check out if it works.

Pavel

Dne 31. 1. 2018 5:37 odp. napsal uživatel "Victor Toso" <
victort...@redhat.com>:

On Sun, Jan 28, 2018 at 06:50:27PM +0400, Dmitriy Kormulev wrote:
> Hi,
> Just wonder if there any possible changes to make in
> spice-vdagent(d) source code ( I am using spice-vdagent 0.14.0
> ) to make client's screen auto-resizable. I tried but failed.
>
> Would be extremely grateful for any clue.
>
> The screen resolution is adjusted only once during  - for the
> first time WM starts, the resolution is not adjusted during the
> session ( does not follow changes in spice-client window size
> ).
>
> Steps to reproduce:
> 1. connect to a freshly started guest
> 2. guest adjust resolution while on login screen
> 3. log in
>
> Expected result:
> resolution matches window size
>
> I am using Mate 1.16 and Centos 7 on VM and Kubuntu 17.10 as a host.

Are you using qxl? Depending on your guest configuration, the
agent might not play a role in adjusting the resolution anymore.

For more details, you can check the implementation notes at
https://www.spice-space.org/multiple-monitors.html

Cheers,
toso

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

Re: [Spice-devel] [PATCH spice-server] red-parse-qxl: Copy correctly brush position

[Pavel Grunt]

2018-01-13 11:08 GMT+01:00 Frediano Ziglio :

> This issue caused the glitches using the rectangular selection
> tool in PaintShop 6.
>
> The line was removed accidentally by "red_parse_qxl: fix throwing
> away drawables that have masks" (812b65984d286414170c6243bd3323b73a405ec3)
>

quite old


> Signed-off-by: Frediano Ziglio 
>
Ack,
Pavel

> ---
>  server/red-parse-qxl.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/server/red-parse-qxl.c b/server/red-parse-qxl.c
> index b4325b048..69748698a 100644
> --- a/server/red-parse-qxl.c
> +++ b/server/red-parse-qxl.c
> @@ -616,6 +616,7 @@ static void red_get_brush_ptr(RedMemSlotInfo *slots,
> int group_id,
>  break;
>  case SPICE_BRUSH_TYPE_PATTERN:
>  red->u.pattern.pat = red_get_image(slots, group_id,
> qxl->u.pattern.pat, flags, false);
> +red_get_point_ptr(>u.pattern.pos, >u.pattern.pos);
>  break;
>  }
>  }
> --
> 2.14.3
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk v2] build-sys: stop installing spicy & spicy-stats

[Pavel Grunt]

2017-08-10 12:27 GMT+02:00 :

> From: Marc-André Lureau 
>
> spicy is only a test UI. A proper end-user UI is provided by
> virt-viewer, vinagre or Boxes for example.
>
> spicy-stats is meant for simple measurements and tweaking during
> development, I never heard of any user. And I can't think of a good
> reason a user would want it.
>
> Signed-off-by: Marc-André Lureau 
>

Ack,
Pavel

P.S.: What be good to stop shipping them in the rhel/fedora spice-gtk-tools
packages soon


> ---
>  tools/Makefile.am | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tools/Makefile.am b/tools/Makefile.am
> index 7c2d90e..5bce252 100644
> --- a/tools/Makefile.am
> +++ b/tools/Makefile.am
> @@ -1,4 +1,5 @@
> -bin_PROGRAMS = spicy-stats spicy-screenshot
> +bin_PROGRAMS = spicy-screenshot
> +noinst_PROGRAMS = spicy-stats
>
>  TOOLS_CPPFLAGS =   \
> -DSPICE_COMPILATION \
> @@ -13,7 +14,7 @@ TOOLS_CPPFLAGS =  \
> $(NULL)
>
>  if WITH_GTK
> -bin_PROGRAMS += spicy
> +noinst_PROGRAMS += spicy
>  TOOLS_CPPFLAGS += $(GTK_CFLAGS)
>  endif
>
> --
> 2.14.0.1.geff633fa0
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] build-sys: stop installing spicy

[Pavel Grunt]

2017-08-10 12:22 GMT+02:00 Marc-André Lureau :

> Hi
>
> - Original Message -
> > Hi,
> >
> > do you want to keep installing spicy-screenshot and spicy-stats? They are
> > also tools just for testing.
>
> spicy-stats indeed.
>
> spicy-screenshot may be used legitimately in scripts though.
>

for instance it is used in spice-server's automated tests


> I'll update the patch
>
> >
> > Pavel
> >
> > 2017-08-10 11:37 GMT+02:00 Marc-André Lureau <
> marcandre.lur...@redhat.com>:
> >
> > > Hi
> > >
> > > - Original Message -
> > > > Hi,
> > > >
> > > > On Wed, Aug 09, 2017 at 10:48:58PM +0200,
> marcandre.lur...@redhat.com
> > > wrote:
> > > > > From: Marc-André Lureau 
> > > > >
> > > > > spicy is only a test UI. A proper end-user UI is provided by
> > > > > virt-viewer, vinagre or Boxes for example.
> > > > >
> > > > > Signed-off-by: Marc-André Lureau 
> > > >
> > > > I don't see why a testing tool should not be installed...
> > >
> > > Because users expect it to be a fully-featured client, which is not.
> Imho,
> > > as a testing tool, it's fine to have it only in the build directory.
> You
> > > may install it manually, but it shouldn't be there by default.
> > >
> > > We may want to have --enable-installed-tests, that would be a different
> > > patch though
> > > https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
> > >
> > > >
> > > > > ---
> > > > >  tools/Makefile.am | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/tools/Makefile.am b/tools/Makefile.am
> > > > > index 7c2d90e..5b7c4de 100644
> > > > > --- a/tools/Makefile.am
> > > > > +++ b/tools/Makefile.am
> > > > > @@ -13,7 +13,7 @@ TOOLS_CPPFLAGS =  \
> > > > > $(NULL)
> > > > >
> > > > >  if WITH_GTK
> > > > > -bin_PROGRAMS += spicy
> > > > > +noinst_PROGRAMS = spicy
> > > > >  TOOLS_CPPFLAGS += $(GTK_CFLAGS)
> > > > >  endif
> > > > >
> > > > > --
> > > > > 2.14.0.1.geff633fa0
> > > > >
> > > > > ___
> > > > > Spice-devel mailing list
> > > > > Spice-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > >
> > > ___
> > > Spice-devel mailing list
> > > Spice-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> > >
> >
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] build-sys: stop installing spicy

[Pavel Grunt]

Hi,

do you want to keep installing spicy-screenshot and spicy-stats? They are
also tools just for testing.

Pavel

2017-08-10 11:37 GMT+02:00 Marc-André Lureau :

> Hi
>
> - Original Message -
> > Hi,
> >
> > On Wed, Aug 09, 2017 at 10:48:58PM +0200, marcandre.lur...@redhat.com
> wrote:
> > > From: Marc-André Lureau 
> > >
> > > spicy is only a test UI. A proper end-user UI is provided by
> > > virt-viewer, vinagre or Boxes for example.
> > >
> > > Signed-off-by: Marc-André Lureau 
> >
> > I don't see why a testing tool should not be installed...
>
> Because users expect it to be a fully-featured client, which is not. Imho,
> as a testing tool, it's fine to have it only in the build directory. You
> may install it manually, but it shouldn't be there by default.
>
> We may want to have --enable-installed-tests, that would be a different
> patch though
> https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
>
> >
> > > ---
> > >  tools/Makefile.am | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tools/Makefile.am b/tools/Makefile.am
> > > index 7c2d90e..5b7c4de 100644
> > > --- a/tools/Makefile.am
> > > +++ b/tools/Makefile.am
> > > @@ -13,7 +13,7 @@ TOOLS_CPPFLAGS =  \
> > > $(NULL)
> > >
> > >  if WITH_GTK
> > > -bin_PROGRAMS += spicy
> > > +noinst_PROGRAMS = spicy
> > >  TOOLS_CPPFLAGS += $(GTK_CFLAGS)
> > >  endif
> > >
> > > --
> > > 2.14.0.1.geff633fa0
> > >
> > > ___
> > > Spice-devel mailing list
> > > Spice-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> >
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] widget: Ignore deprecation warnings for gdk_event_get_scancode

[Pavel Grunt]

It is available since Gtk+ 3.22
---
 src/spice-widget.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/spice-widget.c b/src/spice-widget.c
index d5ebd9d..fb94e94 100644
--- a/src/spice-widget.c
+++ b/src/spice-widget.c
@@ -1577,6 +1577,7 @@ static gboolean key_event(GtkWidget *widget, GdkEventKey 
*key)
  * This API is available from 3.22 or if backported.
  */
 #if HAVE_GDK_EVENT_GET_SCANCODE
+G_GNUC_BEGIN_IGNORE_DEPRECATIONS
 native_scancode = gdk_event_get_scancode((GdkEvent *) key);
 if (native_scancode) {
 scancode = native_scancode & 0x1ff;
@@ -1584,6 +1585,7 @@ static gboolean key_event(GtkWidget *widget, GdkEventKey 
*key)
 if (scancode == (0x100|DIK_NUMLOCK) || scancode == (0x100|DIK_RSHIFT))
 scancode &= 0xff;
 }
+G_GNUC_END_IGNORE_DEPRECATIONS
 #else
 native_scancode = 0;
 #endif
-- 
2.13.3

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

Re: [Spice-devel] cast-align warning when building spice-gtk on Arm

[Pavel Grunt]

Hi Armin,

I also build with --disable-werror on arm (raspberry & orange pi), it works
fine.

The warnings in your log comes from gstreamer's and glib's headers. The
issue is probably there :) Alternatively try ./configure --disable-gstvideo

Pavel

2017-08-03 14:52 GMT+02:00 Victor Toso :

> Hi,
>
> On Thu, Aug 03, 2017 at 04:01:00PM +0430, Armin Ranjbar wrote:
> > Hello list!
> >
> > attached is log of error i receive when trying to build on Arm, so i had
> to
> > use --disable-werror to be able to build spice-gtk, any ideas if they
> > should be ignored?
> > ---
> > Armin ranjbar
>
> Feel free to copy-paste the debug in the email itself.
>
> I think we should fix those warnings ;)
> Patches welcome!
>
> Cheers,
> toso
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [vdagent-win PATCH v2] Do not use dash in rpm version

[Pavel Grunt]

On Thu, 2017-07-27 at 10:15 +0100, Frediano Ziglio wrote:
> RPM does not allow dash in version string.
> Replace dashes with underscores.
> This make easier to run "make dist" followed by rpmbuild.
> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>

Acked-by: Pavel Grunt <pavelgr...@gmail.com>
> ---
>  configure.ac| 2 ++
>  mingw-spice-vdagent.spec.in | 6 +++---
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> Changes since v1:
> - just replace dashed with underscores in order to
>   retain dirty version instead of stripping it off.
> 
> diff --git a/configure.ac b/configure.ac
> index bb33075..fbcb8da 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,6 +38,8 @@ AC_DEFINE_UNQUOTED([RC_PRODUCTVERSION_STR],
> "$RC_PRODUCTVERSION", [Resource prod
>  AC_DEFINE_UNQUOTED([RC_PRODUCTVERSION], [$RC_PRODUCTVERSION], [Resource
> product version])
>  BUILD_YEAR=`date +%Y`
>  AC_DEFINE_UNQUOTED([BUILD_YEAR], "$BUILD_YEAR", [Build year])
> +RPM_VERSION=`echo $PACKAGE_VERSION | sed 's,-,_,g'`
> +AC_SUBST([RPM_VERSION])
>  
>  # Check for programs
>  AC_PROG_CC
> diff --git a/mingw-spice-vdagent.spec.in b/mingw-spice-vdagent.spec.in
> index d25ea31..d129a7b 100644
> --- a/mingw-spice-vdagent.spec.in
> +++ b/mingw-spice-vdagent.spec.in
> @@ -16,13 +16,13 @@
>  %endif
>  
>  Name:   mingw-spice-vdagent
> -Version:@VERSION@
> +Version:@RPM_VERSION@
>  Release:1%{?dist}%{?extra_release}
>  Summary:MinGW Windows SPICE guest agent
>  
>  License:GPLv2+
>  URL:https://www.spice-space.org/
> -Source0:vdagent-win-%{version}%{?_version_suffix}.tar.xz
> +Source0:vdagent-win-@VERSION@%{?_version_suffix}.tar.xz
>  
>  BuildRequires:  mingw32-filesystem >= 23
>  BuildRequires:  mingw64-filesystem >= 23
> @@ -84,7 +84,7 @@ Features:
>session and the client
>  
>  %prep
> -%setup -q -n vdagent-win-%{version}%{?_version_suffix}
> +%setup -q -n vdagent-win-@VERSION@%{?_version_suffix}
>  
>  %{mingw_debug_package}
>  
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server] ci: Fix recent GitLab failures

[Pavel Grunt]

On Fri, 2017-07-28 at 12:44 +0100, Frediano Ziglio wrote:
> Recent GitLab CI jobs are failing to run valgrind checks
> (like https://gitlab.com/spice/spice/-/jobs/25220999).
> 
> This as recent distro changes cause valgrind not to find some
> symbols required to detect some GLib suppression errors.
> 
> Adding debugging information for GLib solve the problem.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  .gitlab-ci.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Tested at https://gitlab.com/freddy77/spice/-/jobs/25249286
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 491ae661..ddf1092c 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -23,7 +23,7 @@ statistics:
>  check-valgrind:
>script:
>- dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-re
> lease-$(rpm -E %fedora).noarch.rpm -y
> -  - dnf debuginfo-install spice-server -y
> +  - dnf debuginfo-install spice-server glib2 -y

Interesting, it should know automatically that it needs glib2 debug symbols
(like it knows for other dependencies)

>- >
>  dnf install valgrind
>  gstreamer1-libav gstreamer1-plugins-ugly gstreamer1-plugins-good
> gstreamer1-plugins-bad-free
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Survey of repository preferences

[Pavel Grunt]

Hi,

On Fri, 2017-07-28 at 09:15 +0200, Christophe de Dinechin wrote:
> > On 27 Jul 2017, at 17:07, Marc-André Lureau 
> > wrote:
> > 
> > Hi
> > 
> > - Original Message -
> > > > I think we should rather find a consensus on the mailing list rather
> > > > than
> > > > avoiding the discussion.
> > > 
> > > “Avoiding the discussion" sounds like a cheap and unjustified shot. Please
> > > discuss.
> > 
> > You are the one making proposal, you should come up with rationale. but ok
> 
> As I wrote, the rationale was discussed on this list between yesterday and
> today. I’ll repeat it here. Now, you were the one saying there were
> “problems”. I cannot guess the problems you have with my proposals if you
> don’t discuss them.
> 
> > 
> > > 
> > > > 
> > 
> > - Use gitlab/github as primary, make freedesktop a mirror *?
> > 
> > What benefit does that bring?
> 
> It is to get these additional features, that AFAIK freedesktop lacks:
> 
> 1. Continuous integration

it can be done through mirrors (it is the case for the gitlab mirror)

> 2. Merge requests or pull requests
> 3. Being actually open (reported by Christophe Fergeau). For example, it took
> me 6 months to get a working freedesktop account

Yeah, you have to ping someone to open the account

> 
> > The canonical source is hosted on freedesktop for ages.
> 
> That does not need to change.
> 
> > The role of this is a stable & controlled git repo to pull/push code to.
> 
> Why do I get a sense that “controlled” is the keyword here? ;-)
> 
> > Moving it to a different location doesn't change that. Using github/gitlab
> > as mirrors allows to have all the benefits of those hosting services.
> 
> To the best of my knowledge, that statement is incorrect
> 
> Specifically, we cannot enable merge requests on a mirror easily, because that
> means if we accept the merge request on gitlab, then gitlab is ahead of
> freedesktop, and when we push from freedesktop, that push is either rejected,
> or if we use push -f, we lose the merge.

You never push to a mirror.

> 
> Similarly, continuous integration on development branches,

Nothing block people from having ci/scripts to test their branches. Nowadays
people can fork our repos at gitlab and get a simple CI for free.
We can give this advice in README.

Also a committer can push the patches to her/his gitlab fork to make sure
everything is OK (before pushing to the main repo).

>  i.e. before we actually merge them, is not possible with freedesktop, even
> less so if your sense of “control” means you feel it’s OK to delete a review
> branch I push there without asking me first. All that is a bit moot anyway,
> because Google “freedesktop continuous integration” gives me nothing on the
> first page. 
> 
> > So why?
> 
> Because I think that continuous integration and a list of pending merge
> requests are more important than preserving the “we have been doing that for
> ages” comfort zone.
> 
> > 
> > - Rename spice as spice-server
> 
> - To unambiguously leave ‘spice’ as the name for a top-level repository.
> - So that mail-processing script does not have to do extra ad-hockery to map
> [PATCH spice-server] to a repo not named spice-server
> 
> Apparently, I’m not the first one to have the (obvious) idea, cf https://cgit.
> freedesktop.org/spice/spice-server (yet another confusing thing for newbies ;-
> )
> 
> > - Rename other repositories so that all children repos begin with 'spice-' *
> > 
> > I wasn't aware of that discussion, but changing a project name brings a
> > number of issues for distributions and people watching releases etc.
> > Renaming stuff is always problematic, what is the benefit?
> 
> Mostly to disambiguate between modules we really own (most of them) and
> modules that seem to be external dependencies for the spice project. For
> example, are libcacard or usbredir used by other projects?
> 
> Is spice/qemu an external dependency, is it there fore convenience? Or is that
> just obsolete? What about spice/spicec, spice/vdesktop, … I have a feeling
> there are a few stale repositories there.
> 
> The logical structure found in https://cgit.freedesktop.org/spice is nice.
> It’s not clearly visible e.g. on spice-space.org. And AFAIK, it’s not visible
> to git.
> 
> > 
> > - Create top-level repository with all others repositories as submodules (if
> > we use 'spice-server', that one would be called 'spice') *
> > 
> > Isn't this already the case? https://cgit.freedesktop.org/spice/
> 
> If that’s the case, it’s cool. But it looks like a group of repositories in
> freedesktop, more than a repository with submodules. What is the git clone
> command to clone that top-level repo?
> 
> Having a top-level repository makes work on branches that impact multiple
> components easier.
For you, not for me :)

>  Case in point today: streaming impacts server, protocol, agent, client, etc.
> So being able to easily switch to the “stream” branch and update protocol,
> agent, 

Re: [Spice-devel] [vdagent-win PATCH] Do not use dash in rpm version

[Pavel Grunt]

Hi,

Cool, looks good to me

I can confirm that thanks to this patch is possible to do things like:
   1. make dist
   2. md5sum vdagent-win-0.8.0.34-7b15.tar.xz > sources
   3. fedpkg srpm

And for instance use the srpm to create a build in koji/brew/copr

On Wed, 2017-07-26 at 16:03 +0100, Frediano Ziglio wrote:
> RPM does not allow dash in version string.
> Remove everything after the dash (which should be the "dirty"
> git version).
> This make easier to run "make dist" followed by rpmbuild.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  configure.ac| 2 ++
>  mingw-spice-vdagent.spec.in | 6 +++---
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> Maybe I should use sed 's,-,.,g' to just replace
> all dashes with dots ?

it is like s/-/./g so it looks more clean to me, but it's up to you :) Both
variants are ok

Pavel
> 
> diff --git a/configure.ac b/configure.ac
> index bb33075..dc75c25 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,6 +38,8 @@ AC_DEFINE_UNQUOTED([RC_PRODUCTVERSION_STR],
> "$RC_PRODUCTVERSION", [Resource prod
>  AC_DEFINE_UNQUOTED([RC_PRODUCTVERSION], [$RC_PRODUCTVERSION], [Resource
> product version])
>  BUILD_YEAR=`date +%Y`
>  AC_DEFINE_UNQUOTED([BUILD_YEAR], "$BUILD_YEAR", [Build year])
> +RPM_VERSION=`echo $PACKAGE_VERSION | sed 's,-.*,,'`
> +AC_SUBST([RPM_VERSION])
>  
>  # Check for programs
>  AC_PROG_CC
> diff --git a/mingw-spice-vdagent.spec.in b/mingw-spice-vdagent.spec.in
> index d25ea31..d129a7b 100644
> --- a/mingw-spice-vdagent.spec.in
> +++ b/mingw-spice-vdagent.spec.in
> @@ -16,13 +16,13 @@
>  %endif
>  
>  Name:   mingw-spice-vdagent
> -Version:@VERSION@
> +Version:@RPM_VERSION@
>  Release:1%{?dist}%{?extra_release}
>  Summary:MinGW Windows SPICE guest agent
>  
>  License:GPLv2+
>  URL:https://www.spice-space.org/
> -Source0:vdagent-win-%{version}%{?_version_suffix}.tar.xz
> +Source0:vdagent-win-@VERSION@%{?_version_suffix}.tar.xz
>  
>  BuildRequires:  mingw32-filesystem >= 23
>  BuildRequires:  mingw64-filesystem >= 23
> @@ -84,7 +84,7 @@ Features:
>session and the client
>  
>  %prep
> -%setup -q -n vdagent-win-%{version}%{?_version_suffix}
> +%setup -q -n vdagent-win-@VERSION@%{?_version_suffix}
>  
>  %{mingw_debug_package}
>  
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v2] usbredir: fix deadlock on error

[Pavel Grunt]

On Tue, 2017-06-20 at 13:10 +0200, Victor Toso wrote:
> From: leaboy 
> 
> The current code deadlocks when a USB error occurs, releasing the
> channel lock before the idle is called fixes this problem.
> 
> More specifically when an error occurs, we queue a call to device_error
> in an idle, and switch to the main context. The device_error() calls
> spice_usbredir_channel_disconnect_device() which needs the channel to be
> unlocked as it calls spice_usbredir_channel_lock().

Ack

Thanks,
Pavel


> 
> Examples:
> - Redirect USB Storage device to the guest and copy some big file. While
>   copy is ongoing, unplug the USB Storage from the client machine;
> - Unplug the usb device from the client machine while the USB Storage
>   device is being identified in the guest.
> - With the auto-redirection option enabled, plug and unplug the USB
>   Storage Device frequently.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1353528
> Signed-off-by: Victor Toso 
> ---
>  src/channel-usbredir.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/channel-usbredir.c b/src/channel-usbredir.c
> index fef62ce..1f791bc 100644
> --- a/src/channel-usbredir.c
> +++ b/src/channel-usbredir.c
> @@ -927,15 +927,16 @@ static void usbredir_handle_msg(SpiceChannel *c,
> SpiceMsgIn *in)
>  err_data.caller = coroutine_self();
>  err_data.spice_device = g_boxed_copy(spice_usb_device_get_type(),
> spice_device);
>  err_data.error = err;
> +spice_usbredir_channel_unlock(channel);
>  g_idle_add(device_error, _data);
>  coroutine_yield(NULL);
>  
>  g_boxed_free(spice_usb_device_get_type(), err_data.spice_device);
>  
>  g_error_free(err);
> +} else {
> +spice_usbredir_channel_unlock(channel);
>  }
> -
> -spice_usbredir_channel_unlock(channel);
>  }
>  
>  #endif /* USE_USBREDIR */
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] Use designated struct initializer

[Pavel Grunt]

On Fri, 2017-07-07 at 16:26 +0200, Pavel Grunt wrote:
> Silence -Wmissing-field-initializers warnings.

Forgot to mention, it happens when building tests. My gcc --version:
gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)

But I'm not sure it is specific to gcc version, a similar fix has been replied
recently for spice-server and reporter mentioned gcc 4.9...
> ---
> imo it also makes the code more readable (especially tests/session.c)
> ---
>  src/channel-display-gst.c |   3 +-
>  src/channel-main.c|   4 +-
>  src/channel-record.c  |  16 +++--
>  src/spice-channel.c   |  12 ++--
>  src/spice-gtk-session.c   |  14 ++---
>  src/spice-pulse.c |  18 +++---
>  src/spice-session.c   |   2 +-
>  tests/session.c   | 156 +--
> ---
>  8 files changed, 118 insertions(+), 107 deletions(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 9b79403..807ff85 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -306,7 +306,7 @@ static gboolean create_pipeline(SpiceGstDecoder *decoder)
>  gchar *desc;
>  gboolean auto_enabled;
>  guint opt;
> -GstAppSinkCallbacks appsink_cbs = { NULL };
> +GstAppSinkCallbacks appsink_cbs = { .new_sample = new_sample };
>  GError *err = NULL;
>  GstBus *bus;
>  
> @@ -344,7 +344,6 @@ static gboolean create_pipeline(SpiceGstDecoder *decoder)
>  decoder->appsrc = GST_APP_SRC(gst_bin_get_by_name(GST_BIN(decoder-
> >pipeline), "src"));
>  decoder->appsink = GST_APP_SINK(gst_bin_get_by_name(GST_BIN(decoder-
> >pipeline), "sink"));
>  
> -appsink_cbs.new_sample = new_sample;
>  gst_app_sink_set_callbacks(decoder->appsink, _cbs, decoder,
> NULL);
>  bus = gst_pipeline_get_bus(GST_PIPELINE(decoder->pipeline));
>  gst_bus_add_watch(bus, handle_pipeline_message, decoder);
> diff --git a/src/channel-main.c b/src/channel-main.c
> index 4edd575..104b18a 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -1275,7 +1275,7 @@ static void agent_sync_audio_record(SpiceMainChannel
> *main_channel)
>  static void agent_display_config(SpiceMainChannel *channel)
>  {
>  SpiceMainChannelPrivate *c = channel->priv;
> -VDAgentDisplayConfig config = { 0, };
> +VDAgentDisplayConfig config = { .flags = 0, .depth = 0};
>  
>  if (c->display_disable_wallpaper) {
>  config.flags |= VD_AGENT_DISPLAY_CONFIG_FLAG_DISABLE_WALLPAPER;
> @@ -2334,7 +2334,7 @@ static void main_migrate_connect(SpiceChannel *channel,
>  {
>  SpiceMainChannelPrivate *main_priv = SPICE_MAIN_CHANNEL(channel)->priv;
>  int reply_type = SPICE_MSGC_MAIN_MIGRATE_CONNECT_ERROR;
> -spice_migrate mig = { 0, };
> +spice_migrate mig = { .from = NULL, };
>  SpiceMsgOut *out;
>  SpiceSession *session;
>  
> diff --git a/src/channel-record.c b/src/channel-record.c
> index 9834e85..2023bb4 100644
> --- a/src/channel-record.c
> +++ b/src/channel-record.c
> @@ -255,18 +255,18 @@ static void
> spice_record_channel_class_init(SpiceRecordChannelClass *klass)
>  static void spice_record_mode(SpiceRecordChannel *channel, uint32_t time,
>uint32_t mode, uint8_t *data, uint32_t
> data_size)
>  {
> -SpiceMsgcRecordMode m = {0, };
> +SpiceMsgcRecordMode m = {
> +.time = time,
> +.mode = mode,
> +.data = data,
> +.data_size = data_size,
> +};
>  SpiceMsgOut *msg;
>  
>  g_return_if_fail(channel != NULL);
>  if (spice_channel_get_read_only(SPICE_CHANNEL(channel)))
>  return;
>  
> -m.mode = mode;
> -m.time = time;
> -m.data = data;
> -m.data_size = data_size;
> -
>  msg = spice_msg_out_new(SPICE_CHANNEL(channel), SPICE_MSGC_RECORD_MODE);
>  msg->marshallers->msgc_record_mode(msg->marshaller, );
>  spice_msg_out_send(msg);
> @@ -317,7 +317,7 @@ void spice_record_send_data(SpiceRecordChannel *channel,
> gpointer data,
>  gsize bytes, uint32_t time)
>  {
>  SpiceRecordChannelPrivate *rc;
> -SpiceMsgcRecordPacket p = {0, };
> +SpiceMsgcRecordPacket p = { .time = time };
>  
>  g_return_if_fail(SPICE_IS_RECORD_CHANNEL(channel));
>  rc = channel->priv;
> @@ -339,8 +339,6 @@ void spice_record_send_data(SpiceRecordChannel *channel,
> gpointer data,
>  if (rc->mode != SPICE_AUDIO_DATA_MODE_RAW)
>  encode_buf = g_alloca(SND_CODEC_MAX_COMPRESSED_BYTES);
>  
> -p.time = time;
> -
>  while (bytes > 0) {
>  gsize n;
>  int frame_size;
> diff --g

Re: [Spice-devel] [spice-gtk] gstreamer: Take into account stride information

[Pavel Grunt]

On Tue, 2017-07-25 at 10:50 -0400, Frediano Ziglio wrote:
> > 
> > Hi Frediano,
> > 
> > On Tue, 2017-07-25 at 15:31 +0100, Frediano Ziglio wrote:
> > > Using hardware encoders/decoders is possible that the output
> > > stride of the image cannot be computed with a fixed formula
> > > (width * 4). GStreamer in this case should set GstVideoMeta
> > > information with the correct stride value.
> > > Consider this value if present.
> > > This fix a problem using NvDec encoder and Intel decoder.
> > 
> > you mean NVENC encoder
> > 
> 
> correct :)
> 
> > > 
> > > Signed-off-by: Frediano Ziglio 
> > > ---
> > >  src/channel-display-gst.c   | 9 -
> > >  src/channel-display-mjpeg.c | 2 +-
> > >  src/channel-display-priv.h  | 2 +-
> > >  src/channel-display.c   | 6 --
> > >  4 files changed, 14 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > > index 03c6044..0abe706 100644
> > > --- a/src/channel-display-gst.c
> > > +++ b/src/channel-display-gst.c
> > > @@ -26,6 +26,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  
> > >  /* GStreamer decoder implementation */
> > > @@ -102,6 +103,12 @@ static void free_gst_frame(SpiceGstFrame *gstframe)
> > >  
> > >  static void schedule_frame(SpiceGstDecoder *decoder);
> > >  
> > > +static int gst_buffer_get_stride(GstBuffer *buffer)
> > 
> > I'd prefer to do in our namespace instead on gstreamer's
> > > +{
> > > +GstVideoMeta *video = gst_buffer_get_video_meta(buffer);
> > > +return video ? video->stride[0] : 0;
> > 
> > The documentation of GstVideoMeta says that the value of the stride may be
> > invalid - do you know what is the value in that case?
> > 
> > What about using some constant instead of 0 (respectively the invalid value)
> > (SPICE_UNKNOWN_STRIDE)
> > 
> 
> No idea the gstreamer invalid value. Maybe n_planes == 0 ?
> Where do you suggest to define it?
> 
> #define SPICE_UNKNOWN_STRIDE 0
> 
> in src/channel-display-priv.h ?
> 
yes

> > 
> > > +}
> > > +
> > >  /* main context */
> > >  static gboolean display_frame(gpointer video_decoder)
> > >  {
> > > @@ -145,7 +152,7 @@ static gboolean display_frame(gpointer video_decoder)
> > >  }
> > >  
> > >  stream_display_frame(decoder->base.stream, gstframe->frame,
> > > - width, height, mapinfo.data);
> > > + width, height, gst_buffer_get_stride(buffer),
> > > mapinfo.data);
> > >  gst_buffer_unmap(buffer, );
> > >  
> > >   error:
> > > diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
> > > index 3ba098c..6082511 100644
> > > --- a/src/channel-display-mjpeg.c
> > > +++ b/src/channel-display-mjpeg.c
> > > @@ -176,7 +176,7 @@ static gboolean mjpeg_decoder_decode_frame(gpointer
> > > video_decoder)
> > >  
> > >  /* Display the frame and dispose of it */
> > >  stream_display_frame(decoder->base.stream, decoder->cur_frame,
> > > - width, height, decoder->out_frame);
> > > + width, height, 0, decoder->out_frame);
> > 
> > same here
> > 
> > >  free_spice_frame(decoder->cur_frame);
> > >  decoder->cur_frame = NULL;
> > >  decoder->timer_id = 0;
> > > diff --git a/src/channel-display-priv.h b/src/channel-display-priv.h
> > > index 04cb4d1..72e0840 100644
> > > --- a/src/channel-display-priv.h
> > > +++ b/src/channel-display-priv.h
> > > @@ -192,7 +192,7 @@ G_STATIC_ASSERT(G_N_ELEMENTS(gst_opts) <=
> > > SPICE_VIDEO_CODEC_TYPE_ENUM_END);
> > >  
> > >  guint32 stream_get_time(display_stream *st);
> > >  void stream_dropped_frame_on_playback(display_stream *st);
> > > -void stream_display_frame(display_stream *st, SpiceFrame *frame, uint32_t
> > > width, uint32_t height, uint8_t* data);
> > > +void stream_display_frame(display_stream *st, SpiceFrame *frame, uint32_t
> > > width, uint32_t height, int stride, uint8_t* data);
> > >  gint64 get_stream_id_by_stream(SpiceChannel *channel, display_stream
> > > *st);
> > >  
> > >  
> > > diff --git a/src/channel-display.c b/src/channel-display.c
> > > index 06ed18a..4eb665f 100644
> > > --- a/src/channel-display.c
> > > +++ b/src/channel-display.c
> > > @@ -1312,9 +1312,11 @@ void
> > > stream_dropped_frame_on_playback(display_stream
> > > *st)
> > >  /* main context */
> > >  G_GNUC_INTERNAL
> > >  void stream_display_frame(display_stream *st, SpiceFrame *frame,
> > > -  uint32_t width, uint32_t height, uint8_t *data)
> > > +  uint32_t width, uint32_t height, int stride,
> > > uint8_t *data)
> > >  {
> > > -int stride = width * sizeof(uint32_t);
> > > +if (stride == 0) {
> > 
> > and here
> > > +stride = width * sizeof(uint32_t);
> > > +}
> > >  if (!(st->flags & SPICE_STREAM_FLAGS_TOP_DOWN)) {
> > >  data += stride * (height - 1);
> > >  stride = -stride;
> 
> Frediano

Re: [Spice-devel] [spice-gtk] gstreamer: Take into account stride information

[Pavel Grunt]

Hi Frediano,

On Tue, 2017-07-25 at 15:31 +0100, Frediano Ziglio wrote:
> Using hardware encoders/decoders is possible that the output
> stride of the image cannot be computed with a fixed formula
> (width * 4). GStreamer in this case should set GstVideoMeta
> information with the correct stride value.
> Consider this value if present.
> This fix a problem using NvDec encoder and Intel decoder.
you mean NVENC encoder

> 
> Signed-off-by: Frediano Ziglio 
> ---
>  src/channel-display-gst.c   | 9 -
>  src/channel-display-mjpeg.c | 2 +-
>  src/channel-display-priv.h  | 2 +-
>  src/channel-display.c   | 6 --
>  4 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 03c6044..0abe706 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  
>  /* GStreamer decoder implementation */
> @@ -102,6 +103,12 @@ static void free_gst_frame(SpiceGstFrame *gstframe)
>  
>  static void schedule_frame(SpiceGstDecoder *decoder);
>  
> +static int gst_buffer_get_stride(GstBuffer *buffer)
I'd prefer to do in our namespace instead on gstreamer's
> +{
> +GstVideoMeta *video = gst_buffer_get_video_meta(buffer);
> +return video ? video->stride[0] : 0;
The documentation of GstVideoMeta says that the value of the stride may be
invalid - do you know what is the value in that case?

What about using some constant instead of 0 (respectively the invalid value)
(SPICE_UNKNOWN_STRIDE)


> +}
> +
>  /* main context */
>  static gboolean display_frame(gpointer video_decoder)
>  {
> @@ -145,7 +152,7 @@ static gboolean display_frame(gpointer video_decoder)
>  }
>  
>  stream_display_frame(decoder->base.stream, gstframe->frame,
> - width, height, mapinfo.data);
> + width, height, gst_buffer_get_stride(buffer),
> mapinfo.data);
>  gst_buffer_unmap(buffer, );
>  
>   error:
> diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
> index 3ba098c..6082511 100644
> --- a/src/channel-display-mjpeg.c
> +++ b/src/channel-display-mjpeg.c
> @@ -176,7 +176,7 @@ static gboolean mjpeg_decoder_decode_frame(gpointer
> video_decoder)
>  
>  /* Display the frame and dispose of it */
>  stream_display_frame(decoder->base.stream, decoder->cur_frame,
> - width, height, decoder->out_frame);
> + width, height, 0, decoder->out_frame);

same here

>  free_spice_frame(decoder->cur_frame);
>  decoder->cur_frame = NULL;
>  decoder->timer_id = 0;
> diff --git a/src/channel-display-priv.h b/src/channel-display-priv.h
> index 04cb4d1..72e0840 100644
> --- a/src/channel-display-priv.h
> +++ b/src/channel-display-priv.h
> @@ -192,7 +192,7 @@ G_STATIC_ASSERT(G_N_ELEMENTS(gst_opts) <=
> SPICE_VIDEO_CODEC_TYPE_ENUM_END);
>  
>  guint32 stream_get_time(display_stream *st);
>  void stream_dropped_frame_on_playback(display_stream *st);
> -void stream_display_frame(display_stream *st, SpiceFrame *frame, uint32_t
> width, uint32_t height, uint8_t* data);
> +void stream_display_frame(display_stream *st, SpiceFrame *frame, uint32_t
> width, uint32_t height, int stride, uint8_t* data);
>  gint64 get_stream_id_by_stream(SpiceChannel *channel, display_stream *st);
>  
>  
> diff --git a/src/channel-display.c b/src/channel-display.c
> index 06ed18a..4eb665f 100644
> --- a/src/channel-display.c
> +++ b/src/channel-display.c
> @@ -1312,9 +1312,11 @@ void stream_dropped_frame_on_playback(display_stream
> *st)
>  /* main context */
>  G_GNUC_INTERNAL
>  void stream_display_frame(display_stream *st, SpiceFrame *frame,
> -  uint32_t width, uint32_t height, uint8_t *data)
> +  uint32_t width, uint32_t height, int stride,
> uint8_t *data)
>  {
> -int stride = width * sizeof(uint32_t);
> +if (stride == 0) {
and here
> +stride = width * sizeof(uint32_t);
> +}
>  if (!(st->flags & SPICE_STREAM_FLAGS_TOP_DOWN)) {
>  data += stride * (height - 1);
>  stride = -stride;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Fix build without egl

[Pavel Grunt]

spice_display_widget_gl_scanout is defined only when building with egl
 ./.libs/libspice-client-gtk-3.0.so: undefined reference to 
`spice_display_widget_gl_scanout'
---
 src/spice-widget-priv.h | 2 ++
 src/spice-widget.c  | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/spice-widget-priv.h b/src/spice-widget-priv.h
index ea7ed8e..1189cbb 100644
--- a/src/spice-widget-priv.h
+++ b/src/spice-widget-priv.h
@@ -169,7 +169,9 @@ gboolean spice_egl_update_scanout(SpiceDisplay 
*display,
   GError **err);
 void spice_egl_cursor_set(SpiceDisplay *display);
 
+#ifdef HAVE_EGL
 void spice_display_widget_gl_scanout (SpiceDisplay *display);
+#endif
 void spice_display_widget_update_monitor_area(SpiceDisplay *display);
 
 G_END_DECLS
diff --git a/src/spice-widget.c b/src/spice-widget.c
index 6f4abc0..d5ebd9d 100644
--- a/src/spice-widget.c
+++ b/src/spice-widget.c
@@ -616,7 +616,7 @@ G_GNUC_END_IGNORE_DEPRECATIONS
 static void
 drawing_area_realize(GtkWidget *area, gpointer user_data)
 {
-#ifdef GDK_WINDOWING_X11
+#if defined(GDK_WINDOWING_X11) && defined(HAVE_EGL)
 SpiceDisplay *display = SPICE_DISPLAY(user_data);
 
 if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
-- 
2.13.3

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

Re: [Spice-devel] [spice-server] Prepare for 0.13.90 release

[Pavel Grunt]

Hey,

On Thu, 2017-07-20 at 17:12 +0200, Christophe Fergeau wrote:
> Update NEWS and soname.
> ---
>  NEWS | 19 +++
>  configure.ac |  2 +-
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> Hey,
> 
> It's high time that we have an unstable release, and I'd like to start
> converging towards a stable 0.14 release. So we could release a 0.13.90
> release
it is a good time for the release. Ack from me.

> candidate (this patch), and hopefully release 0.14.0 soon if it proves not to
> be too bad ;)

There are builds at our copr [1] for those who want to test this easily on
el7/fedora 

[1] https://copr.fedorainfracloud.org/coprs/g/spice/nightly/package/spice/

Thanks,
Pavel
> 
> Christophe
> 
> 
> diff --git a/NEWS b/NEWS
> index eb994838d..784747e3f 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,3 +1,22 @@
> +Major Changes in 0.13.90:
> +=
> +
> +*** IMPORTANT ***
> +0.13.90 is the first release candidate for the stable 0.14.x series. While
> some
> +bugs might still be present, it should be reasonably stable. If you are
> looking
> +for stability for daily use, please keep using the latest 0.12.x release.
> +
> +* Close TCP connection early when client did not send the correct SPICE magic
> +  bytes: this allows VNC clients to gracefully fail when connecting to a
> SPICE
> +  port
> +* Fixes for CVE-2016-9577, CVE-2016-9578 and CVE-2017-7506
> +* Fix client being disconnected after migration (bug introduced in 0.13.3)
> +* Add a --enable-statistics configure option
> +* GLIB 2.28 is now a required build time dependency (used to be 2.22)
> +* Add VP9 encoding support when GStreamer is being used and misc
> +  streaming/encoding improvements
> +* more code refactoring/reorganization work
> +
>  Major Changes in 0.13.3:
>  
>  
> diff --git a/configure.ac b/configure.ac
> index 95985a68d..e1e748621 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -13,7 +13,7 @@ AC_PREREQ([2.57])
>  #
>  dnl TODO see server/spice-char.h TODO comment for API breakage
>  m4_define([SPICE_CURRENT], [13])
> -m4_define([SPICE_REVISION], [1])
> +m4_define([SPICE_REVISION], [2])
>  m4_define([SPICE_AGE], [12])
>  
>  AC_INIT(spice, [m4_esyscmd(build-aux/git-version-gen .tarball-version)],
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Add flatpak builder manifest file for spicy

[Pavel Grunt]

To give an example for creating flatpaks depending on spice-gtk

How to build and run the flatpak:
spicy uses GNOME SDK runtime, version 3.24. The runtime provides tools
and libraries necessary to build the flatpak
 $ flatpak remote-add --if-not-exists gnome 
https://sdk.gnome.org/gnome.flatpakrepo
 $ flatpak install gnome org.gnome.Sdk//3.24

To build and run the flatpak of spicy:
 $ flatpak-builder spicy data/org.spicespace.spicy.json
 $ flatpak build-export repo spicy
 $ flatpak --user remote-add --no-gpg-verify --if-not-exists spice-repo repo
 $ flatpak --user install spice-repo org.spicespace.spicy
 $ flatpak run org.spicespace.spicy
---
v1:
 - addressed Christophe's comments
 - removed PERLPATH
 - fixed audio by adding the pulseaudio socket
---
 data/org.spicespace.spicy.json | 71 ++
 1 file changed, 71 insertions(+)
 create mode 100644 data/org.spicespace.spicy.json

diff --git a/data/org.spicespace.spicy.json b/data/org.spicespace.spicy.json
new file mode 100644
index 000..1e03bf9
--- /dev/null
+++ b/data/org.spicespace.spicy.json
@@ -0,0 +1,71 @@
+{
+"app-id": "org.spicespace.spicy",
+"runtime": "org.gnome.Platform",
+"runtime-version": "3.24",
+"sdk": "org.gnome.Sdk",
+"command": "spicy",
+"tags": ["devel", "development", "nightly"],
+"finish-args": [
+"--share=ipc", "--socket=x11",
+"--socket=wayland",
+"--socket=pulseaudio",
+"--share=network"
+],
+"modules": [
+{
+"name": "python-six",
+"buildsystem": "simple",
+"build-commands": [
+"pip3 install --target=/app six-1.10.0-py2.py3-none-any.whl"
+],
+"sources": [
+{
+   "type": "file",
+   "url": 
"https://pypi.python.org/packages/c8/0a/b6723e1bc4c516cb687841499455a8505b44607ab535be01091c0f24f079/six-1.10.0-py2.py3-none-any.whl#md5=3ab558cf5d4f7a72611d59a81a315dc8;,
+   "sha256": 
"0ff78c403d9bccf5a425a6d31a12aa6b47f1c21ca4dc2573a7e2f32a97335eb1"
+}
+]
+},
+{
+"name": "pyparsing",
+"buildsystem": "simple",
+"build-commands": [
+"pip3 install --target=/app 
pyparsing-2.0.3-py2.py3-none-any.whl"
+],
+"sources": [
+{
+"type": "file",
+"url": 
"https://pypi.python.org/packages/8f/f4/3a70b5e5b865b1ec45fe48dc5a57cd4facb5c7bd80e5cb1255c362732e81/pyparsing-2.0.3-py2.py3-none-any.whl#md5=4c16ef222caea2e5de741ae503aae652;,
+"sha256": 
"a9c896bab06dbf3759ad5fb63cfdb3777191e2c4ae640e6dd69ed37530f6ba56"
+}
+]
+},
+{
+"builddir": true,
+"name": "spice-protocol",
+"sources": [
+{
+"type": "git",
+"url": "git://anongit.freedesktop.org/spice/spice-protocol"
+}
+]
+},
+{
+"builddir": true,
+"name": "spice-gtk",
+"build-options": {
+"env": {
+"PYTHONPATH": "/app"
+}
+},
+"config-opts": [ "--disable-controller", "--disable-vala",
+ "--disable-gtk-doc", "--enable-python-checks" ],
+"sources": [
+{
+"type": "git",
+"url": "git://anongit.freedesktop.org/spice/spice-gtk"
+}
+]
+}
+]
+}
-- 
2.13.3

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

Re: [Spice-devel] [RFC spice-gtk] Add flatpak builder manifest file for spicy

[Pavel Grunt]

On Fri, 2017-07-21 at 10:29 +0200, Christophe Fergeau wrote:
> Hey,
> 
> On Thu, Jul 20, 2017 at 10:49:48PM +0200, Pavel Grunt wrote:
> > To give example for creating flatpaks depending on spice-gtk
> > 
> 
> Yup, good idea, just a few minor comments:
> 
> > How to use to build and run the flatpak:
> 
> Maybe mention that the gnome 3.24 SDK has to be installed?
ok
> 
> >  $ flatpak-builder spicy org.spicespace.spicy.json
> 
> I'd use data/org.spicespace.spicy.json
ok

btw I noticed that some projects put this file into the project's root
directory, some have flatpak subdirectory. I guess data/ is fine for us.

> Any reason for using org.spicespace rather than org.spice-space?
I know, apparently it is not allowed to use '-' in the name

error: 'org.spice-space.spicy' is not a valid application name: Only last name
segment can contain -

it is indeed an interesting requirement 
>  I think
> we usually use the latter as our domain name, even though spicespace is
> an alias to it.
> 
> >  $ flatpak build-export repo spicy
> >  $ flatpak --user remote-add --no-gpg-verify --if-not-exists spice-repo repo
> >  $ flatpak --user install spice-repo org.spicespace.spicy
> >  $ flatpak run org.spicespace.spicy
> > ---
> >  data/org.spicespace.spicy.json | 72
> > ++
> >  1 file changed, 72 insertions(+)
> >  create mode 100644 data/org.spicespace.spicy.json
> > 
> > diff --git a/data/org.spicespace.spicy.json b/data/org.spicespace.spicy.json
> > new file mode 100644
> > index 000..e384aff
> > --- /dev/null
> > +++ b/data/org.spicespace.spicy.json
> > @@ -0,0 +1,72 @@
> > +{
> > +"app-id": "org.spicespace.spicy",
> > +"runtime": "org.gnome.Platform",
> > +"runtime-version": "3.24",
> > +"sdk": "org.gnome.Sdk",
> > +"command": "spicy",
> > +"tags": ["devel", "development", "nightly"],
> > +"finish-args": [
> > +"--share=ipc", "--socket=x11",
> > +"--socket=wayland",
> > +"--filesystem=xdg-pictures",
> > +"--share=network"
> > +],
> > +"modules": [
> > +{
> > +"name": "python-six",
> > +"buildsystem": "simple",
> > +"build-commands": [
> > +"pip3 install --target=/app six-1.10.0-py2.py3-none-
> > any.whl"
> > +],
> > +"sources": [
> > +{
> > +   "type": "file",
> > +   "url": "https://pypi.python.org/packages/c8/0a/b6723e1bc
> > 4c516cb687841499455a8505b44607ab535be01091c0f24f079/six-1.10.0-py2.py3-none-
> > any.whl#md5=3ab558cf5d4f7a72611d59a81a315dc8",
> > +   "sha256":
> > "0ff78c403d9bccf5a425a6d31a12aa6b47f1c21ca4dc2573a7e2f32a97335eb1"
> > +}
> > +]
> > +},
> > +{
> > +"name": "pyparsing",
> > +"buildsystem": "simple",
> > +"build-commands": [
> > +"pip3 install --target=/app pyparsing-2.0.3-py2.py3-none-
> > any.whl"
> > +],
> > +"sources": [
> > +{
> > +"type": "file",
> > +"url": "https://pypi.python.org/packages/8f/f4/3a70b5e5
> > b865b1ec45fe48dc5a57cd4facb5c7bd80e5cb1255c362732e81/pyparsing-2.0.3-
> > py2.py3-none-any.whl#md5=4c16ef222caea2e5de741ae503aae652",
> > +"sha256":
> > "a9c896bab06dbf3759ad5fb63cfdb3777191e2c4ae640e6dd69ed37530f6ba56"
> > +}
> > +]
> > +},
> > +{
> > +"builddir": true,
> > +"name": "spice-protocol",
> > +"sources": [
> > +{
> > +"type": "git",
> > +"url": "git://anongit.freedesktop.org/spice/spice-
> > protocol"
> > +}
> > +]
> > +},
> > +{
> > +"builddir": true,
> > +"name": "spice-gtk",
> > +"build-options": {
> > +"env": {
> > +"PERL5LIB": "/app/lib/perl5",
> > +"PYTHONPATH": "/app"
> > +}
> 
> Is that really required? Shouldn't flatpak-builder do it for us?

perl should be dropped, PYTHON path is required, otherwise it fails to find the
installed modules. It is possible that I install them in a wrong way.

Thanks for the comments,
Pavel

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

[Spice-devel] [RFC spice-gtk] Add flatpak builder manifest file for spicy

[Pavel Grunt]

To give example for creating flatpaks depending on spice-gtk

How to use to build and run the flatpak:
 $ flatpak-builder spicy org.spicespace.spicy.json
 $ flatpak build-export repo spicy
 $ flatpak --user remote-add --no-gpg-verify --if-not-exists spice-repo repo
 $ flatpak --user install spice-repo org.spicespace.spicy
 $ flatpak run org.spicespace.spicy
---
 data/org.spicespace.spicy.json | 72 ++
 1 file changed, 72 insertions(+)
 create mode 100644 data/org.spicespace.spicy.json

diff --git a/data/org.spicespace.spicy.json b/data/org.spicespace.spicy.json
new file mode 100644
index 000..e384aff
--- /dev/null
+++ b/data/org.spicespace.spicy.json
@@ -0,0 +1,72 @@
+{
+"app-id": "org.spicespace.spicy",
+"runtime": "org.gnome.Platform",
+"runtime-version": "3.24",
+"sdk": "org.gnome.Sdk",
+"command": "spicy",
+"tags": ["devel", "development", "nightly"],
+"finish-args": [
+"--share=ipc", "--socket=x11",
+"--socket=wayland",
+"--filesystem=xdg-pictures",
+"--share=network"
+],
+"modules": [
+{
+"name": "python-six",
+"buildsystem": "simple",
+"build-commands": [
+"pip3 install --target=/app six-1.10.0-py2.py3-none-any.whl"
+],
+"sources": [
+{
+   "type": "file",
+   "url": 
"https://pypi.python.org/packages/c8/0a/b6723e1bc4c516cb687841499455a8505b44607ab535be01091c0f24f079/six-1.10.0-py2.py3-none-any.whl#md5=3ab558cf5d4f7a72611d59a81a315dc8;,
+   "sha256": 
"0ff78c403d9bccf5a425a6d31a12aa6b47f1c21ca4dc2573a7e2f32a97335eb1"
+}
+]
+},
+{
+"name": "pyparsing",
+"buildsystem": "simple",
+"build-commands": [
+"pip3 install --target=/app 
pyparsing-2.0.3-py2.py3-none-any.whl"
+],
+"sources": [
+{
+"type": "file",
+"url": 
"https://pypi.python.org/packages/8f/f4/3a70b5e5b865b1ec45fe48dc5a57cd4facb5c7bd80e5cb1255c362732e81/pyparsing-2.0.3-py2.py3-none-any.whl#md5=4c16ef222caea2e5de741ae503aae652;,
+"sha256": 
"a9c896bab06dbf3759ad5fb63cfdb3777191e2c4ae640e6dd69ed37530f6ba56"
+}
+]
+},
+{
+"builddir": true,
+"name": "spice-protocol",
+"sources": [
+{
+"type": "git",
+"url": "git://anongit.freedesktop.org/spice/spice-protocol"
+}
+]
+},
+{
+"builddir": true,
+"name": "spice-gtk",
+"build-options": {
+"env": {
+"PERL5LIB": "/app/lib/perl5",
+"PYTHONPATH": "/app"
+}
+},
+"config-opts": [ "--disable-controller", "--disable-vala",
+ "--disable-gtk-doc", "--enable-python-checks" ],
+"sources": [
+{
+"type": "git",
+"url": "git://anongit.freedesktop.org/spice/spice-gtk"
+}
+]
+}
+]
+}
-- 
2.13.3

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

Re: [Spice-devel] [PATCH] gst: new_sample: remove redundant sample? condition

[Pavel Grunt]

Ack

Thanks,
Pavel

On Thu, 2017-07-20 at 19:41 +0300, Uri Lublin wrote:
> Move the declaration and assignment of 'buffer' into
> the if (sample) block, where sample is not NULL.
>   
> Signed-off-by: Uri Lublin 
> ---
>  src/channel-display-gst.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 3f51361..03c6044 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -200,8 +200,8 @@ static GstFlowReturn new_sample(GstAppSink *gstappsink,
> gpointer video_decoder)
>  SpiceGstDecoder *decoder = video_decoder;
>  
>  GstSample *sample = gst_app_sink_pull_sample(decoder->appsink);
> -GstBuffer *buffer = sample ? gst_sample_get_buffer(sample) : NULL;
>  if (sample) {
> +GstBuffer *buffer = gst_sample_get_buffer(sample);
>  g_mutex_lock(>queues_mutex);
>  
>  /* gst_app_sink_pull_sample() sometimes returns the same buffer twice
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

Victor,

it is faster to write NACK

On Thu, 2017-07-20 at 07:26 +0200, Victor Toso wrote:
> A new day, a new thread
> 
> On Wed, Jul 19, 2017 at 02:59:00PM +0200, Pavel Grunt wrote:
> > GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> > streams. However the check for elements through GstRegistry does not
> > take into account the possible pipeline of elements (like "h264parse !
> > avdec_h264").
> > 
> > Fix that by checking for the elements by their name.
> 
> By reading your commit log, your are fixing a single use case by
> checking element's names that are hard coded to our codebase.
> 
> The reason for the following two patches were to remove the usage of
> hard coded names to check and play the stream.
> 
> Shortlog: display-gst: Use Playbin for GStreamer 1.9.0 onwards
> Commit  : ed697dd7fa165632bd0cbdb34c971c8001c433fa
> Victor Toso on Mon, 10 Jul 2017 17:34:23 +0200
> 
> Shortlog: display-gst: check GstRegistry for decoding elements
> Commit  : c9209aef946b3ad517e7794d2e5648caf5ee2bf9
> Victor Toso on Mon, 10 Jul 2017 17:33:10 +0200
> 
> So, this patch is going backwards in regard to one of the objectives of
> playbin's introducing besides the fact that it does not guarantee a
> solution for 3rd party plugins that might be filtered out.

if going backwards means to not break compatibility with the previous release
then yes, it goes backwards.

> 
> So, Let's try to be clear about what's going on:
> 
> The regression introduced by c9209aef946b3 is that avdec_h264 is filter
> out in gstvideo_has_codec() and for that reason, for systems that do not
> have any other decoder, our caps for decoding h264 will be disabled,
> which is a regression.
> 
> To fix the issue in a way that follows the objective of current code, we
> should simply fix the filter as I've suggested at [0]. By the way, I
> went to the GStreamer folks about this filtering issue and I understood
> that my code in regard to the filtering is wrong due the assumption of
> what is a subset. That's a bug alright.
> 
> https://lists.freedesktop.org/archives/spice-devel/2017-July/038634.html
> 
> Pavel, you saying that patch is incorrect is wrong.

Victor, I cannot say it is correct when it does something incorrectly...

>  If you want, you can
> say _incomplete_, but that's a fix.
> 
> Incomplete you may say, because you think it is important to check for
> h264parse element. I'm not against that
Aren't you?

>  but I do think we, again, need
> to approach #gstreamer folks and check with them that we want a more
> robust check for enabling or not a streaming given a video-codec. If we
> go this way and checking for parses seem important, we should do it in a
> more generic fashion.
> 
> Again, I would go with my patch that fixes an issue and see from now on
> how to make our check more robust and I would not be surprise if there
> is no way to guarantee 100% that checking every single element in a
> pipeline would in fact decode a stream and that's because we don't have
> the parameters for the stream itself embedded in our protocol besides
> other issues that may occur.

Victor, it is checking for the elements used for GST < 1.9 (consider el7,
etc...)

> 
> So, yes, if you remove h264parse from registry, we will say that the
> stream can be decoded with avdec_h264 while it can't. I think that's a
> weak argument

Victor, you have used the same argument for my oneliner
https://lists.freedesktop.org/archives/spice-devel/2017-July/038629.html


>  in favor of your patch and as I'm saying a few times now,
> we should consider failure an option, fallback to image compression or
> different streams with different video-codec types

then you should remove the configure checks as well... (but it wasn't an
intention of your playbin series)

Have a nice day,
Pavel

>  if the fallback
> does not work, it is a bug even with your patch.
> 
> Cheers,
> 
> 
> > ---
> >  src/channel-display-gst.c | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > index 5042fc8..a9a044a 100644
> > --- a/src/channel-display-gst.c
> > +++ b/src/channel-display-gst.c
> > @@ -666,6 +666,31 @@ gboolean gstvideo_has_codec(int codec_type)
> >  codec_decoders = gst_element_factory_list_filter(all_decoders, caps,
> > GST_PAD_SINK, TRUE);
> >  gst_caps_unref(caps);
> >  
> > +/* Check for the presence of decoding elements that could be filter
> > out.
> > + * TODO: Improve filtering to avoid this...
> > + */
> > +{
> > +GList *decoder_elements = NU

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 18:00 +0200, Christophe Fergeau wrote:
> On Wed, Jul 19, 2017 at 05:46:51PM +0200, Victor Toso wrote:
> > What I'm trying to stress is that we are trying to not check *specific*
> > plugins related to decode/parse a stream. We don't know what our users
> > will be using and we should not enforce them to use avdec_h264 for
> > instance. You are doing this in this patch and that's why I'm against
> > it.
> 

Hi Christophe,

this patch is really not enforcing usage of any plugin. It's just making work
what used to work before c9209aef946b3ad517e7794d2e5648caf5ee2bf9. It does not
switch from GstCaps to checking by names. The checking by names is just an extra
addition to make sure that we don't forget about elements that could be filter
out due to *our* usage of GstCaps & gst_element_factory_list_filter()

> Yes, actually, on fedora you won't get avdec_h264 unless you enable RPM
> Fusion, and you might prefer to go the Cisco openh264 road instead
> ( https://ausil.us/wordpress/?p=126 - assuming this is still the
> recommended way to go with Workstation these days).

openh264 can be used only for WebRTC (at least for now). In general you need to
enable the 3rd party repo to get h246 - even for Cisco's openh264

https://fedoraproject.org/wiki/OpenH264

> So yeah my feeling
> would be to avoid hardcoding plugin names, assuming we can fallback
> properly if the decoding fails. 

we got this streaming features thanks to contribution from community, I don't
see a reason for breaking it and doing a release. Let's break (= improve) it
after that (removing configure checks for plugins, Victor's FIXME and my TODO).

> We could also try to make use of the
> 'missing-codec' GStreamer infrastructure if we want to get fancy.
> 
Yeah, that would be a nice RFE for a newcomer to learn about SPICE protocol.
Whether it is useful or annoying, it's a different question :)

Thanks,
Pavel

P.S.: In fact for gstreamer < 1.9 we should check for the plugin only by their
names (or by launching the pipeline). Because with the current approach it can
happen that an element for hw decoding is present (and the capability is
reported to the server) however a different (possibly missing sw decoding)
element is used in the gstreamer's decoding pipeline.


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

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 18:13 +0200, Victor Toso wrote:
> On Wed, Jul 19, 2017 at 06:01:43PM +0200, Pavel Grunt wrote:
> > On Wed, 2017-07-19 at 17:46 +0200, Victor Toso wrote:
> > > Hi,
> > > 
> > > On Wed, Jul 19, 2017 at 05:27:43PM +0200, Pavel Grunt wrote:
> > > > > Stream decoding will fail, server will know about it and sever should
> > > > > fallback to image compression or a different video codec format for
> > > > > streaming.
> > > > 
> > > > millions of criticals in the debug log and some resources wasted
> > > > (Server will keep trying to create streams - it does not know whether
> > > > it is a temporary issue or permanent).
> > > 
> > > With *host* creating the stream or are you testing something else? :)
> > 
> > Only the host (spice-server) creates the stream.
> > 
> > > 
> > > With the following diff, I can test an error in the pipeline which
> > > should remove the stream, see:
> > > 
> > > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > > index 3f51361..eb6a86b 100644
> > > --- a/src/channel-display-gst.c
> > > +++ b/src/channel-display-gst.c
> > > @@ -511,6 +511,9 @@ static gboolean
> > > spice_gst_decoder_queue_frame(VideoDecoder
> > > *video_decoder,
> > > return TRUE;
> > > }
> > > 
> > > +if (video_decoder->codec_type == SPICE_VIDEO_CODEC_TYPE_H264)
> > > +  return FALSE;
> > > +
> > >  if (spice_mmtime_diff(frame->mm_time, decoder->last_mm_time) < 0) {
> > >   SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
> > >" resetting stream",
> > > 
> > > channel-display.c:1241 display-2:0: display_handle_stream_create: id 49
> > > channel-display.c:1497 display-2:0: video latency: 350
> > > channel-display.c:1563 display-2:0: destroy_display_stream: id=49 #in-
> > > frames=1 
> > > out/in=1.00 #drops-on-receive=0 avg-late-time(ms)=0.00 #drops-on-
> > > playback=0
> > > spice-channel.c:2913 test cap 4 in 0x1052: yes report_invalid_stream:
> > > notify
> > > the server that stream 49 does not exist
> > > spice-channel.c:2913 test cap 4 in 0x1052: yes report_invalid_stream:
> > > notify
> > > the server that stream 49 does not exist
> > > 
> > > GSpice-CRITICAL **: display_handle_stream_data: assertion 'st != NULL'
> > > failed
> > > decode-glz.c:352 decode_header: 1920x946, id 51, ref 49
> > > decode-glz.c:352 decode_header: 1920x946, id 52, ref 50
> > > decode-glz.c:352 decode_header: 1920x946, id 53, ref 51
> > > decode-glz.c:352 decode_header: 1920x946, id 54, ref 52
> > > decode-glz.c:352 decode_header: 1920x946, id 55, ref 53
> > > 
> > > Just one critical, which is expected because we might have frames to
> > > decode while we already remove the decoder.
> > 
> > one critical per created stream, in case of youtube it may try to create
> > more
> > streams
> > > 
> > > > > 
> > > > > We cannot guarantee that the pipeline will work smooth in all systems,
> > > > > all possible combinations.
> > > > 
> > > > Victor, that is a different and unrelated issue
> > > 
> > > Its not, because your patch is trying to make avdec_h264 work because of
> > > h264parse and that means you are trying to guarantee h264 to succeed if
> > > this two elements are present
> > > 
> > 
> > no, I am trying to keep compatibility while not reporting 
> 
> Did not understand.. You are trying to fix a regression but only for
> avdec_h264 case while our code is more generic now...

Yes, I am trying to fix the regression and avoid future regressions just before
the release

> 
> > 
> > 
> > > > 
> > > > > 
> > > > > IMHO, we should improve debug log to provide the information of what
> > > > > is
> > > > > lacking on GStreamer point of view instead of trying to guarantee that
> > > > > it will work.
> > > > 
> > > > unrelated
> > > 
> > > It is unrelated.
> > > 
> > > > 
> > > > > 
> > > > > > >  You shouldn't do that in the
> > > > > > > first place.
> > > > > > > 
> > > > > > > My point is to ch

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 17:46 +0200, Victor Toso wrote:
> Hi,
> 
> On Wed, Jul 19, 2017 at 05:27:43PM +0200, Pavel Grunt wrote:
> > > Stream decoding will fail, server will know about it and sever should
> > > fallback to image compression or a different video codec format for
> > > streaming.
> > 
> > millions of criticals in the debug log and some resources wasted
> > (Server will keep trying to create streams - it does not know whether
> > it is a temporary issue or permanent).
> 
> With *host* creating the stream or are you testing something else? :)

Only the host (spice-server) creates the stream.

> 
> With the following diff, I can test an error in the pipeline which
> should remove the stream, see:
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 3f51361..eb6a86b 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -511,6 +511,9 @@ static gboolean spice_gst_decoder_queue_frame(VideoDecoder
> *video_decoder,
> return TRUE;
> }
> 
> +if (video_decoder->codec_type == SPICE_VIDEO_CODEC_TYPE_H264)
> +  return FALSE;
> +
>  if (spice_mmtime_diff(frame->mm_time, decoder->last_mm_time) < 0) {
>   SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>" resetting stream",
> 
> channel-display.c:1241 display-2:0: display_handle_stream_create: id 49
> channel-display.c:1497 display-2:0: video latency: 350
> channel-display.c:1563 display-2:0: destroy_display_stream: id=49 
> #in-frames=1 
> out/in=1.00 #drops-on-receive=0 avg-late-time(ms)=0.00 #drops-on-playback=0
> spice-channel.c:2913 test cap 4 in 0x1052: yes report_invalid_stream: notify
> the server that stream 49 does not exist
> spice-channel.c:2913 test cap 4 in 0x1052: yes report_invalid_stream: notify
> the server that stream 49 does not exist
> 
> GSpice-CRITICAL **: display_handle_stream_data: assertion 'st != NULL' failed
> decode-glz.c:352 decode_header: 1920x946, id 51, ref 49
> decode-glz.c:352 decode_header: 1920x946, id 52, ref 50
> decode-glz.c:352 decode_header: 1920x946, id 53, ref 51
> decode-glz.c:352 decode_header: 1920x946, id 54, ref 52
> decode-glz.c:352 decode_header: 1920x946, id 55, ref 53
> 
> Just one critical, which is expected because we might have frames to
> decode while we already remove the decoder.

one critical per created stream, in case of youtube it may try to create more
streams
> 
> > > 
> > > We cannot guarantee that the pipeline will work smooth in all systems,
> > > all possible combinations.
> > 
> > Victor, that is a different and unrelated issue
> 
> Its not, because your patch is trying to make avdec_h264 work because of
> h264parse and that means you are trying to guarantee h264 to succeed if
> this two elements are present
> 
no, I am trying to keep compatibility while not reporting 


> > 
> > > 
> > > IMHO, we should improve debug log to provide the information of what is
> > > lacking on GStreamer point of view instead of trying to guarantee that
> > > it will work.
> > 
> > unrelated
> 
> It is unrelated.
> 
> > 
> > > 
> > > > >  You shouldn't do that in the
> > > > > first place.
> > > > > 
> > > > > My point is to check for decoders only. If you want to check for
> > > > > parsers, this patch of yours will do it solely for hard coded
> > > > > elements.
> > > > 
> > > > This patch is just try to keep working what used to work in the
> > > > previous release and prevent breaking it for the next release (which
> > > > seems to happen soon).
> > > 
> > > My patch should work as well and possibly for other plugins like
> > > avdec_h264 that don't show up due bad filtering.
> > > 
> > 
> > Have you tested that? They are not working (I'm using playbin).
> 
> Have you checked the commit log of that patch?
Where do you mention testing of those plugins


> 
> > We do have the check for the same elements in configure, I really
> > don't understand what is wrong about doing the same check in runtime
> > (considerring TODO and keeping the compatibility with the last
> > release).
> > 
> > Pavel
> 
> What I'm trying to stress is that we are trying to not check *specific*
> plugins related to decode/parse a stream. We don't know what our users
> will be using and we should not enforce them to use avdec_h264 for
> instance.

I am not enforcing anything in this patch... 

>  You are d

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 16:43 +0200, Victor Toso wrote:
> Hi,
> 
> On Wed, Jul 19, 2017 at 04:25:19PM +0200, Pavel Grunt wrote:
> > On Wed, 2017-07-19 at 16:15 +0200, Victor Toso wrote:
> > > Hi,
> > > 
> > > On Wed, Jul 19, 2017 at 04:01:21PM +0200, Pavel Grunt wrote:
> > > > On Wed, 2017-07-19 at 15:52 +0200, Victor Toso wrote:
> > > > > On Wed, Jul 19, 2017 at 03:46:36PM +0200, Pavel Grunt wrote:
> > > > > > On Wed, 2017-07-19 at 15:40 +0200, Victor Toso wrote:
> > > > > > > On Wed, Jul 19, 2017 at 03:30:49PM +0200, Pavel Grunt wrote:
> > > > > > > > On Wed, 2017-07-19 at 15:23 +0200, Victor Toso wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > On Wed, Jul 19, 2017 at 02:59:00PM +0200, Pavel Grunt wrote:
> > > > > > > > > > GStreamer's avdec_h264 needs h264parse to be able to process
> > > > > > > > > > H264
> > > > > > > > > > video
> > > > > > > > > > streams. However the check for elements through GstRegistry
> > > > > > > > > > does
> > > > > > > > > > not
> > > > > > > > > > take into account the possible pipeline of elements (like
> > > > > > > > > > "h264parse
> > > > > > > > > > !
> > > > > > > > > > avdec_h264").
> > > > > > > > > > 
> > > > > > > > > > Fix that by checking for the elements by their name.
> > > > > > > > > 
> > > > > > > > > As I mentioned before, given the extra complexity that this is
> > > > > > > > > requiring, I'm not convinced that it is a good fix because it
> > > > > > > > > relies
> > > > > > > > > on
> > > > > > > > > the fact that we know the elements that we need (hard coded).
> > > > > > > > > 
> > > > > > > > > 1-) An user might have a different subset of plugins, like the
> > > > > > > > > fluendo
> > > > > > > > > ones or a different 3rd party ones. Do that work when we
> > > > > > > > > check
> > > > > > > > > for
> > > > > > > > > h264parse avdec_h264? I don't think so as it should be
> > > > > > > > > different
> > > > > > > > > plugins (one that people pay to have in their system)
> > > > > > > > 
> > > > > > > > This checks for presence of all the requirred plugins, for both
> > > > > > > > h264parse and avdec_h264. the user must have both to detect it.
> > > > > > > 
> > > > > > > I can have h264 stream decoded without avdec_h264 -> Not required
> > > > > > > 
> > > > > > > I _might_ _still_ have failures due lack of plugins on runtime
> > > > > > > even
> > > > > > > with
> > > > > > > h264parse -> Not enough
> > > > > > > 
> > > > > > > > It fixes the "regression" caused by the GstRegistry patch by
> > > > > > > > checking
> > > > > > > > for
> > > > > > > > the
> > > > > > > > elements like it was done before (but without parsing the full
> > > > > > > > pipeline)
> > > > > > > 
> > > > > > > It does fix for this case. I would prefer to be agnostic about
> > > > > > > plugins,
> > > > > > > really.
> > > > > > > 
> > > > > > > > > 
> > > > > > > > > 2-) If playbin just needs an extra plugin, we don't check it
> > > > > > > > > and
> > > > > > > > > that
> > > > > > > > > means the pipeline will fail even if the caps were
> > > > > > > > > enabled.
> > > > > > > > 
> > > > > > > > It is about the plugin combinations already tested in the past.
> > > > > > > > We
> > > > > > > > have
> >

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 16:15 +0200, Victor Toso wrote:
> Hi,
> 
> On Wed, Jul 19, 2017 at 04:01:21PM +0200, Pavel Grunt wrote:
> > On Wed, 2017-07-19 at 15:52 +0200, Victor Toso wrote:
> > > On Wed, Jul 19, 2017 at 03:46:36PM +0200, Pavel Grunt wrote:
> > > > On Wed, 2017-07-19 at 15:40 +0200, Victor Toso wrote:
> > > > > On Wed, Jul 19, 2017 at 03:30:49PM +0200, Pavel Grunt wrote:
> > > > > > On Wed, 2017-07-19 at 15:23 +0200, Victor Toso wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Wed, Jul 19, 2017 at 02:59:00PM +0200, Pavel Grunt wrote:
> > > > > > > > GStreamer's avdec_h264 needs h264parse to be able to process
> > > > > > > > H264
> > > > > > > > video
> > > > > > > > streams. However the check for elements through GstRegistry does
> > > > > > > > not
> > > > > > > > take into account the possible pipeline of elements (like
> > > > > > > > "h264parse
> > > > > > > > !
> > > > > > > > avdec_h264").
> > > > > > > > 
> > > > > > > > Fix that by checking for the elements by their name.
> > > > > > > 
> > > > > > > As I mentioned before, given the extra complexity that this is
> > > > > > > requiring, I'm not convinced that it is a good fix because it
> > > > > > > relies
> > > > > > > on
> > > > > > > the fact that we know the elements that we need (hard coded).
> > > > > > > 
> > > > > > > 1-) An user might have a different subset of plugins, like the
> > > > > > > fluendo
> > > > > > > ones or a different 3rd party ones. Do that work when we check
> > > > > > > for
> > > > > > > h264parse avdec_h264? I don't think so as it should be
> > > > > > > different
> > > > > > > plugins (one that people pay to have in their system)
> > > > > > 
> > > > > > This checks for presence of all the requirred plugins, for both
> > > > > > h264parse and avdec_h264. the user must have both to detect it.
> > > > > 
> > > > > I can have h264 stream decoded without avdec_h264 -> Not required
> > > > > 
> > > > > I _might_ _still_ have failures due lack of plugins on runtime even
> > > > > with
> > > > > h264parse -> Not enough
> > > > > 
> > > > > > It fixes the "regression" caused by the GstRegistry patch by
> > > > > > checking
> > > > > > for
> > > > > > the
> > > > > > elements like it was done before (but without parsing the full
> > > > > > pipeline)
> > > > > 
> > > > > It does fix for this case. I would prefer to be agnostic about
> > > > > plugins,
> > > > > really.
> > > > > 
> > > > > > > 
> > > > > > > 2-) If playbin just needs an extra plugin, we don't check it and
> > > > > > > that
> > > > > > > means the pipeline will fail even if the caps were enabled.
> > > > > > 
> > > > > > It is about the plugin combinations already tested in the past. We
> > > > > > have
> > > > > > their
> > > > > > name (and their usage in a pipeline) in the header file
> > > > > 
> > > > > That's correct but it doesn't mean that with playbin it'll be always
> > > > > correct as we are trying to increase the possibilities (i.e not depend
> > > > > solely on avdec_h264)
> > > > > 
> > > > > I don't think we will agree because you want to check for h264parse
> > > > > and
> > > > > that's one thing I want to avoid.
> > > > > 
> > > > 
> > > > I do the check for the plugins defined in the header, if you remove
> > > > h264parse
> > > > from the header, it won't check for it
> > > 
> > > Which would mean that [0] is much simpler, no?
> > > 
> > > [0] https://lists.freedesktop.org/archives/spice-devel/2017-July/038634.ht
> > > ml
> > > 
> > 
> > It is simple,

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 15:52 +0200, Victor Toso wrote:
> On Wed, Jul 19, 2017 at 03:46:36PM +0200, Pavel Grunt wrote:
> > On Wed, 2017-07-19 at 15:40 +0200, Victor Toso wrote:
> > > On Wed, Jul 19, 2017 at 03:30:49PM +0200, Pavel Grunt wrote:
> > > > On Wed, 2017-07-19 at 15:23 +0200, Victor Toso wrote:
> > > > > Hi,
> > > > > 
> > > > > On Wed, Jul 19, 2017 at 02:59:00PM +0200, Pavel Grunt wrote:
> > > > > > GStreamer's avdec_h264 needs h264parse to be able to process H264
> > > > > > video
> > > > > > streams. However the check for elements through GstRegistry does not
> > > > > > take into account the possible pipeline of elements (like "h264parse
> > > > > > !
> > > > > > avdec_h264").
> > > > > > 
> > > > > > Fix that by checking for the elements by their name.
> > > > > 
> > > > > As I mentioned before, given the extra complexity that this is
> > > > > requiring, I'm not convinced that it is a good fix because it relies
> > > > > on
> > > > > the fact that we know the elements that we need (hard coded).
> > > > > 
> > > > > 1-) An user might have a different subset of plugins, like the fluendo
> > > > > ones or a different 3rd party ones. Do that work when we check for
> > > > > h264parse avdec_h264? I don't think so as it should be different
> > > > > plugins (one that people pay to have in their system)
> > > > 
> > > > This checks for presence of all the requirred plugins, for both
> > > > h264parse and avdec_h264. the user must have both to detect it.
> > > 
> > > I can have h264 stream decoded without avdec_h264 -> Not required
> > > 
> > > I _might_ _still_ have failures due lack of plugins on runtime even with
> > > h264parse -> Not enough
> > > 
> > > > It fixes the "regression" caused by the GstRegistry patch by checking
> > > > for
> > > > the
> > > > elements like it was done before (but without parsing the full pipeline)
> > > 
> > > It does fix for this case. I would prefer to be agnostic about plugins,
> > > really.
> > > 
> > > > > 
> > > > > 2-) If playbin just needs an extra plugin, we don't check it and that
> > > > > means the pipeline will fail even if the caps were enabled.
> > > > 
> > > > It is about the plugin combinations already tested in the past. We have
> > > > their
> > > > name (and their usage in a pipeline) in the header file
> > > 
> > > That's correct but it doesn't mean that with playbin it'll be always
> > > correct as we are trying to increase the possibilities (i.e not depend
> > > solely on avdec_h264)
> > > 
> > > I don't think we will agree because you want to check for h264parse and
> > > that's one thing I want to avoid.
> > > 
> > 
> > I do the check for the plugins defined in the header, if you remove
> > h264parse
> > from the header, it won't check for it
> 
> Which would mean that [0] is much simpler, no?
> 
> [0] https://lists.freedesktop.org/archives/spice-devel/2017-July/038634.html
> 
It is simple, because it is incorrect. Remove h264parse and vaapi plugins and
keep avdec_h264, then try to connect to h264 streaming vm...


> > 
> > 
> > > > > 
> > > > > I do think the right approach is as I mentioned before, fix the
> > > > > filtering to show all decoders for h264 and that's it. If the pipeline
> > > > > fails, that's fine because it is *hard* to *ensure* that it'll work
> > > > > anyway without an actual video stream.
> > > > > 
> > > > > > ---
> > > > > >  src/channel-display-gst.c | 25 +
> > > > > >  1 file changed, 25 insertions(+)
> > > > > > 
> > > > > > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > > > > > index 5042fc8..a9a044a 100644
> > > > > > --- a/src/channel-display-gst.c
> > > > > > +++ b/src/channel-display-gst.c
> > > > > > @@ -666,6 +666,31 @@ gboolean gstvideo_has_codec(int codec_type)
> > > > > >  codec_decoders = gst_element_factory_list_filter(all_decoders,
> > > > > >

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 15:40 +0200, Victor Toso wrote:
> On Wed, Jul 19, 2017 at 03:30:49PM +0200, Pavel Grunt wrote:
> > On Wed, 2017-07-19 at 15:23 +0200, Victor Toso wrote:
> > > Hi,
> > > 
> > > On Wed, Jul 19, 2017 at 02:59:00PM +0200, Pavel Grunt wrote:
> > > > GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> > > > streams. However the check for elements through GstRegistry does not
> > > > take into account the possible pipeline of elements (like "h264parse !
> > > > avdec_h264").
> > > > 
> > > > Fix that by checking for the elements by their name.
> > > 
> > > As I mentioned before, given the extra complexity that this is
> > > requiring, I'm not convinced that it is a good fix because it relies on
> > > the fact that we know the elements that we need (hard coded).
> > > 
> > > 1-) An user might have a different subset of plugins, like the fluendo
> > > ones or a different 3rd party ones. Do that work when we check for
> > > h264parse avdec_h264? I don't think so as it should be different
> > > plugins (one that people pay to have in their system)
> > 
> > This checks for presence of all the requirred plugins, for both
> > h264parse and avdec_h264. the user must have both to detect it.
> 
> I can have h264 stream decoded without avdec_h264 -> Not required
> 
> I _might_ _still_ have failures due lack of plugins on runtime even with
> h264parse -> Not enough
> 
> > It fixes the "regression" caused by the GstRegistry patch by checking for
> > the
> > elements like it was done before (but without parsing the full pipeline)
> 
> It does fix for this case. I would prefer to be agnostic about plugins,
> really.
> 
> > > 
> > > 2-) If playbin just needs an extra plugin, we don't check it and that
> > > means the pipeline will fail even if the caps were enabled.
> > 
> > It is about the plugin combinations already tested in the past. We have
> > their
> > name (and their usage in a pipeline) in the header file
> 
> That's correct but it doesn't mean that with playbin it'll be always
> correct as we are trying to increase the possibilities (i.e not depend
> solely on avdec_h264)
> 
> I don't think we will agree because you want to check for h264parse and
> that's one thing I want to avoid.
> 
I do the check for the plugins defined in the header, if you remove h264parse
from the header, it won't check for it


> > > 
> > > I do think the right approach is as I mentioned before, fix the
> > > filtering to show all decoders for h264 and that's it. If the pipeline
> > > fails, that's fine because it is *hard* to *ensure* that it'll work
> > > anyway without an actual video stream.
> > > 
> > > > ---
> > > >  src/channel-display-gst.c | 25 +
> > > >  1 file changed, 25 insertions(+)
> > > > 
> > > > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > > > index 5042fc8..a9a044a 100644
> > > > --- a/src/channel-display-gst.c
> > > > +++ b/src/channel-display-gst.c
> > > > @@ -666,6 +666,31 @@ gboolean gstvideo_has_codec(int codec_type)
> > > >  codec_decoders = gst_element_factory_list_filter(all_decoders,
> > > > caps,
> > > > GST_PAD_SINK, TRUE);
> > > >  gst_caps_unref(caps);
> > > > 
> > > > +/* Check for the presence of decoding elements that could be filter
> > > > out.
> > > > + * TODO: Improve filtering to avoid this...
> > > > + */
> > > > +{
> > > > +GList *decoder_elements = NULL;
> > > > +gchar **decoders_by_names;
> > > > +guint i = 0;
> > > > +decoders_by_names = g_strsplit(gst_opts[codec_type].dec_name,
> > > > "!",
> > > > -1);
> > > > +for (i = 0; decoders_by_names[i] != NULL; i++) {
> > > > +GstElementFactory *element =
> > > > gst_element_factory_find(g_strstrip(decoders_by_names[i]));
> > > > +if (element == NULL) {
> > > > +gst_plugin_feature_list_free(decoder_elements);
> > > > +decoder_elements = NULL;
> > > > +break;
> > > > +}
> > > > +if (g_list_find(codec_decoders, element)) {
> > > > +gst_object_unref(eleme

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 15:23 +0200, Victor Toso wrote:
> Hi,
> 
> On Wed, Jul 19, 2017 at 02:59:00PM +0200, Pavel Grunt wrote:
> > GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> > streams. However the check for elements through GstRegistry does not
> > take into account the possible pipeline of elements (like "h264parse !
> > avdec_h264").
> > 
> > Fix that by checking for the elements by their name.
> 
> As I mentioned before, given the extra complexity that this is
> requiring, I'm not convinced that it is a good fix because it relies on
> the fact that we know the elements that we need (hard coded).
> 
> 1-) An user might have a different subset of plugins, like the fluendo
> ones or a different 3rd party ones. Do that work when we check for
> h264parse avdec_h264? I don't think so as it should be different
> plugins (one that people pay to have in their system)

This checks for presence of all the requirred plugins, for both h264parse and
avdec_h264. the user must have both to detect it.

It fixes the "regression" caused by the GstRegistry patch by checking for the
elements like it was done before (but without parsing the full pipeline)

> 
> 2-) If playbin just needs an extra plugin, we don't check it and that
> means the pipeline will fail even if the caps were enabled.

It is about the plugin combinations already tested in the past. We have their
name (and their usage in a pipeline) in the header file

> 
> I do think the right approach is as I mentioned before, fix the
> filtering to show all decoders for h264 and that's it. If the pipeline
> fails, that's fine because it is *hard* to *ensure* that it'll work
> anyway without an actual video stream.
> 
> > ---
> >  src/channel-display-gst.c | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > index 5042fc8..a9a044a 100644
> > --- a/src/channel-display-gst.c
> > +++ b/src/channel-display-gst.c
> > @@ -666,6 +666,31 @@ gboolean gstvideo_has_codec(int codec_type)
> >  codec_decoders = gst_element_factory_list_filter(all_decoders, caps,
> > GST_PAD_SINK, TRUE);
> >  gst_caps_unref(caps);
> > 
> > +/* Check for the presence of decoding elements that could be filter
> > out.
> > + * TODO: Improve filtering to avoid this...
> > + */
> > +{
> > +GList *decoder_elements = NULL;
> > +gchar **decoders_by_names;
> > +guint i = 0;
> > +decoders_by_names = g_strsplit(gst_opts[codec_type].dec_name, "!",
> > -1);
> > +for (i = 0; decoders_by_names[i] != NULL; i++) {
> > +GstElementFactory *element =
> > gst_element_factory_find(g_strstrip(decoders_by_names[i]));
> > +if (element == NULL) {
> > +gst_plugin_feature_list_free(decoder_elements);
> > +decoder_elements = NULL;
> > +break;
> > +}
> > +if (g_list_find(codec_decoders, element)) {
> > +gst_object_unref(element);
> > +} else {
> > +decoder_elements = g_list_append(decoder_elements,
> > element);
> > +}
> > +}
> > +codec_decoders = g_list_concat(codec_decoders, decoder_elements);
> > +g_strfreev(decoders_by_names);
> > +}
> > +
> >  if (codec_decoders == NULL) {
> >  spice_debug("From %u decoders, none can handle '%s'",
> >  g_list_length(all_decoders),
> > gst_opts[codec_type].dec_caps);
> > -- 
> > 2.13.3
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

GStreamer's avdec_h264 needs h264parse to be able to process H264 video
streams. However the check for elements through GstRegistry does not
take into account the possible pipeline of elements (like "h264parse ! 
avdec_h264").

Fix that by checking for the elements by their name.
---
 src/channel-display-gst.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 5042fc8..a9a044a 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -666,6 +666,31 @@ gboolean gstvideo_has_codec(int codec_type)
 codec_decoders = gst_element_factory_list_filter(all_decoders, caps, 
GST_PAD_SINK, TRUE);
 gst_caps_unref(caps);
 
+/* Check for the presence of decoding elements that could be filter out.
+ * TODO: Improve filtering to avoid this...
+ */
+{
+GList *decoder_elements = NULL;
+gchar **decoders_by_names;
+guint i = 0;
+decoders_by_names = g_strsplit(gst_opts[codec_type].dec_name, "!", -1);
+for (i = 0; decoders_by_names[i] != NULL; i++) {
+GstElementFactory *element = 
gst_element_factory_find(g_strstrip(decoders_by_names[i]));
+if (element == NULL) {
+gst_plugin_feature_list_free(decoder_elements);
+decoder_elements = NULL;
+break;
+}
+if (g_list_find(codec_decoders, element)) {
+gst_object_unref(element);
+} else {
+decoder_elements = g_list_append(decoder_elements, element);
+}
+}
+codec_decoders = g_list_concat(codec_decoders, decoder_elements);
+g_strfreev(decoders_by_names);
+}
+
 if (codec_decoders == NULL) {
 spice_debug("From %u decoders, none can handle '%s'",
 g_list_length(all_decoders), 
gst_opts[codec_type].dec_caps);
-- 
2.13.3

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

Re: [Spice-devel] [PATCH spice-gtk] gst-audio: Do not update mmtime without real audio channel

[Pavel Grunt]

On Tue, 2017-07-18 at 17:04 +0200, Christophe de Dinechin wrote:
> On 14 Jul 2017, at 14:27, Christophe de Dinechin <dinec...@redhat.com> wrote:
> > 
> > This looks better than my fix. Can’t ack right now (I did not build and test
> > it yet), but that looks like a reasonable approach
> > 
> > > On 14 Jul 2017, at 14:24, Pavel Grunt <pgr...@redhat.com> wrote:
> > > 
> > > This also fixes the huge memore leak reported by Christophe.
> > > Steps to reproduce:
> > > 1. ./configure --disable-pulse --enable-gstaudio
> > > 2. connect to a vm streaming video with no audio playing
> > > 3. see the memory grow really fast
> > > 
> > > It seems to be due to the fact that the "fake audio" channel updates the
> > > mmtime
> > > in a way that schedules the frames to the future ((unsigned) 0 - delay)
> > > and then
> > > gstreamer starts to queue the frames (they should be played later)
> > > 
> > > Pavel
> > > 
> > > On Fri, 2017-07-14 at 13:19 +0200, Pavel Grunt wrote:
> > > > The fake channel has been introduced to get the audio volume by starting
> > > > the gstreamer's audio pipeline and querring its volume info (see commit
> > > > aa8d044417bbf60685f59163b874ecb4f157c3c9).
> > > > 
> > > > Hovewer starting the pipeline updates the mmtime as a side effect. This
> > > > may cause a (big) delay in displaying a video stream.
> > > > 
> > > > Because the fake channel is only needed to get the volume info, make
> > > > sure to not update the mm-time with it.
> > > > 
> > > > Reported-by: Christophe de Dinechin <dinec...@redhat.com>
> > > > ---
> > > > src/spice-gstaudio.c | 11 +++
> > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/src/spice-gstaudio.c b/src/spice-gstaudio.c
> > > > index 014c3a5..715f824 100644
> > > > --- a/src/spice-gstaudio.c
> > > > +++ b/src/spice-gstaudio.c
> > > > @@ -38,6 +38,7 @@ struct stream {
> > > >GstElement  *sink;
> > > >guint   rate;
> > > >guint   channels;
> > > > +gbooleanfake; /* fake channel just for getting info
> > > > about
> > > > audio (volume) */
> > > > };
> > > > 
> > > > struct _SpiceGstaudioPrivate {
> > > > @@ -264,6 +265,8 @@ static gboolean update_mmtime_timeout_cb(gpointer
> > > > data)
> > > >SpiceGstaudioPrivate *p = gstaudio->priv;
> > > >GstQuery *q;
> > > > 
> > > > +g_return_val_if_fail(!p->playback.fake, TRUE);
> > > > +
> > > >q = gst_query_new_latency();
> > > >if (gst_element_query(p->playback.pipe, q)) {
> > > >gboolean live;
> > > > @@ -326,7 +329,7 @@ cleanup:
> > > >if (p->playback.pipe)
> > > >gst_element_set_state(p->playback.pipe, GST_STATE_PLAYING);
> > > > 
> > > > -if (p->mmtime_id == 0) {
> > > > +if (!p->playback.fake && p->mmtime_id == 0) {
> > > >update_mmtime_timeout_cb(gstaudio);
> > > >p->mmtime_id = g_timeout_add_seconds(1, update_mmtime_timeout_cb,
> > > > gstaudio);
> > > >}
> > > > @@ -569,7 +572,6 @@ static gboolean
> > > > spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
> > > >GstElement *e;
> > > >gboolean lmute;
> > > >gdouble vol;
> > > > -gboolean fake_channel = FALSE;
> > > >GTask *task = G_TASK(res);
> > > > 
> > > >g_return_val_if_fail(g_task_is_valid(task, audio), FALSE);
> > > > @@ -584,9 +586,9 @@ static gboolean
> > > > spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
> > > > 
> > > >if (p->playback.sink == NULL || p->playback.channels == 0) {
> > > >SPICE_DEBUG("PlaybackChannel not created yet, force start");
> > > > +p->playback.fake = TRUE;
> > > >/* In order to get system volume, we start the pipeline */
> > > >playback_start(NULL, SPICE_AUDIO_FMT_S16, 2, 48000, audio);
> > > > -fake_channel = TRUE;
> > > >}
> > > > 
> > > >if (GST_IS_BIN(p->playback.sink))
> > > > @@ -604,9 +606,10 @@ static gboolean
> > > > spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
> > > >}
> > > >g_object_unref(e);
> > > > 
> > > > -if (fake_channel) {
> > > > +if (p->playback.fake) {
> > > >SPICE_DEBUG("Stop faked PlaybackChannel");
> > > >playback_stop(SPICE_GSTAUDIO(audio));
> > > > +p->playback.fake = FALSE;
> > > >}
> > > > 
> > > >if (mute != NULL) {
> 
> This fixes the issue I was seeing with a black screen.

Does it fix the memory usage problem for you? it does for me.

Pavel

> 
> Acked-by: Christophe de Dinechin <dinec...@redhat.com>
> 
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk] build-sys: Lower gettext requirement

[Pavel Grunt]

On Mon, 2017-07-17 at 14:00 +0200, Christophe Fergeau wrote:
> spice-gtk currently requires gettext 0.19 which is a fairly recent
> release (not available in el7.3 and older, nor in ubuntu 14.04 LTS).
> They both have a gettext newer than 0.18.2, so we can require that.
> 
> Requiring 0.18 or 0.18.1 is throwing automake errors because of our use
> of -Werror, so we side-step this by requiring 0.18.2.
> 
> Signed-off-by: Christophe Fergeau 
> ---
>  configure.ac | 2 +-
>  spice-common | 2 +-

unrelated submodule update?

>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 61b01209..f915d81e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -16,7 +16,7 @@ AM_MAINTAINER_MODE
>  GETTEXT_PACKAGE=AC_PACKAGE_TARNAME
>  AC_SUBST(GETTEXT_PACKAGE)
>  AC_DEFINE_UNQUOTED([GETTEXT_PACKAGE], "$GETTEXT_PACKAGE", [GETTEXT package
> name])
> -AM_GNU_GETTEXT_VERSION([0.19])
> +AM_GNU_GETTEXT_VERSION([0.18.2])
>  AM_GNU_GETTEXT([external])
>  
>  
> diff --git a/spice-common b/spice-common
> index 858a0bfa..a76ed0ac 16
> --- a/spice-common
> +++ b/spice-common
> @@ -1 +1 @@
> -Subproject commit 858a0bfae9925ea6e363573de4113090c7821133
> +Subproject commit a76ed0ac73fd6b336825eefc71ae68857012f126

git show a76ed0ac73fd6b336825eefc71ae68857012f126
fatal: bad object a76ed0ac73fd6b336825eefc71ae68857012f126

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

Re: [Spice-devel] [spice-server PATCH 1/3] red_get_surface_cmd: avoid overflow

[Pavel Grunt]

On Sun, 2017-07-16 at 18:47 +0300, Uri Lublin wrote:
> Although unlikely, theoretically, multiplying two 32-bit
> numbers may overflow.
> 
> Found by coverity.
> 
> Signed-off-by: Uri Lublin <u...@redhat.com>
Acked-by: Pavel Grunt <pgr...@redhat.com>
> ---
>  server/red-parse-qxl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/server/red-parse-qxl.c b/server/red-parse-qxl.c
> index 33f36923a..0ffa5f7d4 100644
> --- a/server/red-parse-qxl.c
> +++ b/server/red-parse-qxl.c
> @@ -1397,7 +1397,7 @@ bool red_get_surface_cmd(RedMemSlotInfo *slots, int
> group_id,
>  return false;
>  }
>  
> -size = red->u.surface_create.height * abs(red-
> >u.surface_create.stride);
> +size = red->u.surface_create.height * (uint64_t)abs(red-
> >u.surface_create.stride);
>  red->u.surface_create.data =
>  (uint8_t*)memslot_get_virt(slots, qxl->u.surface_create.data,
> size, group_id, );
>  if (error) {
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-server PATCH 2/3] red_replay_image_free: do not free QUIC qxl twice

[Pavel Grunt]

On Sun, 2017-07-16 at 18:47 +0300, Uri Lublin wrote:
> If qxl->descriptor.type is QUIC, red_replay_data_chunks_free
> frees qxl (data), so no need to free it again at the bottom
> of the function.
> 
> Found by coverity.
> 
> Signed-off-by: Uri Lublin <u...@redhat.com>
Acked-by: Pavel Grunt <pgr...@redhat.com>
> ---
>  server/red-replay-qxl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/server/red-replay-qxl.c b/server/red-replay-qxl.c
> index 3c0f528bd..6172ed22e 100644
> --- a/server/red-replay-qxl.c
> +++ b/server/red-replay-qxl.c
> @@ -523,6 +523,7 @@ static void red_replay_image_free(SpiceReplay *replay,
> QXLPHYSICAL p, uint32_t f
>  break;
>  case SPICE_IMAGE_TYPE_QUIC:
>  red_replay_data_chunks_free(replay, qxl, 0);
> +qxl = NULL;
>  break;
>  default:
>  spice_warn_if_reached();
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-server PATCH 3/3] init ssl connection: return quickly if link is null

[Pavel Grunt]

On Sun, 2017-07-16 at 18:47 +0300, Uri Lublin wrote:
> Under error: 'link' fields are being accessed, so it's
> wrong to goto error with link == NULL.
> 
> Instead, return immediately.
> 
> Found by coverity.
> 
> Signed-off-by: Uri Lublin <u...@redhat.com>
Acked-by: Pavel Grunt <pgr...@redhat.com>
> ---
>  server/reds.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/server/reds.c b/server/reds.c
> index f412a8486..46d33fb5f 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -2462,7 +2462,7 @@ static RedLinkInfo
> *reds_init_client_ssl_connection(RedsState *reds, int socket)
>  
>  link = reds_init_client_connection(reds, socket);
>  if (link == NULL)
> -goto error;
> +return NULL;
>  
>  ssl_status = reds_stream_enable_ssl(link->stream, reds->ctx);
>  switch (ssl_status) {
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [vdagent-win PATCH v3 2/5] Initial rewrite of image conversion code

[Pavel Grunt]

On Fri, 2017-07-14 at 11:42 -0400, Frediano Ziglio wrote:
> > 
> > On Fri, 2017-07-14 at 13:57 +0100, Frediano Ziglio wrote:
> > > Remove CxImage linking.
> > > Support Windows BMP format.
> > > 
> > > Signed-off-by: Frediano Ziglio 
> > > ---
> > >  Makefile.am |   4 +-
> > >  configure.ac|   4 +-
> > >  mingw-spice-vdagent.spec.in |   2 -
> > >  vdagent/image.cpp   | 182
> > >  ++-
> > > -
> > >  vdagent/image.h |  13 
> > >  5 files changed, 159 insertions(+), 46 deletions(-)
> > > 
> > > diff --git a/Makefile.am b/Makefile.am
> > > index 868199e..b35dd57 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -23,8 +23,8 @@ LIBS = -lversion
> > >  
> > >  bin_PROGRAMS = vdagent vdservice
> > >  
> > > -vdagent_LDADD = -lwtsapi32 $(CXIMAGE_LIBS) vdagent_rc.$(OBJEXT)
> > > -vdagent_CXXFLAGS = $(AM_CXXFLAGS) $(CXIMAGE_CFLAGS)
> > > +vdagent_LDADD = -lwtsapi32 -lgdi32 vdagent_rc.$(OBJEXT)
> > > +vdagent_CXXFLAGS = $(AM_CXXFLAGS)
> > >  vdagent_LDFLAGS = $(AM_LDFLAGS) -Wl,--subsystem,windows
> > >  vdagent_SOURCES =\
> > >   common/vdcommon.cpp \
> > > diff --git a/configure.ac b/configure.ac
> > > index ff489cc..4eac4b4 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -42,6 +42,7 @@ AC_DEFINE_UNQUOTED([BUILD_YEAR], "$BUILD_YEAR", [Build
> > > year])
> > >  # Check for programs
> > >  AC_PROG_CC
> > >  AC_PROG_CXX
> > > +AX_CXX_COMPILE_STDCXX_11
> > >  AM_PROG_CC_C_O
> > >  AC_PROG_INSTALL
> > >  AC_CHECK_TOOL(WINDRES, [windres])
> > > @@ -100,9 +101,6 @@ dnl
> > > --
> > > -
> > >  dnl - Check library dependencies
> > >  dnl
> > >  ---
> > > 
> > >  
> > > -PKG_CHECK_MODULES(CXIMAGE, [cximage])
> > > -CXIMAGE_LIBS=`$PKG_CONFIG --static --libs cximage`
> > > -
> > >  dnl
> > >  ---
> > > 
> > >  dnl - Makefiles, etc.
> > >  dnl
> > >  ---
> > > 
> > > diff --git a/mingw-spice-vdagent.spec.in b/mingw-spice-vdagent.spec.in
> > > index 563341d..8cfd01a 100644
> > > --- a/mingw-spice-vdagent.spec.in
> > > +++ b/mingw-spice-vdagent.spec.in
> > > @@ -13,8 +13,6 @@ Source0:vdagent-win-
> > > %{version}%{?_version_suffix}.tar.xz
> > >  
> > >  BuildRequires:  mingw32-filesystem >= 23
> > >  BuildRequires:  mingw64-filesystem >= 23
> > > -BuildRequires:  mingw32-cximage-static
> > > -BuildRequires:  mingw64-cximage-static
> > >  BuildRequires:  mingw32-jasper-static
> > >  BuildRequires:  mingw64-jasper-static
> > >  BuildRequires:  mingw32-libjpeg-turbo-static
> > > diff --git a/vdagent/image.cpp b/vdagent/image.cpp
> > > index 598a742..6f7608d 100644
> > > --- a/vdagent/image.cpp
> > > +++ b/vdagent/image.cpp
> > > @@ -16,71 +16,175 @@
> > >  */
> > >  
> > >  #include 
> > > +#include 
> > > +#include 
> > >  
> > >  #include "vdcommon.h"
> > >  #include "image.h"
> > >  
> > > -#include "ximage.h"
> > > +ImageCoder *create_bitmap_coder();
> > > +ImageCoder *create_png_coder();
> > >  
> > > -typedef struct ImageType {
> > > -uint32_t type;
> > > -DWORD cximage_format;
> > > -} ImageType;
> > > -
> > > -static const ImageType image_types[] = {
> > > -{VD_AGENT_CLIPBOARD_IMAGE_PNG, CXIMAGE_FORMAT_PNG},
> > > -{VD_AGENT_CLIPBOARD_IMAGE_BMP, CXIMAGE_FORMAT_BMP},
> > > -};
> > > -
> > > -static DWORD get_cximage_format(uint32_t type)
> > > +static ImageCoder *get_coder(uint32_t vdagent_type)
> > >  {
> > > -for (unsigned int i = 0; i < SPICE_N_ELEMENTS(image_types); i++) {
> > > -if (image_types[i].type == type) {
> > > -return image_types[i].cximage_format;
> > > -}
> > > +switch (vdagent_type) {
> > > +case VD_AGENT_CLIPBOARD_IMAGE_BMP:
> > > +return create_bitmap_coder();
> > > +case VD_AGENT_CLIPBOARD_IMAGE_PNG:
> > > +return create_png_coder();
> > >  }
> > > -return 0;
> > > +return NULL;
> > >  }
> > >  
> > >  HANDLE get_image_handle(const VDAgentClipboard& clipboard, uint32_t size,
> > > UINT )
> > >  {
> > > -HANDLE clip_data;
> > > -DWORD cximage_format = get_cximage_format(clipboard.type);
> > > -ASSERT(cximage_format);
> > > -CxImage image((BYTE*)clipboard.data, size, cximage_format);
> > > -clip_data = image.CopyToHandle();
> > > +std::unique_ptr coder(get_coder(clipboard.type));
> > > +if (!coder) {
> > > +return NULL;
> > > +}
> > > +
> > > +format = CF_DIB;
> > 
> > so it is just an output parameter (and always set to CF_DIB)
> > 
> 
> Currently only CF_DIB is used. But potentially other clipboard types
> can be used for images.
> 
> > > +size_t dib_size = coder->get_dib_size(clipboard.data, size);
> > 

Re: [Spice-devel] [vdagent-win PATCH v3 2/5] Initial rewrite of image conversion code

[Pavel Grunt]

On Fri, 2017-07-14 at 13:57 +0100, Frediano Ziglio wrote:
> Remove CxImage linking.
> Support Windows BMP format.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  Makefile.am |   4 +-
>  configure.ac|   4 +-
>  mingw-spice-vdagent.spec.in |   2 -
>  vdagent/image.cpp   | 182 ++-
> -
>  vdagent/image.h |  13 
>  5 files changed, 159 insertions(+), 46 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 868199e..b35dd57 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -23,8 +23,8 @@ LIBS = -lversion
>  
>  bin_PROGRAMS = vdagent vdservice
>  
> -vdagent_LDADD = -lwtsapi32 $(CXIMAGE_LIBS) vdagent_rc.$(OBJEXT)
> -vdagent_CXXFLAGS = $(AM_CXXFLAGS) $(CXIMAGE_CFLAGS)
> +vdagent_LDADD = -lwtsapi32 -lgdi32 vdagent_rc.$(OBJEXT)
> +vdagent_CXXFLAGS = $(AM_CXXFLAGS)
>  vdagent_LDFLAGS = $(AM_LDFLAGS) -Wl,--subsystem,windows
>  vdagent_SOURCES =\
>   common/vdcommon.cpp \
> diff --git a/configure.ac b/configure.ac
> index ff489cc..4eac4b4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -42,6 +42,7 @@ AC_DEFINE_UNQUOTED([BUILD_YEAR], "$BUILD_YEAR", [Build
> year])
>  # Check for programs
>  AC_PROG_CC
>  AC_PROG_CXX
> +AX_CXX_COMPILE_STDCXX_11
>  AM_PROG_CC_C_O
>  AC_PROG_INSTALL
>  AC_CHECK_TOOL(WINDRES, [windres])
> @@ -100,9 +101,6 @@ dnl --
> -
>  dnl - Check library dependencies
>  dnl ---
> 
>  
> -PKG_CHECK_MODULES(CXIMAGE, [cximage])
> -CXIMAGE_LIBS=`$PKG_CONFIG --static --libs cximage`
> -
>  dnl ---
> 
>  dnl - Makefiles, etc.
>  dnl ---
> 
> diff --git a/mingw-spice-vdagent.spec.in b/mingw-spice-vdagent.spec.in
> index 563341d..8cfd01a 100644
> --- a/mingw-spice-vdagent.spec.in
> +++ b/mingw-spice-vdagent.spec.in
> @@ -13,8 +13,6 @@ Source0:vdagent-win-
> %{version}%{?_version_suffix}.tar.xz
>  
>  BuildRequires:  mingw32-filesystem >= 23
>  BuildRequires:  mingw64-filesystem >= 23
> -BuildRequires:  mingw32-cximage-static
> -BuildRequires:  mingw64-cximage-static
>  BuildRequires:  mingw32-jasper-static
>  BuildRequires:  mingw64-jasper-static
>  BuildRequires:  mingw32-libjpeg-turbo-static
> diff --git a/vdagent/image.cpp b/vdagent/image.cpp
> index 598a742..6f7608d 100644
> --- a/vdagent/image.cpp
> +++ b/vdagent/image.cpp
> @@ -16,71 +16,175 @@
>  */
>  
>  #include 
> +#include 
> +#include 
>  
>  #include "vdcommon.h"
>  #include "image.h"
>  
> -#include "ximage.h"
> +ImageCoder *create_bitmap_coder();
> +ImageCoder *create_png_coder();
>  
> -typedef struct ImageType {
> -uint32_t type;
> -DWORD cximage_format;
> -} ImageType;
> -
> -static const ImageType image_types[] = {
> -{VD_AGENT_CLIPBOARD_IMAGE_PNG, CXIMAGE_FORMAT_PNG},
> -{VD_AGENT_CLIPBOARD_IMAGE_BMP, CXIMAGE_FORMAT_BMP},
> -};
> -
> -static DWORD get_cximage_format(uint32_t type)
> +static ImageCoder *get_coder(uint32_t vdagent_type)
>  {
> -for (unsigned int i = 0; i < SPICE_N_ELEMENTS(image_types); i++) {
> -if (image_types[i].type == type) {
> -return image_types[i].cximage_format;
> -}
> +switch (vdagent_type) {
> +case VD_AGENT_CLIPBOARD_IMAGE_BMP:
> +return create_bitmap_coder();
> +case VD_AGENT_CLIPBOARD_IMAGE_PNG:
> +return create_png_coder();
>  }
> -return 0;
> +return NULL;
>  }
>  
>  HANDLE get_image_handle(const VDAgentClipboard& clipboard, uint32_t size,
> UINT )
>  {
> -HANDLE clip_data;
> -DWORD cximage_format = get_cximage_format(clipboard.type);
> -ASSERT(cximage_format);
> -CxImage image((BYTE*)clipboard.data, size, cximage_format);
> -clip_data = image.CopyToHandle();
> +std::unique_ptr coder(get_coder(clipboard.type));
> +if (!coder) {
> +return NULL;
> +}
> +
> +format = CF_DIB;

so it is just an output parameter (and always set to CF_DIB)

> +size_t dib_size = coder->get_dib_size(clipboard.data, size);
> +if (!dib_size) {
> +return NULL;
> +}
> +HANDLE clip_data = GlobalAlloc(GMEM_MOVEABLE, dib_size);
> +if (clip_data) {
> +uint8_t* dst = (uint8_t*)GlobalLock(clip_data);
> +if (!dst) {
> +GlobalFree(clip_data);
> +return NULL;
> +}
> +coder->get_dib_data(dst, clipboard.data, size);
> +GlobalUnlock(clip_data);
> +}
>  return clip_data;
>  }
>  
>  uint8_t* get_raw_clipboard_image(const VDAgentClipboardRequest&
> clipboard_request,
>   HANDLE clip_data, long& new_size)
>  {
> -CxImage image;
> -uint8_t *new_data = NULL;
> -DWORD cximage_format = get_cximage_format(clipboard_request.type);

Re: [Spice-devel] [vdagent-win PATCH v3 1/5] Move image handling to a separate file

[Pavel Grunt]

On Fri, 2017-07-14 at 13:57 +0100, Frediano Ziglio wrote:
> This will make easier to change code that handle images.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  Makefile.am |  2 ++
>  vdagent/image.cpp   | 86
> +
>  vdagent/image.h | 48 ++
>  vdagent/vdagent.cpp | 57 +--
>  4 files changed, 144 insertions(+), 49 deletions(-)
>  create mode 100644 vdagent/image.cpp
>  create mode 100644 vdagent/image.h
> 
> diff --git a/Makefile.am b/Makefile.am
> index b60a718..868199e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -42,6 +42,8 @@ vdagent_SOURCES =   \
>   vdagent/vdagent.cpp \
>   vdagent/as_user.cpp \
>   vdagent/as_user.h   \
> + vdagent/image.cpp   \
> + vdagent/image.h \
>   $(NULL)
>  
>  vdagent_rc.$(OBJEXT): vdagent/vdagent.rc
> diff --git a/vdagent/image.cpp b/vdagent/image.cpp
> new file mode 100644
> index 000..598a742
> --- /dev/null
> +++ b/vdagent/image.cpp
> @@ -0,0 +1,86 @@
> +/*
> +   Copyright (C) 2013-2017 Red Hat, Inc.
> +
> +   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 2 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 .
> +*/
> +
> +#include 
> +
> +#include "vdcommon.h"
> +#include "image.h"
> +
> +#include "ximage.h"
> +
> +typedef struct ImageType {
> +uint32_t type;
> +DWORD cximage_format;
> +} ImageType;
> +
> +static const ImageType image_types[] = {
> +{VD_AGENT_CLIPBOARD_IMAGE_PNG, CXIMAGE_FORMAT_PNG},
> +{VD_AGENT_CLIPBOARD_IMAGE_BMP, CXIMAGE_FORMAT_BMP},
> +};
> +
> +static DWORD get_cximage_format(uint32_t type)
> +{
> +for (unsigned int i = 0; i < SPICE_N_ELEMENTS(image_types); i++) {
> +if (image_types[i].type == type) {
> +return image_types[i].cximage_format;
> +}
> +}
> +return 0;
> +}
> +
> +HANDLE get_image_handle(const VDAgentClipboard& clipboard, uint32_t size,
> UINT )
> +{
> +HANDLE clip_data;
> +DWORD cximage_format = get_cximage_format(clipboard.type);
> +ASSERT(cximage_format);
> +CxImage image((BYTE*)clipboard.data, size, cximage_format);
> +clip_data = image.CopyToHandle();
> +return clip_data;
> +}
> +
> +uint8_t* get_raw_clipboard_image(const VDAgentClipboardRequest&
> clipboard_request,
> + HANDLE clip_data, long& new_size)
> +{
> +CxImage image;
> +uint8_t *new_data = NULL;
> +DWORD cximage_format = get_cximage_format(clipboard_request.type);
> +HPALETTE pal = 0;

I'd suggest to set new_size to zero to match the documentation (size of returned
data)

> +
> +ASSERT(cximage_format);
> +if (IsClipboardFormatAvailable(CF_PALETTE)) {
> +pal = (HPALETTE)GetClipboardData(CF_PALETTE);
> +}
> +if (!image.CreateFromHBITMAP((HBITMAP)clip_data, pal)) {
> +vd_printf("Image create from handle failed");
> +return NULL;
> +}
> +if (!image.Encode(new_data, new_size, cximage_format)) {
> +vd_printf("Image encode to type %u failed", clipboard_request.type);
> +return NULL;
> +}
> +vd_printf("Image encoded to %lu bytes", new_size);
> +return new_data;
> +}
> +
> +void free_raw_clipboard_image(uint8_t *data)
> +{
> +// this is really just a free however is better to make
> +// the free from CxImage code as on Windows the free
> +// can be different between libraries
> +CxImage image;
> +image.FreeMemory(data);
> +}
> diff --git a/vdagent/image.h b/vdagent/image.h
> new file mode 100644
> index 000..379c5cc
> --- /dev/null
> +++ b/vdagent/image.h
> @@ -0,0 +1,48 @@
> +/*
> +   Copyright (C) 2013-2017 Red Hat, Inc.
> +
> +   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 2 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 

Re: [Spice-devel] [PATCH spice-gtk] gst-audio: Do not update mmtime without real audio channel

[Pavel Grunt]

This also fixes the huge memore leak reported by Christophe.
Steps to reproduce:
1. ./configure --disable-pulse --enable-gstaudio
2. connect to a vm streaming video with no audio playing
3. see the memory grow really fast

It seems to be due to the fact that the "fake audio" channel updates the mmtime
in a way that schedules the frames to the future ((unsigned) 0 - delay) and then
gstreamer starts to queue the frames (they should be played later)

Pavel

On Fri, 2017-07-14 at 13:19 +0200, Pavel Grunt wrote:
> The fake channel has been introduced to get the audio volume by starting
> the gstreamer's audio pipeline and querring its volume info (see commit
> aa8d044417bbf60685f59163b874ecb4f157c3c9).
> 
> Hovewer starting the pipeline updates the mmtime as a side effect. This
> may cause a (big) delay in displaying a video stream.
> 
> Because the fake channel is only needed to get the volume info, make
> sure to not update the mm-time with it.
> 
> Reported-by: Christophe de Dinechin <dinec...@redhat.com>
> ---
>  src/spice-gstaudio.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/src/spice-gstaudio.c b/src/spice-gstaudio.c
> index 014c3a5..715f824 100644
> --- a/src/spice-gstaudio.c
> +++ b/src/spice-gstaudio.c
> @@ -38,6 +38,7 @@ struct stream {
>  GstElement  *sink;
>  guint   rate;
>  guint   channels;
> +gbooleanfake; /* fake channel just for getting info about
> audio (volume) */
>  };
>  
>  struct _SpiceGstaudioPrivate {
> @@ -264,6 +265,8 @@ static gboolean update_mmtime_timeout_cb(gpointer data)
>  SpiceGstaudioPrivate *p = gstaudio->priv;
>  GstQuery *q;
>  
> +g_return_val_if_fail(!p->playback.fake, TRUE);
> +
>  q = gst_query_new_latency();
>  if (gst_element_query(p->playback.pipe, q)) {
>  gboolean live;
> @@ -326,7 +329,7 @@ cleanup:
>  if (p->playback.pipe)
>  gst_element_set_state(p->playback.pipe, GST_STATE_PLAYING);
>  
> -if (p->mmtime_id == 0) {
> +if (!p->playback.fake && p->mmtime_id == 0) {
>  update_mmtime_timeout_cb(gstaudio);
>  p->mmtime_id = g_timeout_add_seconds(1, update_mmtime_timeout_cb,
> gstaudio);
>  }
> @@ -569,7 +572,6 @@ static gboolean
> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>  GstElement *e;
>  gboolean lmute;
>  gdouble vol;
> -gboolean fake_channel = FALSE;
>  GTask *task = G_TASK(res);
>  
>  g_return_val_if_fail(g_task_is_valid(task, audio), FALSE);
> @@ -584,9 +586,9 @@ static gboolean
> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>  
>  if (p->playback.sink == NULL || p->playback.channels == 0) {
>  SPICE_DEBUG("PlaybackChannel not created yet, force start");
> +p->playback.fake = TRUE;
>  /* In order to get system volume, we start the pipeline */
>  playback_start(NULL, SPICE_AUDIO_FMT_S16, 2, 48000, audio);
> -fake_channel = TRUE;
>  }
>  
>  if (GST_IS_BIN(p->playback.sink))
> @@ -604,9 +606,10 @@ static gboolean
> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>  }
>  g_object_unref(e);
>  
> -if (fake_channel) {
> +if (p->playback.fake) {
>  SPICE_DEBUG("Stop faked PlaybackChannel");
>  playback_stop(SPICE_GSTAUDIO(audio));
> +p->playback.fake = FALSE;
>  }
>  
>  if (mute != NULL) {
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Do not update .po files with ./autogen.sh && make

[Pavel Grunt]

It is enough to update them just before the release (`make dist`)

Reported-by: Victor Toso 
---
also remove a intltool leftover
---
 Makefile.am | 1 -
 po/Makevars | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 30f05f4..ccb81aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -32,7 +32,6 @@ EXTRA_DIST =  \
build-aux/git-version-gen   \
gtk-doc.make\
.version\
-   $(INTLTOOL_FILES)   \
$(NULL)
 
 MAINTAINERCLEANFILES = \
diff --git a/po/Makevars b/po/Makevars
index 1359b7a..78f708e 100644
--- a/po/Makevars
+++ b/po/Makevars
@@ -86,7 +86,7 @@ MSGINIT_OPTIONS =
 # has changed.  Possible values are "yes" and "no".  Set this to no if
 # the POT file is checked in the repository and the version control
 # program ignores timestamps.
-PO_DEPENDS_ON_POT = yes
+PO_DEPENDS_ON_POT = no
 
 # This tells whether or not to forcibly update $(DOMAIN).pot and
 # regenerate PO files on "make dist".  Possible values are "yes" and
-- 
2.13.3

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

Re: [Spice-devel] [PATCH spice-gtk] Fix occasional black screen at startup

[Pavel Grunt]

On Thu, 2017-07-13 at 18:44 +0200, Christophe de Dinechin wrote:
> From: Christophe de Dinechin 
> 
> The problem occurs when we call spice_playback_channel_set_delay before
> the channel had received any data setting c->last_time,

Interesting bug... setting the delay of the playback before the playback starts


>  but after
> session initialization had set mm_time in the session. The result was
> that the (good) value in session->mm_time would be overwritten with 0.
> 
> Signed-off-by: Christophe de Dinechin 
> ---
>  src/channel-playback.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/channel-playback.c b/src/channel-playback.c
> index ca14b96..f5acf23 100644
> --- a/src/channel-playback.c
> +++ b/src/channel-playback.c
> @@ -471,7 +471,8 @@ void spice_playback_channel_set_delay(SpicePlaybackChannel
> *channel, guint32 del
>  
>  session = spice_channel_get_session(SPICE_CHANNEL(channel));
>  if (session) {
> -spice_session_set_mm_time(session, c->last_time - delay_ms);
> +if (c->last_time != 0)
> +spice_session_set_mm_time(session, c->last_time - delay_ms);
>  } else {
>  CHANNEL_DEBUG(channel, "channel detached from session, mm time
> skipped");
>  }
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] gst: Fix build for GStreamer < 1.5.1

[Pavel Grunt]

GST_DEBUG_GRAPH_SHOW_FULL_PARAMS is available since that
---
 src/channel-display-gst.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 87e472c..fcb9e25 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -297,7 +297,9 @@ static gboolean handle_pipeline_message(GstBus *bus, 
GstMessage *msg, gpointer v
   
gst_opts[decoder->base.codec_type].name);
 GST_DEBUG_BIN_TO_DOT_FILE(GST_BIN(decoder->pipeline),
   GST_DEBUG_GRAPH_SHOW_ALL
+#if GST_CHECK_VERSION(1,5,1)
 | GST_DEBUG_GRAPH_SHOW_FULL_PARAMS
+#endif
 | GST_DEBUG_GRAPH_SHOW_STATES,
 filename);
 g_free(filename);
-- 
2.13.0

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

Re: [Spice-devel] [spice-gtk v1] display-gst: Improve h264 elements filtering

[Pavel Grunt]

On Thu, 2017-07-13 at 14:33 +0200, Victor Toso wrote:
> From: Victor Toso 
> 
> This patch fixes the avdec_h264 element not being present on
> gstvideo_has_codec() which get all decoder elements from GstRegistry
> and filter them on our GstCaps in order to get the ones for given
> codec.
> 
> The issue is around the filtering. The current GstCaps for h264 is not
> consider a subset of avdec_h264's capabilites and that will fiter this
> element out of the list.
> 
> The proposed solution for that is to set `subsetonly` parameter from
> gst_element_factory_list_filter() to false.

that is incorrect for the same reason as my patch (some required element plugin
may be missing)

> 
> While at it, the cap "stream-format=byte-stream" is less useful now
> because it isn't needed to play the stream - see 6fe88871240c53b8
> 
> In my system, our debug shows:
> .. gstvideo_debug_available_decoders: From 228 video decoder elements,
> - 4 can handle caps   image/jpeg: jpegdec, nvdec, avdec_mjpeg, vaapijpegdec

like here a parser for avdec_mjpeg

> - 3 can handle caps  video/x-vp8: vaapidecodebin, vp8dec, avdec_vp8
> - 4 can handle caps video/x-h264: vaapidecodebin, avdec_h264, nvdec,
> vaapih264dec
> - 3 can handle caps  video/x-vp9: vaapidecodebin, vp9dec, avdec_vp9
> 
> Signed-off-by: Victor Toso 
> ---
>  src/channel-display-gst.c  | 2 +-
>  src/channel-display-priv.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 20d236a..1bd7df1 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -647,7 +647,7 @@ gboolean gstvideo_has_codec(int codec_type)
>  }
>  
>  caps = gst_caps_from_string(gst_opts[codec_type].dec_caps);
> -codec_decoders = gst_element_factory_list_filter(all_decoders, caps,
> GST_PAD_SINK, TRUE);
> +codec_decoders = gst_element_factory_list_filter(all_decoders, caps,
> GST_PAD_SINK, FALSE);
>  gst_caps_unref(caps);
>  
>  if (codec_decoders == NULL) {
> diff --git a/src/channel-display-priv.h b/src/channel-display-priv.h
> index 04cb4d1..9bfd4ac 100644
> --- a/src/channel-display-priv.h
> +++ b/src/channel-display-priv.h
> @@ -181,7 +181,7 @@ static const struct {
>   * (hardcoded in spice-server), let's add it here to avoid the warning.
>   */
>  { SPICE_DISPLAY_CAP_CODEC_H264, "h264",
> -  "h264parse ! avdec_h264", "video/x-h264,stream-format=byte-stream" },
> +  "h264parse ! avdec_h264", "video/x-h264" },
>  
>  /* SPICE_VIDEO_CODEC_TYPE_VP9 */
>  { SPICE_DISPLAY_CAP_CODEC_VP9, "vp9",
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Thu, 2017-07-13 at 13:22 +0200, Victor Toso wrote:
> Hi,
> 
> On Thu, Jul 13, 2017 at 01:18:14PM +0200, Pavel Grunt wrote:
> > On Thu, 2017-07-13 at 13:11 +0200, Victor Toso wrote:
> > > On Thu, Jul 13, 2017 at 01:05:31PM +0200, Pavel Grunt wrote:
> > > > GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> > > > streams. However the check for elements through GstRegistry forgot to
> > > > include the parsers, thus making spice-gtk to not set the relevant cap
> > > > to inform the server about H264 decoding capability.
> > > 
> > > Wouldn't that make it possible to find a parser but not a decoder and
> > > evaluate the _has_codec() to true?
> > 
> > yes, it would
> > 
> > so it must be a check for parsers and then searching for decoders accepting
> > the
> > parser(s)'s output
> 
> Not really, avdec_h264 should show when we list the decoders.

it should not, the caps we set are not a subset of avdec_h264 caps.
Documentation of GstCaps may not be clear, but take a look at tests. Basically
"video/x-raw" is the superset for "video/x-raw, format=(string)YUY2".

Pavel


> 
> > 
> > Pavel
> > > > ---
> > > >  src/channel-display-gst.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > > > index 54edd6b..d883d9f 100644
> > > > --- a/src/channel-display-gst.c
> > > > +++ b/src/channel-display-gst.c
> > > > @@ -652,6 +652,7 @@ gboolean gstvideo_has_codec(int codec_type)
> > > >  g_return_val_if_fail(VALID_VIDEO_CODEC_TYPE(codec_type), FALSE);
> > > >  
> > > >  type = GST_ELEMENT_FACTORY_TYPE_DECODER |
> > > > +   GST_ELEMENT_FACTORY_TYPE_PARSER |
> > > > GST_ELEMENT_FACTORY_TYPE_MEDIA_VIDEO |
> > > > GST_ELEMENT_FACTORY_TYPE_MEDIA_IMAGE;
> > > >  all_decoders = gst_element_factory_list_get_elements(type,
> > > > GST_RANK_NONE);
> > > > -- 
> > > > 2.13.0
> > > > 
> > > > ___
> > > > Spice-devel mailing list
> > > > Spice-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Thu, 2017-07-13 at 13:11 +0200, Victor Toso wrote:
> On Thu, Jul 13, 2017 at 01:05:31PM +0200, Pavel Grunt wrote:
> > GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> > streams. However the check for elements through GstRegistry forgot to
> > include the parsers, thus making spice-gtk to not set the relevant cap
> > to inform the server about H264 decoding capability.
> 
> Wouldn't that make it possible to find a parser but not a decoder and
> evaluate the _has_codec() to true?
yes, it would

so it must be a check for parsers and then searching for decoders accepting the
parser(s)'s output

Pavel
> > ---
> >  src/channel-display-gst.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > index 54edd6b..d883d9f 100644
> > --- a/src/channel-display-gst.c
> > +++ b/src/channel-display-gst.c
> > @@ -652,6 +652,7 @@ gboolean gstvideo_has_codec(int codec_type)
> >  g_return_val_if_fail(VALID_VIDEO_CODEC_TYPE(codec_type), FALSE);
> >  
> >  type = GST_ELEMENT_FACTORY_TYPE_DECODER |
> > +   GST_ELEMENT_FACTORY_TYPE_PARSER |
> > GST_ELEMENT_FACTORY_TYPE_MEDIA_VIDEO |
> > GST_ELEMENT_FACTORY_TYPE_MEDIA_IMAGE;
> >  all_decoders = gst_element_factory_list_get_elements(type,
> > GST_RANK_NONE);
> > -- 
> > 2.13.0
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

GStreamer's avdec_h264 needs h264parse to be able to process H264 video
streams. However the check for elements through GstRegistry forgot to
include the parsers, thus making spice-gtk to not set the relevant cap
to inform the server about H264 decoding capability.
---
 src/channel-display-gst.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 54edd6b..d883d9f 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -652,6 +652,7 @@ gboolean gstvideo_has_codec(int codec_type)
 g_return_val_if_fail(VALID_VIDEO_CODEC_TYPE(codec_type), FALSE);
 
 type = GST_ELEMENT_FACTORY_TYPE_DECODER |
+   GST_ELEMENT_FACTORY_TYPE_PARSER |
GST_ELEMENT_FACTORY_TYPE_MEDIA_VIDEO |
GST_ELEMENT_FACTORY_TYPE_MEDIA_IMAGE;
 all_decoders = gst_element_factory_list_get_elements(type, GST_RANK_NONE);
-- 
2.13.0

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

[Spice-devel] [PATCH spice-gtk v3] Make error messages translatable

[Pavel Grunt]

Signed-off-by: Victor Toso <victort...@redhat.com>
Signed-off-by: Pavel Grunt <pgr...@redhat.com>
---
 po/POTFILES.in | 13 +
 src/channel-main.c | 15 ++-
 src/channel-port.c |  4 +++-
 src/channel-usbredir.c |  8 
 src/giopipe.c  |  7 +--
 src/smartcard-manager.c|  5 +++--
 src/spice-channel.c|  2 +-
 src/spice-client-glib-usb-acl-helper.c |  2 +-
 src/spice-file-transfer-task.c |  6 --
 src/spice-pulse.c  |  8 +---
 src/spice-session.c|  2 +-
 src/spice-uri.c| 17 ++---
 src/spice-widget-egl.c | 23 ---
 src/usb-acl-helper.c   |  9 +
 src/usb-device-manager.c   |  6 +++---
 src/vmcstream.c|  3 ++-
 src/win-usb-dev.c  |  8 
 src/wocky-http-proxy.c | 11 ++-
 18 files changed, 92 insertions(+), 57 deletions(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index d1033f9..7a744af 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,9 +1,22 @@
 src/channel-main.c
+src/channel-port.c
 src/channel-usbredir.c
 src/desktop-integration.c
+src/giopipe.c
+src/smartcard-manager.c
 src/spice-channel.c
+src/spice-client-glib-usb-acl-helper.c
+src/spice-file-transfer-task.c
 src/spice-option.c
+src/spice-pulse.c
+src/spice-session.c
+src/spice-uri.c
+src/spice-widget-egl.c
+src/usb-acl-helper.c
 src/usb-device-manager.c
 src/usb-device-widget.c
 src/usbutil.c
+src/vmcstream.c
+src/win-usb-dev.c
+src/wocky-http-proxy.c
 tools/spice-cmdline.c
diff --git a/src/channel-main.c b/src/channel-main.c
index 4edd575..c035ce1 100644
--- a/src/channel-main.c
+++ b/src/channel-main.c
@@ -17,6 +17,7 @@
 */
 #include "config.h"
 
+#include 
 #include 
 #include 
 #include 
@@ -1900,7 +1901,7 @@ static void 
main_agent_handle_xfer_status(SpiceMainChannel *channel,
 default:
 g_warn_if_reached();
 error = g_error_new(SPICE_CLIENT_ERROR, SPICE_CLIENT_ERROR_FAILED,
-"unhandled status type: %u", msg->result);
+_("unhandled status type: %u"), msg->result);
 break;
 }
 
@@ -2906,12 +2907,16 @@ failed:
 
 static void file_transfer_operation_free(FileTransferOperation *xfer_op)
 {
+const char *error_summary_fmt;
 g_return_if_fail(xfer_op != NULL);
 
+error_summary_fmt = ngettext(_("Transferring %u file: %u succeed, %u 
cancelled, %u failed"),
+ _("Transferring %u files: %u succeed, %u 
cancelled, %u failed"),
+ xfer_op->stats.num_files);
 if (xfer_op->stats.failed != 0) {
 GError *error = g_error_new(SPICE_CLIENT_ERROR,
 SPICE_CLIENT_ERROR_FAILED,
-"Transferring %u files: %u succeed, %u 
cancelled, %u failed",
+error_summary_fmt,
 xfer_op->stats.num_files,
 xfer_op->stats.succeed,
 xfer_op->stats.cancelled,
@@ -2921,7 +2926,7 @@ static void 
file_transfer_operation_free(FileTransferOperation *xfer_op)
 } else if (xfer_op->stats.cancelled != 0 && xfer_op->stats.succeed == 0) {
 GError *error = g_error_new(G_IO_ERROR,
 G_IO_ERROR_CANCELLED,
-"Transferring %u files: %u succeed, %u 
cancelled, %u failed",
+error_summary_fmt,
 xfer_op->stats.num_files,
 xfer_op->stats.succeed,
 xfer_op->stats.cancelled,
@@ -2962,7 +2967,7 @@ static void 
spice_main_channel_reset_all_xfer_operations(SpiceMainChannel *chann
 }
 
 error = g_error_new(SPICE_CLIENT_ERROR, SPICE_CLIENT_ERROR_FAILED,
-"Agent connection closed");
+_("Agent connection closed"));
 spice_file_transfer_task_completed(xfer_task, error);
 }
 g_list_free(keys);
@@ -3119,7 +3124,7 @@ void spice_main_file_copy_async(SpiceMainChannel *channel,
 spice_main_file_copy_async,
 SPICE_CLIENT_ERROR,
 SPICE_CLIENT_ERROR_FAILED,
-"The agent is not connected");
+_("The agent is not connected"));
 return;
 }
 
diff --git a/src/channel-port.c b/src/channel-port.c
index d922e4b..

Re: [Spice-devel] [spice-gtk v2 2/2] file-xfer: Inform client of errors on init of xfer

[Pavel Grunt]

On Tue, 2017-07-11 at 12:42 +0200, Victor Toso wrote:
> From: Victor Toso <m...@victortoso.com>
> 
> With SpiceFileTransferTask we suggest that Spice clients watch
> (signal) SpiceMainChannel::new-file-transfer so they can follow the
> transfer's progress till the moment it is finished.
> 
> The signal SpiceFileTransferTask::finished informs if an error happens
> to the application.
> 
> This patch solves the problem of SpiceFileTransferTask::finished not
> being emitted when the agent is not connected nor when file-transfer
> is disabled in the host.
> 
> We should first emit SpiceMainChannel::new-file-transfer followed up
> by SpiceFileTransferTask::finished, which is done by the function
> spice_file_transfer_task_completed().
> 
> As channel-main chains up the "finish" signal by removing the
> SpiceFileTransferTask from its GHashTable, we have to change from
> GHashTableIter to a simple GList of keys.
> 
> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1373830
> Signed-off-by: Victor Toso <victort...@redhat.com>
Acked-by: Pavel Grunt <pgr...@redhat.com>
> ---
>  src/channel-main.c | 50 ++
>  1 file changed, 22 insertions(+), 28 deletions(-)
> 
> diff --git a/src/channel-main.c b/src/channel-main.c
> index 68ec62e..17f9122 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -3103,9 +3103,9 @@ void spice_main_file_copy_async(SpiceMainChannel
> *channel,
>  gpointer user_data)
>  {
>  SpiceMainChannelPrivate *c;
> -GHashTableIter iter;
> -gpointer key, value;
>  FileTransferOperation *xfer_op;
> +GError *error = NULL;
> +GList *it, *keys;
>  
>  g_return_if_fail(channel != NULL);
>  g_return_if_fail(SPICE_IS_MAIN_CHANNEL(channel));
> @@ -3113,25 +3113,13 @@ void spice_main_file_copy_async(SpiceMainChannel
> *channel,
>  
>  c = channel->priv;
>  if (!c->agent_connected) {
> -g_task_report_new_error(channel,
> -callback,
> -user_data,
> -spice_main_file_copy_async,
> -SPICE_CLIENT_ERROR,
> -SPICE_CLIENT_ERROR_FAILED,
> -_("The agent is not connected"));
> -return;
> -}
> -
> -if (test_agent_cap(channel, VD_AGENT_CAP_FILE_XFER_DISABLED)) {
> -g_task_report_new_error(channel,
> -callback,
> -user_data,
> -spice_main_file_copy_async,
> -SPICE_CLIENT_ERROR,
> -SPICE_CLIENT_ERROR_FAILED,
> -_("The file transfer is disabled"));
> -return;
> +error = g_error_new(SPICE_CLIENT_ERROR,
> +SPICE_CLIENT_ERROR_FAILED,
> +_("The agent is not connected"));
> +} else if (test_agent_cap(channel, VD_AGENT_CAP_FILE_XFER_DISABLED)) {
> +error = g_error_new(SPICE_CLIENT_ERROR,
> +SPICE_CLIENT_ERROR_FAILED,
> +_("The file transfer is disabled"));
>  }
>  
>  xfer_op = g_new0(FileTransferOperation, 1);
> @@ -3144,23 +3132,29 @@ void spice_main_file_copy_async(SpiceMainChannel
> *channel,
> flags,
> cancellable);
>  xfer_op->stats.num_files = g_hash_table_size(xfer_op->xfer_task);
> -g_hash_table_iter_init(, xfer_op->xfer_task);
> -while (g_hash_table_iter_next(, , )) {
> +keys = g_hash_table_get_keys(xfer_op->xfer_task);
> +for (it = keys; it != NULL; it = it->next) {
>  guint32 task_id;
> -SpiceFileTransferTask *xfer_task = value;
> +SpiceFileTransferTask *xfer_task = g_hash_table_lookup(xfer_op-
> >xfer_task, it->data);
>  
>  task_id = spice_file_transfer_task_get_id(xfer_task);
>  
>  SPICE_DEBUG("Insert a xfer task:%u to task list", task_id);
>  
> -g_hash_table_insert(c->file_xfer_tasks, key, xfer_op);
> +g_hash_table_insert(c->file_xfer_tasks, it->data, xfer_op);
>  g_signal_connect(xfer_task, "finished",
> G_CALLBACK(file_transfer_operation_task_finished), NULL);
>  g_signal_emit(channel, signals[SPICE_MAIN_NEW_FILE_TRANSFER], 0,
> xfer_task);
>  
> -spice_file_tra

Re: [Spice-devel] [PATCH spice-gtk 2/2] file-xfer: Inform client of errors on init of xfer

[Pavel Grunt]

Hi,

On Mon, 2017-07-03 at 15:28 +0200, Victor Toso wrote:
> From: Victor Toso 
> 
> With SpiceFileTransferTask we suggest that Spice clients watch
> (signal) SpiceMainChannel::new-file-transfer so it can follow the
... so they can..
> transfer's progress till the moment it is finished.
> 
> On (signal) SpiceFileTransferTask::finished, we will issue if any
> error has happened to the application.

imo this sentence is hard to read. What about:
 The signal SpiceFileTransferTask::finished informs if an error happens to the
application


> 
> This patch solves the problem of SpiceFileTransferTask::finished not
> being emitted when the agent is not connected nor when file-transfer
> is disabled in the host.
> 
> We should fist emit SpiceMainChannel::new-file-transfer followed up by
first

> SpiceFileTransferTask::finished, which is done by the function
> spice_file_transfer_task_completed().
> 
> As channel-main chains up the "finish" signal by removing the
> SpiceFileTransferTask from its GHashTable, we have to change from
> GHashTableIter to a simple GList of keys.
okay
> 
> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1373830
> Signed-off-by: Victor Toso 
> ---
>  src/channel-main.c | 50 ++
>  1 file changed, 22 insertions(+), 28 deletions(-)
> 
> diff --git a/src/channel-main.c b/src/channel-main.c
> index 1c77c7b..0140d5b 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -3103,9 +3103,9 @@ void spice_main_file_copy_async(SpiceMainChannel
> *channel,
>  gpointer user_data)
>  {
>  SpiceMainChannelPrivate *c;
> -GHashTableIter iter;
> -gpointer key, value;
>  FileTransferOperation *xfer_op;
> +GError *error = NULL;
> +GList *it, *keys;
>  
>  g_return_if_fail(channel != NULL);
>  g_return_if_fail(SPICE_IS_MAIN_CHANNEL(channel));
> @@ -3113,25 +3113,13 @@ void spice_main_file_copy_async(SpiceMainChannel
> *channel,
>  
>  c = channel->priv;
>  if (!c->agent_connected) {
> -g_task_report_new_error(channel,
> -callback,
> -user_data,
> -spice_main_file_copy_async,
> -SPICE_CLIENT_ERROR,
> -SPICE_CLIENT_ERROR_FAILED,
> -_("The agent is not connected"));
> -return;
> -}
> -
> -if (test_agent_cap(channel, VD_AGENT_CAP_FILE_XFER_DISABLED)) {
> -g_task_report_new_error(channel,
> -callback,
> -user_data,
> -spice_main_file_copy_async,
> -SPICE_CLIENT_ERROR,
> -SPICE_CLIENT_ERROR_FAILED,
> -_("The file transfer is disabled"));
> -return;
> +error = g_error_new(SPICE_CLIENT_ERROR,
> +SPICE_CLIENT_ERROR_FAILED,
> +_("The agent is not connected"));
> +} else if (test_agent_cap(channel, VD_AGENT_CAP_FILE_XFER_DISABLED)) {
> +error = g_error_new(SPICE_CLIENT_ERROR,
> +SPICE_CLIENT_ERROR_FAILED,
> +_("The file transfer is disabled"));
>  }
>  
>  xfer_op = g_new0(FileTransferOperation, 1);
> @@ -3144,23 +3132,29 @@ void spice_main_file_copy_async(SpiceMainChannel
> *channel,
> flags,
> cancellable);
>  xfer_op->stats.num_files = g_hash_table_size(xfer_op->xfer_task);
> -g_hash_table_iter_init(, xfer_op->xfer_task);
> -while (g_hash_table_iter_next(, , )) {
> +keys = g_hash_table_get_keys(xfer_op->xfer_task);
> +for (it = keys; it != NULL; it = it->next) {
>  guint32 task_id;
> -SpiceFileTransferTask *xfer_task = value;
> +SpiceFileTransferTask *xfer_task = g_hash_table_lookup(xfer_op-
> >xfer_task, it->data);
>  
>  task_id = spice_file_transfer_task_get_id(xfer_task);
>  
>  SPICE_DEBUG("Insert a xfer task:%u to task list", task_id);
>  
> -g_hash_table_insert(c->file_xfer_tasks, key, xfer_op);
> +g_hash_table_insert(c->file_xfer_tasks, it->data, xfer_op);
>  g_signal_connect(xfer_task, "finished",
> G_CALLBACK(file_transfer_operation_task_finished), NULL);
>  g_signal_emit(channel, signals[SPICE_MAIN_NEW_FILE_TRANSFER], 0,
> xfer_task);
>  
> -spice_file_transfer_task_init_task_async(xfer_task,
> - file_xfer_init_task_async_cb
> ,
> - xfer_op);
> +if (error == NULL) {
> +spice_file_transfer_task_init_task_async(xfer_task,
> +

[Spice-devel] [PATCH spice-gtk v2] Make error messages translatable

[Pavel Grunt]

---
v2:
 - Use ngettext for error messages in plural
 - rebased on top of Victor's patch
---
 po/POTFILES.in | 4 
 src/channel-main.c | 9 +++--
 src/channel-port.c | 4 +++-
 src/channel-usbredir.c | 2 +-
 src/smartcard-manager.c| 5 +++--
 src/spice-channel.c| 2 +-
 src/spice-file-transfer-task.c | 6 --
 src/spice-pulse.c  | 4 +++-
 8 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index d1033f9..5f438b5 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,8 +1,12 @@
 src/channel-main.c
+src/channel-port.c
 src/channel-usbredir.c
 src/desktop-integration.c
+src/smartcard-manager.c
 src/spice-channel.c
+src/spice-file-transfer-task.c
 src/spice-option.c
+src/spice-pulse.c
 src/usb-device-manager.c
 src/usb-device-widget.c
 src/usbutil.c
diff --git a/src/channel-main.c b/src/channel-main.c
index 68ec62e..c035ce1 100644
--- a/src/channel-main.c
+++ b/src/channel-main.c
@@ -17,6 +17,7 @@
 */
 #include "config.h"
 
+#include 
 #include 
 #include 
 #include 
@@ -2906,12 +2907,16 @@ failed:
 
 static void file_transfer_operation_free(FileTransferOperation *xfer_op)
 {
+const char *error_summary_fmt;
 g_return_if_fail(xfer_op != NULL);
 
+error_summary_fmt = ngettext(_("Transferring %u file: %u succeed, %u 
cancelled, %u failed"),
+ _("Transferring %u files: %u succeed, %u 
cancelled, %u failed"),
+ xfer_op->stats.num_files);
 if (xfer_op->stats.failed != 0) {
 GError *error = g_error_new(SPICE_CLIENT_ERROR,
 SPICE_CLIENT_ERROR_FAILED,
-_("Transferring %u files: %u succeed, %u 
cancelled, %u failed"),
+error_summary_fmt,
 xfer_op->stats.num_files,
 xfer_op->stats.succeed,
 xfer_op->stats.cancelled,
@@ -2921,7 +2926,7 @@ static void 
file_transfer_operation_free(FileTransferOperation *xfer_op)
 } else if (xfer_op->stats.cancelled != 0 && xfer_op->stats.succeed == 0) {
 GError *error = g_error_new(G_IO_ERROR,
 G_IO_ERROR_CANCELLED,
-_("Transferring %u files: %u succeed, %u 
cancelled, %u failed"),
+error_summary_fmt,
 xfer_op->stats.num_files,
 xfer_op->stats.succeed,
 xfer_op->stats.cancelled,
diff --git a/src/channel-port.c b/src/channel-port.c
index d922e4b..9fb7f05 100644
--- a/src/channel-port.c
+++ b/src/channel-port.c
@@ -17,6 +17,8 @@
 */
 #include "config.h"
 
+#include 
+
 #include "spice-client.h"
 #include "spice-common.h"
 #include "spice-channel-priv.h"
@@ -294,7 +296,7 @@ void spice_port_write_async(SpicePortChannel *self,
 g_task_report_new_error(self, callback,
 user_data, spice_port_write_async,
 SPICE_CLIENT_ERROR, SPICE_CLIENT_ERROR_FAILED,
-"The port is not opened");
+_("The port is not opened"));
 return;
 }
 
diff --git a/src/channel-usbredir.c b/src/channel-usbredir.c
index fef62ce..f8a5234 100644
--- a/src/channel-usbredir.c
+++ b/src/channel-usbredir.c
@@ -348,7 +348,7 @@ static void spice_usbredir_channel_open_acl_cb(
 spice_usb_acl_helper_open_acl_finish(acl_helper, acl_res, );
 if (!err && priv->state == STATE_DISCONNECTING) {
 err = g_error_new_literal(G_IO_ERROR, G_IO_ERROR_CANCELLED,
-  "USB redirection channel connect cancelled");
+  _("USB redirection channel connect 
cancelled"));
 }
 if (!err) {
 spice_usbredir_channel_open_device(channel, );
diff --git a/src/smartcard-manager.c b/src/smartcard-manager.c
index 708f976..05e113d 100644
--- a/src/smartcard-manager.c
+++ b/src/smartcard-manager.c
@@ -18,6 +18,7 @@
 #include "config.h"
 
 #include 
+#include 
 #include 
 
 #ifdef USE_SMARTCARD_012
@@ -439,7 +440,7 @@ static gboolean 
smartcard_manager_init(SmartcardManagerInitArgs *args)
 if (options == NULL) {
 args->err = g_error_new(SPICE_CLIENT_ERROR,
 SPICE_CLIENT_ERROR_FAILED,
-"vcard_emul_options() failed!");
+_("vcard_emul_options() failed!"));
 goto end;
 }
 
@@ -453,7 +454,7 @@ init:
 && (emul_init_status != VCARD_EMUL_INIT_ALREADY_INITED)) {
 args->err = g_error_new(SPICE_CLIENT_ERROR,
 SPICE_CLIENT_ERROR_FAILED,
-"Failed to initialize smartcard");
+_("Failed to initialize smartcard"));
 goto end;
 }
 
diff 

Re: [Spice-devel] Recording the screen output of a spice channel

[Pavel Grunt]

On Tue, 2017-07-11 at 08:12 +0100, André Rodier wrote:
> Hello Victor.
> Thank you for your prompt answer. I will see what we can do.

Hi,
you can use a tool `recordmydesktop` to record windows of an application. Take a
look at its man page, it has several examples of usage (you can give it an id of
the window, or coordinates & dimensions)

Pavel

> Kind regards,
> André.
> 
> On 11 Jul 2017 07:22, "Victor Toso"  wrote:
> > Hi André,
> > 
> > On Tue, Jul 11, 2017 at 07:12:08AM +0100, André Rodier wrote:
> > > Hello everyone,
> > >
> > > I am using Spice on Debian Stretch, with libvirt. I need to record the
> > > screens of the virtual machines, in MPEG4.
> > >
> > > I wondered if there is a solution to record the screen output of a spice
> > > channel, and to convert it to MP4.
> > 
> > Something like this is desirable but not implemented yet, see:
> > https://bugs.freedesktop.org/show_bug.cgi?id=51714
> > 
> > >
> > > I know there is already a package to transcode a VNC channel to SWF, but
> > > I would rather use some standard like MPEG4, OGG Theora, etc.
> > >
> > > Kind regards,
> > > André
> > 
> > Cheers,
> > toso
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] usb-manager: Fix docstring annotation

[Pavel Grunt]

---
 src/usb-device-manager.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/usb-device-manager.c b/src/usb-device-manager.c
index bbe2391..dfac5a0 100644
--- a/src/usb-device-manager.c
+++ b/src/usb-device-manager.c
@@ -635,9 +635,9 @@ static void 
spice_usb_device_manager_class_init(SpiceUsbDeviceManagerClass *klas
 pspec);
 
 /**
- * SpiceUsbDeviceManager:n-free-channels:
+ * SpiceUsbDeviceManager:free-channels:
  *
- * Get a list of avaialable channels for redirecting USB devices.
+ * Get a number of available channels for redirecting USB devices.
  *
  * Since: 0.31
  */
-- 
2.13.0

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

Re: [Spice-devel] [spice-gtk v2] file-xfer: Error messages should always be translated

[Pavel Grunt]

On Tue, 2017-07-11 at 08:05 +0200, Pavel Grunt wrote:
> On Mon, 2017-07-10 at 17:57 +0200, Victor Toso wrote:
> > From: Victor Toso <m...@victortoso.com>
> > 
> > Signed-off-by: Victor Toso <victort...@redhat.com>
> 
> Acked-by: Pavel Grunt <pgr...@redhat.com>

I forgot about a patch (acked) about this /o\

The comment about ngettext is still valid
 https://lists.freedesktop.org/archives/spice-devel/2017-March/036783.html



> > ---
> >  src/channel-main.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/src/channel-main.c b/src/channel-main.c
> > index 4edd575..68ec62e 100644
> > --- a/src/channel-main.c
> > +++ b/src/channel-main.c
> > @@ -1900,7 +1900,7 @@ static void
> > main_agent_handle_xfer_status(SpiceMainChannel *channel,
> >  default:
> >  g_warn_if_reached();
> >  error = g_error_new(SPICE_CLIENT_ERROR, SPICE_CLIENT_ERROR_FAILED,
> > -"unhandled status type: %u", msg->result);
> > +_("unhandled status type: %u"), msg->result);
> >  break;
> >  }
> >  
> > @@ -2911,7 +2911,7 @@ static void
> > file_transfer_operation_free(FileTransferOperation *xfer_op)
> >  if (xfer_op->stats.failed != 0) {
> >  GError *error = g_error_new(SPICE_CLIENT_ERROR,
> >  SPICE_CLIENT_ERROR_FAILED,
> > -"Transferring %u files: %u succeed, %u
> > cancelled, %u failed",
> > +_("Transferring %u files: %u succeed,
> > %u
> > cancelled, %u failed"),
> >  xfer_op->stats.num_files,
> >  xfer_op->stats.succeed,
> >  xfer_op->stats.cancelled,
> > @@ -2921,7 +2921,7 @@ static void
> > file_transfer_operation_free(FileTransferOperation *xfer_op)
> >  } else if (xfer_op->stats.cancelled != 0 && xfer_op->stats.succeed ==
> > 0)
> > {
> >  GError *error = g_error_new(G_IO_ERROR,
> >  G_IO_ERROR_CANCELLED,
> > -"Transferring %u files: %u succeed, %u
> > cancelled, %u failed",
> > +_("Transferring %u files: %u succeed,
> > %u
> > cancelled, %u failed"),
> >  xfer_op->stats.num_files,
> >  xfer_op->stats.succeed,
> >  xfer_op->stats.cancelled,
> > @@ -2962,7 +2962,7 @@ static void
> > spice_main_channel_reset_all_xfer_operations(SpiceMainChannel *chann
> >  }
> >  
> >  error = g_error_new(SPICE_CLIENT_ERROR, SPICE_CLIENT_ERROR_FAILED,
> > -"Agent connection closed");
> > +_("Agent connection closed"));
> >  spice_file_transfer_task_completed(xfer_task, error);
> >  }
> >  g_list_free(keys);
> > @@ -3119,7 +3119,7 @@ void spice_main_file_copy_async(SpiceMainChannel
> > *channel,
> >  spice_main_file_copy_async,
> >  SPICE_CLIENT_ERROR,
> >  SPICE_CLIENT_ERROR_FAILED,
> > -"The agent is not connected");
> > +_("The agent is not connected"));
> >  return;
> >  }
> >  
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v2] file-xfer: Error messages should always be translated

[Pavel Grunt]

On Mon, 2017-07-10 at 17:57 +0200, Victor Toso wrote:
> From: Victor Toso <m...@victortoso.com>
> 
> Signed-off-by: Victor Toso <victort...@redhat.com>
Acked-by: Pavel Grunt <pgr...@redhat.com>
> ---
>  src/channel-main.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/src/channel-main.c b/src/channel-main.c
> index 4edd575..68ec62e 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -1900,7 +1900,7 @@ static void
> main_agent_handle_xfer_status(SpiceMainChannel *channel,
>  default:
>  g_warn_if_reached();
>  error = g_error_new(SPICE_CLIENT_ERROR, SPICE_CLIENT_ERROR_FAILED,
> -"unhandled status type: %u", msg->result);
> +_("unhandled status type: %u"), msg->result);
>  break;
>  }
>  
> @@ -2911,7 +2911,7 @@ static void
> file_transfer_operation_free(FileTransferOperation *xfer_op)
>  if (xfer_op->stats.failed != 0) {
>  GError *error = g_error_new(SPICE_CLIENT_ERROR,
>  SPICE_CLIENT_ERROR_FAILED,
> -"Transferring %u files: %u succeed, %u
> cancelled, %u failed",
> +_("Transferring %u files: %u succeed, %u
> cancelled, %u failed"),
>  xfer_op->stats.num_files,
>  xfer_op->stats.succeed,
>  xfer_op->stats.cancelled,
> @@ -2921,7 +2921,7 @@ static void
> file_transfer_operation_free(FileTransferOperation *xfer_op)
>  } else if (xfer_op->stats.cancelled != 0 && xfer_op->stats.succeed == 0)
> {
>  GError *error = g_error_new(G_IO_ERROR,
>  G_IO_ERROR_CANCELLED,
> -"Transferring %u files: %u succeed, %u
> cancelled, %u failed",
> +_("Transferring %u files: %u succeed, %u
> cancelled, %u failed"),
>  xfer_op->stats.num_files,
>  xfer_op->stats.succeed,
>  xfer_op->stats.cancelled,
> @@ -2962,7 +2962,7 @@ static void
> spice_main_channel_reset_all_xfer_operations(SpiceMainChannel *chann
>  }
>  
>  error = g_error_new(SPICE_CLIENT_ERROR, SPICE_CLIENT_ERROR_FAILED,
> -"Agent connection closed");
> +_("Agent connection closed"));
>  spice_file_transfer_task_completed(xfer_task, error);
>  }
>  g_list_free(keys);
> @@ -3119,7 +3119,7 @@ void spice_main_file_copy_async(SpiceMainChannel
> *channel,
>  spice_main_file_copy_async,
>  SPICE_CLIENT_ERROR,
>  SPICE_CLIENT_ERROR_FAILED,
> -"The agent is not connected");
> +_("The agent is not connected"));
>  return;
>  }
>  
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk 1/2] file-xfer: Error messages should always be translated

[Pavel Grunt]

On Mon, 2017-07-03 at 15:28 +0200, Victor Toso wrote:
> From: Victor Toso 
> 
There are more untranslated error messages in the channel-main.c related to
file-xfer (search for g_error_new)

> Signed-off-by: Victor Toso 
> ---
>  src/channel-main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/channel-main.c b/src/channel-main.c
> index 4edd575..1c77c7b 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -3119,7 +3119,7 @@ void spice_main_file_copy_async(SpiceMainChannel
> *channel,
>  spice_main_file_copy_async,
>  SPICE_CLIENT_ERROR,
>  SPICE_CLIENT_ERROR_FAILED,
> -"The agent is not connected");
> +_("The agent is not connected"));
>  return;
>  }
>  
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [vdagent-win PATCH 3/7] Move image handling to a separate file

[Pavel Grunt]

On Thu, 2017-07-06 at 14:32 +0100, Frediano Ziglio wrote:
> This will make easier to change code that handle images.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  Makefile.am |  2 ++
>  vdagent/image.cpp   | 86
> +
>  vdagent/image.h | 46 
>  vdagent/vdagent.cpp | 57 +--
>  4 files changed, 142 insertions(+), 49 deletions(-)
>  create mode 100644 vdagent/image.cpp
>  create mode 100644 vdagent/image.h
> 
> diff --git a/Makefile.am b/Makefile.am
> index b60a718..868199e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -42,6 +42,8 @@ vdagent_SOURCES =   \
>   vdagent/vdagent.cpp \
>   vdagent/as_user.cpp \
>   vdagent/as_user.h   \
> + vdagent/image.cpp   \
> + vdagent/image.h \
>   $(NULL)
>  
>  vdagent_rc.$(OBJEXT): vdagent/vdagent.rc
> diff --git a/vdagent/image.cpp b/vdagent/image.cpp
> new file mode 100644
> index 000..fb19dbc
> --- /dev/null
> +++ b/vdagent/image.cpp
> @@ -0,0 +1,86 @@
> +/*
> +   Copyright (C) 2013-2016 Red Hat, Inc.
> +
> +   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 2 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 .
> +*/
> +
> +#include 
> +
> +#include "vdcommon.h"
> +#include "image.h"
> +
> +#include "ximage.h"


(it is going to be removed, but it is a system header, per our style the order
should be different)

> +
> +typedef struct ImageType {
> +uint32_t type;
> +DWORD cximage_format;
> +} ImageType;
> +
> +static const ImageType image_types[] = {
> +{VD_AGENT_CLIPBOARD_IMAGE_PNG, CXIMAGE_FORMAT_PNG},
> +{VD_AGENT_CLIPBOARD_IMAGE_BMP, CXIMAGE_FORMAT_BMP},
> +};
> +
> +static DWORD get_cximage_format(uint32_t type)
> +{
> +for (unsigned int i = 0; i < SPICE_N_ELEMENTS(image_types); i++) {
> +if (image_types[i].type == type) {
> +return image_types[i].cximage_format;
> +}
> +}
> +return 0;
> +}
> +
> +HANDLE get_image_handle(const VDAgentClipboard& clipboard, uint32_t size,
> UINT )
> +{
> +HANDLE clip_data;
> +DWORD cximage_format = get_cximage_format(clipboard.type);
> +ASSERT(cximage_format);
> +CxImage image((BYTE*)clipboard.data, size, cximage_format);
> +clip_data = image.CopyToHandle();
> +return clip_data;
> +}
> +
> +uint8_t* get_raw_clipboard_image(const VDAgentClipboardRequest&
> clipboard_request,
> + HANDLE clip_data, long& new_size)
> +{
> +CxImage image;
> +uint8_t *new_data = NULL;
> +DWORD cximage_format = get_cximage_format(clipboard_request.type);
> +HPALETTE pal = 0;
> +
> +ASSERT(cximage_format);
> +if (IsClipboardFormatAvailable(CF_PALETTE)) {
> +pal = (HPALETTE)GetClipboardData(CF_PALETTE);
> +}
> +if (!image.CreateFromHBITMAP((HBITMAP)clip_data, pal)) {
> +vd_printf("Image create from handle failed");
> +return NULL;
> +}
> +if (!image.Encode(new_data, new_size, cximage_format)) {
> +vd_printf("Image encode to type %u failed", clipboard_request.type);
> +return NULL;
> +}
> +vd_printf("Image encoded to %lu bytes", new_size);
> +return new_data;
> +}
> +
> +void free_raw_clipboard_image(uint8_t *data)
> +{
> +// this is really just a free however is better to make
> +// the free from CxImage code as on Windows the free
> +// can be different between libraries
> +CxImage image;
> +image.FreeMemory(data);
> +}
> diff --git a/vdagent/image.h b/vdagent/image.h
> new file mode 100644
> index 000..9ba6003
> --- /dev/null
> +++ b/vdagent/image.h
> @@ -0,0 +1,46 @@
> +/*
> +   Copyright (C) 2013-2016 Red Hat, Inc.
> +
> +   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 2 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 

Re: [Spice-devel] [spice-gtk v5 6/7] display-gst: Use Playbin for GStreamer 1.9.0 onwards

[Pavel Grunt]

On Fri, 2017-06-30 at 12:56 +0200, Victor Toso wrote:
> From: Victor Toso 
> 
> The Playbin can provide the full pipeline which reduces the
> overall maintenance in the code as we don't need to track which
> decoder can work with our stream type.
> 
> We need to maintain the GstCaps per SPICE_VIDEO_CODEC_TYPE in order to
> tell Playbin the type of data we expect. This much should be covered
> by spice-protocol and very likely we will need to extend it in the
> future to allow more settings that might not possible to verify at
> runtime.
> 
> This patch keeps previous code for compatibility reasons.
> 
> Note that we have to wait Playbin to emit "source-setup" in order to
> configure GstAppSrc with the capabilities of input stream. If in the
> unlikely event of frames arriving while GstAppSrc is not setup, we
> will drop those frames.
> 
> Signed-off-by: Victor Toso 
> ---
>  src/channel-display-gst.c | 102
> +-
>  1 file changed, 100 insertions(+), 2 deletions(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 1b40002..6fe0ac4 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -50,6 +50,9 @@ typedef struct SpiceGstDecoder {
>  guint timer_id;
>  } SpiceGstDecoder;
>  
> +/* FIXME: With gstreamer version 1.9.0 and higher, we are using playbin to
> + * create the pipeline for us and for that reason we don't need to keep track
> of
> + * decoder's name anymore. */
>  static struct {
>  const gchar *dec_name;
>  const gchar *dec_caps;
> @@ -83,6 +86,24 @@ G_STATIC_ASSERT(G_N_ELEMENTS(gst_opts) <=
> SPICE_VIDEO_CODEC_TYPE_ENUM_END);
>  #define VALID_VIDEO_CODEC_TYPE(codec) \
>  (codec > 0 && codec < G_N_ELEMENTS(gst_opts))
>  
> +/* GstPlay enum is plugin's header which will never be exported.
GstPlayFlags enum is *in*

okay (Never say never ;))

Ack,
Pavel

> + * https://bugzilla.gnome.org/show_bug.cgi?id=784279
> + */
> +typedef enum {
> +  GST_PLAY_FLAG_VIDEO = (1 << 0),
> +  GST_PLAY_FLAG_AUDIO = (1 << 1),
> +  GST_PLAY_FLAG_TEXT  = (1 << 2),
> +  GST_PLAY_FLAG_VIS   = (1 << 3),
> +  GST_PLAY_FLAG_SOFT_VOLUME   = (1 << 4),
> +  GST_PLAY_FLAG_NATIVE_AUDIO  = (1 << 5),
> +  GST_PLAY_FLAG_NATIVE_VIDEO  = (1 << 6),
> +  GST_PLAY_FLAG_DOWNLOAD  = (1 << 7),
> +  GST_PLAY_FLAG_BUFFERING = (1 << 8),
> +  GST_PLAY_FLAG_DEINTERLACE   = (1 << 9),
> +  GST_PLAY_FLAG_SOFT_COLORBALANCE = (1 << 10),
> +  GST_PLAY_FLAG_FORCE_FILTERS = (1 << 11),
Offtopic - may this flag be responsible for incorrect colours with vaapi?


> +} GstPlayFlags;
> +
>  /* -- SpiceGstFrame -- */
>  
>  typedef struct SpiceGstFrame {
> @@ -298,13 +319,81 @@ static gboolean handle_pipeline_message(GstBus *bus,
> GstMessage *msg, gpointer v
>  return TRUE;
>  }
>  
> +#if GST_CHECK_VERSION(1,9,0)
> +static void app_source_setup(GstElement *pipeline G_GNUC_UNUSED,
> + GstElement *source,
> + SpiceGstDecoder *decoder)
> +{
> +GstCaps *caps;
> +
> +/* - We schedule the frame display ourselves so set sync=false on appsink
> + *   so the pipeline decodes them as fast as possible. This will also
> + *   minimize the risk of frames getting lost when we rebuild the
> + *   pipeline.
> + * - Set max-bytes=0 on appsrc so it does not drop frames that may be
> + *   needed by those that follow.
> + */
> +caps = gst_caps_from_string(gst_opts[decoder->base.codec_type].dec_caps);
> +g_object_set(source,
> + "caps", caps,
> + "is-live", TRUE,
> + "format", GST_FORMAT_TIME,
> + "max-bytes", 0,
> + "block", TRUE,
> + NULL);
> +gst_caps_unref(caps);
> +decoder->appsrc = GST_APP_SRC(gst_object_ref(source));
> +}
> +#endif
> +
>  static gboolean create_pipeline(SpiceGstDecoder *decoder)
>  {
> -gchar *desc;
>  GstAppSinkCallbacks appsink_cbs = { NULL };
> -GError *err = NULL;
>  GstBus *bus;
> +#if GST_CHECK_VERSION(1,9,0)
> +GstElement *playbin, *sink;
> +GstPlayFlags flags;
> +GstCaps *caps;
>  
> +playbin = gst_element_factory_make("playbin", "playbin");
> +if (playbin == NULL) {
> +spice_warning("error upon creation of 'playbin' element");
> +return FALSE;
> +}
> +
> +sink = gst_element_factory_make("appsink", "sink");
> +if (sink == NULL) {
> +spice_warning("error upon creation of 'appsink' element");
> +gst_object_unref(playbin);
> +return FALSE;
> +}
> +
> +caps = gst_caps_from_string("video/x-raw,format=BGRx");
> +g_object_set(sink,
> + "caps", caps,
> + "sync", FALSE,
> + "drop", FALSE,
> + NULL);
> +gst_caps_unref(caps);
> +
> +

Re: [Spice-devel] [vdagent-win PATCH 2/7] Avoid log_level warning using a static const

[Pavel Grunt]

On Thu, 2017-07-06 at 14:31 +0100, Frediano Ziglio wrote:
> Compiler warnings for unused static variable.
> Not for constants.
> 
> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>
Acked-by: Pavel Grunt <pgr...@redhat.com>
> ---
>  common/vdlog.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/common/vdlog.h b/common/vdlog.h
> index 6d0413b..e645409 100644
> --- a/common/vdlog.h
> +++ b/common/vdlog.h
> @@ -41,18 +41,18 @@ private:
>  FILE* _handle;
>  };
>  
> -enum {
> +typedef enum {
>LOG_DEBUG,
>LOG_INFO,
>LOG_WARN,
>LOG_ERROR,
>LOG_FATAL
> -};
> +} VDLogLevel;
>  
>  #ifdef _DEBUG
> -static unsigned int log_level = LOG_DEBUG;
> +static const VDLogLevel log_level = LOG_DEBUG;
>  #else
> -static unsigned int log_level = LOG_INFO;
> +static const VDLogLevel log_level = LOG_INFO;
>  #endif
>  
>  #define PRINT_LINE(type, format, datetime, ms, ...) \
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [vdagent-win PATCH 1/7] Enable debug information build on spec file

[Pavel Grunt]

On Thu, 2017-07-06 at 14:31 +0100, Frediano Ziglio wrote:
> The spec file cause the generation of debuginfo packages however
> the build fails as the executables are not compiled with debugging
> information.
> 
> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>
Acked-by: Pavel Grunt <pgr...@redhat.com>

> ---
>  mingw-spice-vdagent.spec.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mingw-spice-vdagent.spec.in b/mingw-spice-vdagent.spec.in
> index d3ac53a..474c389 100644
> --- a/mingw-spice-vdagent.spec.in
> +++ b/mingw-spice-vdagent.spec.in
> @@ -76,7 +76,7 @@ Features:
>  %{mingw_debug_package}
>  
>  %build
> -%mingw_configure
> +%mingw_configure --enable-debug
>  %mingw_make %{?_smp_mflags} V=1
>  
>  
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Use designated struct initializer

[Pavel Grunt]

Silence -Wmissing-field-initializers warnings.
---
imo it also makes the code more readable (especially tests/session.c)
---
 src/channel-display-gst.c |   3 +-
 src/channel-main.c|   4 +-
 src/channel-record.c  |  16 +++--
 src/spice-channel.c   |  12 ++--
 src/spice-gtk-session.c   |  14 ++---
 src/spice-pulse.c |  18 +++---
 src/spice-session.c   |   2 +-
 tests/session.c   | 156 +-
 8 files changed, 118 insertions(+), 107 deletions(-)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 9b79403..807ff85 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -306,7 +306,7 @@ static gboolean create_pipeline(SpiceGstDecoder *decoder)
 gchar *desc;
 gboolean auto_enabled;
 guint opt;
-GstAppSinkCallbacks appsink_cbs = { NULL };
+GstAppSinkCallbacks appsink_cbs = { .new_sample = new_sample };
 GError *err = NULL;
 GstBus *bus;
 
@@ -344,7 +344,6 @@ static gboolean create_pipeline(SpiceGstDecoder *decoder)
 decoder->appsrc = 
GST_APP_SRC(gst_bin_get_by_name(GST_BIN(decoder->pipeline), "src"));
 decoder->appsink = 
GST_APP_SINK(gst_bin_get_by_name(GST_BIN(decoder->pipeline), "sink"));
 
-appsink_cbs.new_sample = new_sample;
 gst_app_sink_set_callbacks(decoder->appsink, _cbs, decoder, NULL);
 bus = gst_pipeline_get_bus(GST_PIPELINE(decoder->pipeline));
 gst_bus_add_watch(bus, handle_pipeline_message, decoder);
diff --git a/src/channel-main.c b/src/channel-main.c
index 4edd575..104b18a 100644
--- a/src/channel-main.c
+++ b/src/channel-main.c
@@ -1275,7 +1275,7 @@ static void agent_sync_audio_record(SpiceMainChannel 
*main_channel)
 static void agent_display_config(SpiceMainChannel *channel)
 {
 SpiceMainChannelPrivate *c = channel->priv;
-VDAgentDisplayConfig config = { 0, };
+VDAgentDisplayConfig config = { .flags = 0, .depth = 0};
 
 if (c->display_disable_wallpaper) {
 config.flags |= VD_AGENT_DISPLAY_CONFIG_FLAG_DISABLE_WALLPAPER;
@@ -2334,7 +2334,7 @@ static void main_migrate_connect(SpiceChannel *channel,
 {
 SpiceMainChannelPrivate *main_priv = SPICE_MAIN_CHANNEL(channel)->priv;
 int reply_type = SPICE_MSGC_MAIN_MIGRATE_CONNECT_ERROR;
-spice_migrate mig = { 0, };
+spice_migrate mig = { .from = NULL, };
 SpiceMsgOut *out;
 SpiceSession *session;
 
diff --git a/src/channel-record.c b/src/channel-record.c
index 9834e85..2023bb4 100644
--- a/src/channel-record.c
+++ b/src/channel-record.c
@@ -255,18 +255,18 @@ static void 
spice_record_channel_class_init(SpiceRecordChannelClass *klass)
 static void spice_record_mode(SpiceRecordChannel *channel, uint32_t time,
   uint32_t mode, uint8_t *data, uint32_t data_size)
 {
-SpiceMsgcRecordMode m = {0, };
+SpiceMsgcRecordMode m = {
+.time = time,
+.mode = mode,
+.data = data,
+.data_size = data_size,
+};
 SpiceMsgOut *msg;
 
 g_return_if_fail(channel != NULL);
 if (spice_channel_get_read_only(SPICE_CHANNEL(channel)))
 return;
 
-m.mode = mode;
-m.time = time;
-m.data = data;
-m.data_size = data_size;
-
 msg = spice_msg_out_new(SPICE_CHANNEL(channel), SPICE_MSGC_RECORD_MODE);
 msg->marshallers->msgc_record_mode(msg->marshaller, );
 spice_msg_out_send(msg);
@@ -317,7 +317,7 @@ void spice_record_send_data(SpiceRecordChannel *channel, 
gpointer data,
 gsize bytes, uint32_t time)
 {
 SpiceRecordChannelPrivate *rc;
-SpiceMsgcRecordPacket p = {0, };
+SpiceMsgcRecordPacket p = { .time = time };
 
 g_return_if_fail(SPICE_IS_RECORD_CHANNEL(channel));
 rc = channel->priv;
@@ -339,8 +339,6 @@ void spice_record_send_data(SpiceRecordChannel *channel, 
gpointer data,
 if (rc->mode != SPICE_AUDIO_DATA_MODE_RAW)
 encode_buf = g_alloca(SND_CODEC_MAX_COMPRESSED_BYTES);
 
-p.time = time;
-
 while (bytes > 0) {
 gsize n;
 int frame_size;
diff --git a/src/spice-channel.c b/src/spice-channel.c
index 4c3db9d..3e88d7a 100644
--- a/src/spice-channel.c
+++ b/src/spice-channel.c
@@ -928,12 +928,17 @@ static void spice_channel_write_msg(SpiceChannel 
*channel, SpiceMsgOut *out)
 #ifdef G_OS_UNIX
 static ssize_t read_fd(int fd, int *msgfd)
 {
-struct msghdr msg = { NULL, };
 struct iovec iov[1];
 union {
 struct cmsghdr cmsg;
 char control[CMSG_SPACE(sizeof(int))];
 } msg_control;
+struct msghdr msg = {
+.msg_iov = iov,
+.msg_iovlen = 1,
+.msg_control = _control,
+.msg_controllen = sizeof(msg_control),
+};
 struct cmsghdr *cmsg;
 ssize_t ret;
 char c;
@@ -941,11 +946,6 @@ static ssize_t read_fd(int fd, int *msgfd)
 iov[0].iov_base = 
 iov[0].iov_len = 1;
 
-msg.msg_iov = iov;
-msg.msg_iovlen = 1;
-msg.msg_control = _control;
-msg.msg_controllen = sizeof(msg_control);
-
 

Re: [Spice-devel] [vdagent-win PATCH] Update project URL

[Pavel Grunt]

On Fri, 2017-07-07 at 09:16 +0100, Frediano Ziglio wrote:
> Uses secure version https://www.spice-space.org.
> Avoid not secure and use same full name.
> 
> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>
Acked-by: Pavel Grunt <pgr...@redhat.com>

> ---
>  mingw-spice-vdagent.spec.in | 2 +-
>  spice-vdagent.wxs.in| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mingw-spice-vdagent.spec.in b/mingw-spice-vdagent.spec.in
> index b55e8d5..8cfd01a 100644
> --- a/mingw-spice-vdagent.spec.in
> +++ b/mingw-spice-vdagent.spec.in
> @@ -8,7 +8,7 @@ Release:1%{?dist}%{?extra_release}
>  Summary:MinGW Windows SPICE guest agent
>  
>  License:GPLv2+
> -URL:http://spice-space.org/
> +URL:https://www.spice-space.org/
>  Source0:vdagent-win-%{version}%{?_version_suffix}.tar.xz
>  
>  BuildRequires:  mingw32-filesystem >= 23
> diff --git a/spice-vdagent.wxs.in b/spice-vdagent.wxs.in
> index 060f33d..452f995 100644
> --- a/spice-vdagent.wxs.in
> +++ b/spice-vdagent.wxs.in
> @@ -23,7 +23,7 @@
>  
>  
>  
> -http://www.spice-space.org"/>;
> +https://www.spice-space.org"/>;
>  
>  
>  
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] Replace HAVE_X11_XKBLIB_H with GDK_WINDOWING_X11

[Pavel Grunt]

On Thu, 2017-07-06 at 18:42 +0200, Daniel Albers wrote:
> Thanks, Pavel.
> I thought I had checked this against git master, but I missed entirely 
> that https://github.com/SPICE/spice-gtk is actually stale since Apr '16.

unfortunately the github mirror is unmaintained.

You can find the original repos at https://cgit.freedesktop.org/spice/

Pavel

> 
> Cheers, Daniel
> 
> 
> On 2017-07-06 18:17, Pavel Grunt wrote:
> > Hi Daniel,
> > 
> > it's been already fixed in the spice-gtk git master:
> > https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=a7381b0864b7e6b15e6d
> > 08f6
> > 8e53bf3a429ab4ed
> > 
> > Any feedback regarding issues on non X11 system is welcome.
> > 
> > Thanks,
> > Pavel
> > 
> > On Thu, 2017-07-06 at 17:35 +0200, Daniel Albers wrote:
> > > Not all systems with an XKBlib.h also have a GDK with X11 support. 
> > > macOS can
> > > e.g. have HAVE_X11_XKBLIB_H without GDK_WINDOWING_X11, but
> > > GDK_WINDOWING_QUARTZ
> > > instead.
> > > ---
> > > Alternatively HAVE_GDK_GDK_X could be checked, but spice-gtk already 
> > > depends
> > > on
> > > GDK_WINDOWING_X11 in other places.
> > > 
> > >  src/spice-gtk-session.c | 8 ++--
> > >  src/spice-widget.c  | 4 
> > >  2 files changed, 2 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > index 27623f0..1398758 100644
> > > --- a/src/spice-gtk-session.c
> > > +++ b/src/spice-gtk-session.c
> > > @@ -19,10 +19,6 @@
> > > 
> > >  #include 
> > > 
> > > -#ifdef HAVE_X11_XKBLIB_H
> > > -#include 
> > > -#include 
> > > -#endif
> > >  #ifdef GDK_WINDOWING_X11
> > >  #include 
> > >  #include 
> > > @@ -138,7 +134,7 @@ static guint32 get_keyboard_lock_modifiers(void)
> > >  modifiers |= SPICE_INPUTS_SCROLL_LOCK;
> > >  }
> > >  #else
> > > -#ifdef HAVE_X11_XKBLIB_H
> > > +#ifdef GDK_WINDOWING_X11
> > >  Display *x_display = NULL;
> > >  XKeyboardState keyboard_state;
> > > 
> > > @@ -172,7 +168,7 @@ static guint32 get_keyboard_lock_modifiers(void)
> > >  }
> > >  #else
> > >  g_warning("get_keyboard_lock_modifiers not implemented");
> > > -#endif // HAVE_X11_XKBLIB_H
> > > +#endif // GDK_WINDOWING_X11
> > >  #endif // GTK_CHECK_VERSION(3,18,0)
> > >  return modifiers;
> > >  }
> > > diff --git a/src/spice-widget.c b/src/spice-widget.c
> > > index b458909..ffd4286 100644
> > > --- a/src/spice-widget.c
> > > +++ b/src/spice-widget.c
> > > @@ -20,10 +20,6 @@
> > >  #include 
> > >  #include 
> > > 
> > > -#ifdef HAVE_X11_XKBLIB_H
> > > -#include 
> > > -#include 
> > > -#endif
> > >  #ifdef GDK_WINDOWING_X11
> > >  #include 
> > >  #include 
> 
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] Replace HAVE_X11_XKBLIB_H with GDK_WINDOWING_X11

[Pavel Grunt]

Hi Daniel,

it's been already fixed in the spice-gtk git master:
https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=a7381b0864b7e6b15e6d08f6
8e53bf3a429ab4ed

Any feedback regarding issues on non X11 system is welcome.

Thanks,
Pavel

On Thu, 2017-07-06 at 17:35 +0200, Daniel Albers wrote:
> Not all systems with an XKBlib.h also have a GDK with X11 support. macOS can
> e.g. have HAVE_X11_XKBLIB_H without GDK_WINDOWING_X11, but
> GDK_WINDOWING_QUARTZ
> instead.
> ---
> Alternatively HAVE_GDK_GDK_X could be checked, but spice-gtk already depends
> on
> GDK_WINDOWING_X11 in other places.
> 
>  src/spice-gtk-session.c | 8 ++--
>  src/spice-widget.c  | 4 
>  2 files changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 27623f0..1398758 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -19,10 +19,6 @@
>  
>  #include 
>  
> -#ifdef HAVE_X11_XKBLIB_H
> -#include 
> -#include 
> -#endif
>  #ifdef GDK_WINDOWING_X11
>  #include 
>  #include 
> @@ -138,7 +134,7 @@ static guint32 get_keyboard_lock_modifiers(void)
>  modifiers |= SPICE_INPUTS_SCROLL_LOCK;
>  }
>  #else
> -#ifdef HAVE_X11_XKBLIB_H
> +#ifdef GDK_WINDOWING_X11
>  Display *x_display = NULL;
>  XKeyboardState keyboard_state;
>  
> @@ -172,7 +168,7 @@ static guint32 get_keyboard_lock_modifiers(void)
>  }
>  #else
>  g_warning("get_keyboard_lock_modifiers not implemented");
> -#endif // HAVE_X11_XKBLIB_H
> +#endif // GDK_WINDOWING_X11
>  #endif // GTK_CHECK_VERSION(3,18,0)
>  return modifiers;
>  }
> diff --git a/src/spice-widget.c b/src/spice-widget.c
> index b458909..ffd4286 100644
> --- a/src/spice-widget.c
> +++ b/src/spice-widget.c
> @@ -20,10 +20,6 @@
>  #include 
>  #include 
>  
> -#ifdef HAVE_X11_XKBLIB_H
> -#include 
> -#include 
> -#endif
>  #ifdef GDK_WINDOWING_X11
>  #include 
>  #include 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk v4 5/7] display-gst: check GstRegistry for decoding elements

[Pavel Grunt]

On Wed, 2017-06-28 at 14:43 +0200, Victor Toso wrote:
> From: Victor Toso 
> 
> With this patch, we can find all the elements in the registry that are
> video decoders which can handle the predefined GstCaps.
> 
> Main benefits are:
> - We don't rely on a predefined list of GstElements. We don't need to
>   update them;
> - debugging: It does help to know what the registry has at runtime;
> 
> Signed-off-by: Victor Toso 
> Acked-by: Frediano Ziglio 
> Signed-off-by: Victor Toso 
> ---
>  src/channel-display-gst.c | 56 ++--
> ---
>  1 file changed, 50 insertions(+), 6 deletions(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 57f0eb7..1b40002 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -521,16 +521,60 @@ VideoDecoder* create_gstreamer_decoder(int codec_type,
> display_stream *stream)
>  return (VideoDecoder*)decoder;
>  }
>  
> +static void gstvideo_debug_available_decoders(int codec_type,
> +  GList *all_decoders,
> +  GList *codec_decoders)
> +{
> +GList *l;
> +GString *msg = g_string_new(NULL);
> +/* Print list of available decoders to make debugging easier */
> +g_string_printf(msg, "From %3u video decoder elements, %2u can handle
> caps %12s: ",
> +g_list_length(all_decoders),
> g_list_length(codec_decoders),
> +gst_opts[codec_type].dec_caps);
> +
> +for (l = codec_decoders; l != NULL; l = l->next) {
> +GstPluginFeature *pfeat = GST_PLUGIN_FEATURE(l->data);
> +g_string_append_printf(msg, "%s, ",
> gst_plugin_feature_get_name(pfeat));
> +}
> +
> +/* Drop trailing ", " */
> +g_string_truncate(msg, msg->len - 2);
> +spice_debug("%s", msg->str);
> +g_string_free(msg, TRUE);
> +}
> +
>  G_GNUC_INTERNAL
>  gboolean gstvideo_has_codec(int codec_type)
>  {
> -gboolean has_codec = FALSE;
> +GList *all_decoders, *codec_decoders;
> +GstCaps *caps;
> +GstElementFactoryListType type;
> +
> +g_return_val_if_fail(gstvideo_init(), FALSE);
> +g_return_val_if_fail(VALID_VIDEO_CODEC_TYPE(codec_type), FALSE);
>  
> -VideoDecoder *decoder = create_gstreamer_decoder(codec_type, NULL);
> -if (decoder) {
> -has_codec = TRUE;
> -decoder->destroy(decoder);
> +type = GST_ELEMENT_FACTORY_TYPE_DECODER |
> GST_ELEMENT_FACTORY_TYPE_MEDIA_VIDEO;

also GST_ELEMENT_FACTORY_TYPE_MEDIA_IMAGE for "image/jpeg"

> +all_decoders = gst_element_factory_list_get_elements(type,
> GST_RANK_NONE);
> +if (all_decoders == NULL) {
> +spice_warning("No video decoders from GStreamer were found");
> +return FALSE;
>  }
>  
> -return has_codec;
> +caps = gst_caps_from_string(gst_opts[codec_type].dec_caps);
> +codec_decoders = gst_element_factory_list_filter(all_decoders, caps,
> GST_PAD_SINK, TRUE);
> +gst_caps_unref(caps);
> +
> +if (codec_decoders == NULL) {
> +spice_debug("From %u decoders, none can handle '%s'",
> +g_list_length(all_decoders),
> gst_opts[codec_type].dec_caps);
> +gst_plugin_feature_list_free(all_decoders);
> +return FALSE;
> +}
> +
> +if (spice_util_get_debug())
> +gstvideo_debug_available_decoders(codec_type, all_decoders,
> codec_decoders);
> +
> +gst_plugin_feature_list_free(codec_decoders);
> +gst_plugin_feature_list_free(all_decoders);
> +return TRUE;
>  }
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk v2] spice-channel: Factor out code for storing caps

[Pavel Grunt]

Signed-off-by: Pavel Grunt <pgr...@redhat.com>
---
v2 per Christophe's suggestion:
use GArray as parameter
---
 src/spice-channel.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/src/spice-channel.c b/src/spice-channel.c
index b8cf19c..4c3db9d 100644
--- a/src/spice-channel.c
+++ b/src/spice-channel.c
@@ -1884,11 +1884,25 @@ cleanup:
 #endif /* HAVE_SASL */
 
 /* coroutine context */
+static void store_caps(const uint8_t *caps_src, const GArray *caps_dst)
+{
+uint32_t *caps;
+guint i;
+
+caps = _array_index(caps_dst, uint32_t, 0);
+memcpy(caps, caps_src, caps_dst->len * sizeof(uint32_t));
+for (i = 0; i < caps_dst->len; i++, caps++) {
+*caps = GUINT32_FROM_LE(*caps);
+SPICE_DEBUG("\t%u:0x%X", i, *caps);
+}
+}
+
+/* coroutine context */
 static gboolean spice_channel_recv_link_msg(SpiceChannel *channel)
 {
 SpiceChannelPrivate *c;
-int rc, num_caps, i;
-uint32_t *caps, num_channel_caps, num_common_caps;
+int rc, num_caps;
+uint32_t num_channel_caps, num_common_caps;
 uint8_t *caps_src;
 SpiceChannelEvent event = SPICE_CHANNEL_ERROR_LINK;
 
@@ -1931,21 +1945,13 @@ static gboolean 
spice_channel_recv_link_msg(SpiceChannel *channel)
 
 caps_src = (uint8_t *)c->peer_msg + 
GUINT32_FROM_LE(c->peer_msg->caps_offset);
 g_array_set_size(c->remote_common_caps, num_common_caps);
-caps = _array_index(c->remote_common_caps, uint32_t, 0);
-memcpy(caps, caps_src, num_common_caps * sizeof(uint32_t));
-for (i = 0; i < num_common_caps; i++, caps++) {
-*caps = GUINT32_FROM_LE(*caps);
-CHANNEL_DEBUG(channel, "got common caps %d:0x%X", i, *caps);
-}
+CHANNEL_DEBUG(channel, "got remote common caps:");
+store_caps(caps_src, c->remote_common_caps);
 
 caps_src += num_common_caps * sizeof(uint32_t);
 g_array_set_size(c->remote_caps, num_channel_caps);
-caps = _array_index(c->remote_caps, uint32_t, 0);
-memcpy(caps, caps_src, num_channel_caps * sizeof(uint32_t));
-for (i = 0; i < num_channel_caps; i++, caps++) {
-*caps = GUINT32_FROM_LE(*caps);
-CHANNEL_DEBUG(channel, "got channel caps %d:0x%X", i, *caps);
-}
+CHANNEL_DEBUG(channel, "got remote channel caps:");
+store_caps(caps_src, c->remote_caps);
 
 if (!spice_channel_test_common_capability(channel,
 SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION)) {
-- 
2.13.0

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

[Spice-devel] [PATCH spice-gtk 1/2] spice-channel: Store the caps correctly

[Pavel Grunt]

The commit babe5630d5d3242b1d186cccdd5b4d51debe78e9 forgot to update
position of the caps pointer making remote caps to not be stored.

That cause strange behavior in remote-viewer - it always opened window
for each remote display.

Signed-off-by: Victor Toso <victort...@redhat.com>
Signed-off-by: Pavel Grunt <pgr...@redhat.com>
---
the lines were reordered to make the two "blocks" look similar, making clear 
that is possible to factor out the common code.
---
 src/spice-channel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/spice-channel.c b/src/spice-channel.c
index 418e2b7..b8cf19c 100644
--- a/src/spice-channel.c
+++ b/src/spice-channel.c
@@ -1938,8 +1938,9 @@ static gboolean spice_channel_recv_link_msg(SpiceChannel 
*channel)
 CHANNEL_DEBUG(channel, "got common caps %d:0x%X", i, *caps);
 }
 
-g_array_set_size(c->remote_caps, num_channel_caps);
 caps_src += num_common_caps * sizeof(uint32_t);
+g_array_set_size(c->remote_caps, num_channel_caps);
+caps = _array_index(c->remote_caps, uint32_t, 0);
 memcpy(caps, caps_src, num_channel_caps * sizeof(uint32_t));
 for (i = 0; i < num_channel_caps; i++, caps++) {
 *caps = GUINT32_FROM_LE(*caps);
-- 
2.13.0

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

[Spice-devel] [PATCH spice-gtk 2/2] spice-channel: Factor out code for storing caps

[Pavel Grunt]

Signed-off-by: Pavel Grunt <pgr...@redhat.com>
---
 src/spice-channel.c | 41 +
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/src/spice-channel.c b/src/spice-channel.c
index b8cf19c..2422811 100644
--- a/src/spice-channel.c
+++ b/src/spice-channel.c
@@ -1884,11 +1884,32 @@ cleanup:
 #endif /* HAVE_SASL */
 
 /* coroutine context */
+static void store_remote_caps(SpiceChannel *channel,
+  const bool are_common,
+  const uint8_t *caps_src,
+  const guint num_caps)
+{
+SpiceChannelPrivate *c = channel->priv;
+uint32_t *caps;
+guint i;
+GArray *remote_caps = are_common ? c->remote_common_caps : c->remote_caps;
+const gchar *caps_name = are_common ? "common" : "channel";
+
+g_array_set_size(remote_caps, num_caps);
+caps = _array_index(remote_caps, uint32_t, 0);
+memcpy(caps, caps_src, num_caps * sizeof(uint32_t));
+for (i = 0; i < num_caps; i++, caps++) {
+*caps = GUINT32_FROM_LE(*caps);
+CHANNEL_DEBUG(channel, "got %s caps %u:0x%X", caps_name,  i, *caps);
+}
+}
+
+/* coroutine context */
 static gboolean spice_channel_recv_link_msg(SpiceChannel *channel)
 {
 SpiceChannelPrivate *c;
-int rc, num_caps, i;
-uint32_t *caps, num_channel_caps, num_common_caps;
+int rc, num_caps;
+uint32_t num_channel_caps, num_common_caps;
 uint8_t *caps_src;
 SpiceChannelEvent event = SPICE_CHANNEL_ERROR_LINK;
 
@@ -1930,22 +1951,10 @@ static gboolean 
spice_channel_recv_link_msg(SpiceChannel *channel)
 /* g_return_if_fail(c->peer_msg + c->peer_msg->caps_offset * 
sizeof(uint32_t) > c->peer_msg + c->peer_hdr.size); */
 
 caps_src = (uint8_t *)c->peer_msg + 
GUINT32_FROM_LE(c->peer_msg->caps_offset);
-g_array_set_size(c->remote_common_caps, num_common_caps);
-caps = _array_index(c->remote_common_caps, uint32_t, 0);
-memcpy(caps, caps_src, num_common_caps * sizeof(uint32_t));
-for (i = 0; i < num_common_caps; i++, caps++) {
-*caps = GUINT32_FROM_LE(*caps);
-CHANNEL_DEBUG(channel, "got common caps %d:0x%X", i, *caps);
-}
+store_remote_caps(channel, true, caps_src, num_common_caps);
 
 caps_src += num_common_caps * sizeof(uint32_t);
-g_array_set_size(c->remote_caps, num_channel_caps);
-caps = _array_index(c->remote_caps, uint32_t, 0);
-memcpy(caps, caps_src, num_channel_caps * sizeof(uint32_t));
-for (i = 0; i < num_channel_caps; i++, caps++) {
-*caps = GUINT32_FROM_LE(*caps);
-CHANNEL_DEBUG(channel, "got channel caps %d:0x%X", i, *caps);
-}
+store_remote_caps(channel, false, caps_src, num_channel_caps);
 
 if (!spice_channel_test_common_capability(channel,
 SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION)) {
-- 
2.13.0

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

Re: [Spice-devel] [PATCH spice-gtk v4 7/7] display-gst: Debug video pipeline on stream-start message

[Pavel Grunt]

On Wed, 2017-06-28 at 14:43 +0200, Victor Toso wrote:
> From: Victor Toso 
> 
> On GST_MESSAGE_STREAM_START our stream is about to start and it
> seems
> a good moment to debug GStreamer pipeline if requested.
> 
So this is just for the debug purpose.


> That we can do with GST_DEBUG_BIN_TO_DOT_FILE() which iterates
> recursively in the whole pipeline and generates a dot file with all
> the information, the filename is 'spice-gtk-gst-pipeline-debug.dot'.

When streaming is enabled there is a lot of streams, but just one
file. I'd suggest to put the stream id to the file name.

Pavel

> 
> One can generate png image out of this dot file with the command:
>   dot -Tpng -oimage.png spice-gtk-gst-pipeline-debug.dot
> 
> Not that GST_DEBUG_BIN_TO_DOT_FILE() will only work if Gstreamer was
> configured with --gst-enable-gst-debug and the environment variable
> GST_DEBUG_DUMP_DOT_DIR was properly set.
> 
> Full example:
> 
> 1) GST_DEBUG_DUMP_DOT_DIR=/tmp remote-viewer ...
> 2) dot -Tpng -oimage.png spice-gtk-gst-pipeline-debug.dot
> 
> Signed-off-by: Victor Toso 
> Signed-off-by: Victor Toso 
> ---
>  src/channel-display-gst.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index df58de3..04710e8 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -298,7 +298,8 @@ static gboolean handle_pipeline_message(GstBus
> *bus, GstMessage *msg, gpointer v
>  {
>  SpiceGstDecoder *decoder = video_decoder;
>  
> -if (GST_MESSAGE_TYPE(msg) == GST_MESSAGE_ERROR) {
> +switch(GST_MESSAGE_TYPE(msg)) {
> +case GST_MESSAGE_ERROR: {
>  GError *err = NULL;
>  gchar *debug_info = NULL;
>  gst_message_parse_error(msg, , _info);
> @@ -312,6 +313,18 @@ static gboolean handle_pipeline_message(GstBus
> *bus, GstMessage *msg, gpointer v
>  
>  /* We won't be able to process any more frame anyway */
>  free_pipeline(decoder);
> +break;
> +}
> +case GST_MESSAGE_STREAM_START:
> +GST_DEBUG_BIN_TO_DOT_FILE(GST_BIN(decoder->pipeline),
> +  GST_DEBUG_GRAPH_SHOW_ALL
> +|
> GST_DEBUG_GRAPH_SHOW_FULL_PARAMS
> +| GST_DEBUG_GRAPH_SHOW_STATES,
> +  "spice-gtk-gst-pipeline-debug");
> +break;
> +default:
> +/* not being handled */
> +break;
>  }
>  return TRUE;
>  }
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk v4 6/7] display-gst: Use Playbin for GStreamer 1.9.0 onwards

[Pavel Grunt]

On Wed, 2017-06-28 at 14:43 +0200, Victor Toso wrote:
> From: Victor Toso 
> 
> The Playbin can provide the full pipeline which reduces the
> overall maintenance in the code as we don't need to track which
> decoder can work with our stream type.
> 
> We need to maintain the GstCaps per SPICE_VIDEO_CODEC_TYPE in order
> to
> tell Playbin the type of data we expect. This much should be covered
> by spice-protocol and very likely we will need to extend it in the
> future to allow more settings that might not possible to verify at
> runtime.
> 
> This patch keeps previous code for compatibility reasons.
> 
> Note that we have to wait Playbin to emit "source-setup" in order to
> configure GstAppSrc with the capabilities of input stream. If in the
> unlikely event of frames arriving while GstAppSrc is not setup, we
> will drop those frames.
> 
> Signed-off-by: Victor Toso 
> Signed-off-by: Victor Toso 
> ---
>  src/channel-display-gst.c | 99
> ++-
>  1 file changed, 97 insertions(+), 2 deletions(-)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 1b40002..df58de3 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -50,6 +50,9 @@ typedef struct SpiceGstDecoder {
>  guint timer_id;
>  } SpiceGstDecoder;
>  
> +/* FIXME: With gstreamer version 1.9.0 and higher, we are using
> playbin to
> + * create the pipeline for us and for that reason we don't need to
> keep track of
> + * decoder's name anymore. */
>  static struct {
>  const gchar *dec_name;
>  const gchar *dec_caps;
> @@ -83,6 +86,21 @@ G_STATIC_ASSERT(G_N_ELEMENTS(gst_opts) <=
> SPICE_VIDEO_CODEC_TYPE_ENUM_END);
>  #define VALID_VIDEO_CODEC_TYPE(codec) \
>  (codec > 0 && codec < G_N_ELEMENTS(gst_opts))
>  
> +typedef enum {
> +  GST_PLAY_FLAG_VIDEO = (1 << 0),
> +  GST_PLAY_FLAG_AUDIO = (1 << 1),
> +  GST_PLAY_FLAG_TEXT  = (1 << 2),
> +  GST_PLAY_FLAG_VIS   = (1 << 3),
> +  GST_PLAY_FLAG_SOFT_VOLUME   = (1 << 4),
> +  GST_PLAY_FLAG_NATIVE_AUDIO  = (1 << 5),
> +  GST_PLAY_FLAG_NATIVE_VIDEO  = (1 << 6),
> +  GST_PLAY_FLAG_DOWNLOAD  = (1 << 7),
> +  GST_PLAY_FLAG_BUFFERING = (1 << 8),
> +  GST_PLAY_FLAG_DEINTERLACE   = (1 << 9),
> +  GST_PLAY_FLAG_SOFT_COLORBALANCE = (1 << 10),
> +  GST_PLAY_FLAG_FORCE_FILTERS = (1 << 11),
> +} GstPlayFlags;

It can cause problems if gstreamer exports, please give them a SPICE
prefix

> +
>  /* -- SpiceGstFrame -- */
>  
>  typedef struct SpiceGstFrame {
> @@ -298,13 +316,81 @@ static gboolean handle_pipeline_message(GstBus
> *bus, GstMessage *msg, gpointer v
>  return TRUE;
>  }
>  
> +#if GST_CHECK_VERSION(1,9,0)
> +static void app_source_setup(GstElement *pipeline G_GNUC_UNUSED,
> + GstElement *source,
> + SpiceGstDecoder *decoder)
> +{
> +GstCaps *caps;
> +
> +/* - We schedule the frame display ourselves so set sync=false
> on appsink
> + *   so the pipeline decodes them as fast as possible. This
> will also
> + *   minimize the risk of frames getting lost when we rebuild
> the
> + *   pipeline.
> + * - Set max-bytes=0 on appsrc so it does not drop frames that
> may be
> + *   needed by those that follow.
> + */
> +caps = gst_caps_from_string(gst_opts[decoder-
> >base.codec_type].dec_caps);
> +g_object_set(source,
> + "caps", caps,
> + "is-live", TRUE,
> + "format", GST_FORMAT_TIME,
> + "max-bytes", 0,
> + "block", TRUE,
> + NULL);
> +gst_caps_unref(caps);
> +decoder->appsrc = GST_APP_SRC(gst_object_ref(source));
> +}
> +#endif
> +
>  static gboolean create_pipeline(SpiceGstDecoder *decoder)
>  {
> -gchar *desc;
>  GstAppSinkCallbacks appsink_cbs = { NULL };
> -GError *err = NULL;
>  GstBus *bus;
> +#if GST_CHECK_VERSION(1,9,0)
> +GstElement *playbin, *sink;
> +gint flags;
the type of the property is GstPlayFlags (I know, not exported but
you've defined it)

> +GstCaps *caps;
>  
> +playbin = gst_element_factory_make("playbin", "playbin");
> +if (playbin == NULL) {
> +spice_warning("error upon creation of 'playbin' element");
> +return FALSE;
> +}
> +
> +sink = gst_element_factory_make("appsink", "sink");
> +if (sink == NULL) {
> +spice_warning("error upon creation of 'appsink' element");
> +gst_object_unref(playbin);
> +return FALSE;
> +}
> +
> +caps = gst_caps_from_string("video/x-raw,format=BGRx");
the string can be a static constant

> +g_object_set(sink,
> + "caps", caps,
> + "sync", FALSE,
> + "drop", FALSE,
> + NULL);
> +gst_caps_unref(caps);
> +
> +

Re: [Spice-devel] [PATCH spice-gtk v4 1/7] display-gst: check codec type before creating decoder

[Pavel Grunt]

On Wed, 2017-06-28 at 14:42 +0200, Victor Toso wrote:
> From: Victor Toso <m...@victortoso.com>
> 
> Inserting this check in channel-display-gst.c as the GStreamer
> decoder
> is the only one handling all the different video formats supported
> by
> spice-protocol.
> 
> If a unsupported/bad codec type value was sent, spice-gtk will fail
> to
> create the decoder and any messages related to this stream-id will
> be
> ignored.
> 
> Signed-off-by: Victor Toso <victort...@redhat.com>
> Signed-off-by: Victor Toso <m...@victortoso.com>

Acked-by: Pavel Grunt <pgr...@redhat.com>

It is a programmer error. The programmer should check for the codec
type in display_stream_create()

Pavel

> ---
>  src/channel-display-gst.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 9b79403..d3e83e3 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -512,6 +512,8 @@ VideoDecoder* create_gstreamer_decoder(int
> codec_type, display_stream *stream)
>  {
>  SpiceGstDecoder *decoder = NULL;
>  
> +g_return_val_if_fail(VALID_VIDEO_CODEC_TYPE(codec_type), NULL);
> +
>  if (gstvideo_init()) {
>  decoder = spice_new0(SpiceGstDecoder, 1);
>  decoder->base.destroy = spice_gst_decoder_destroy;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk v2 1/2] usb-device-widget: Fix parent class type

[Pavel Grunt]

On Mon, 2017-06-26 at 06:18 -0400, Frediano Ziglio wrote:
> > 
> > The widget is defined as GTK_TYPE_BOX, use GtkBox instead of
> > GtkVBox.
> 
> Shouldn't you set the orientation to vertical too? I think the
> default
> is horizontal.

the object is created with the vertical orientation, see the
definition of spice_usb_device_widget_new

> Not that I think something would change, there are no reference to
> GtkVBox,
> only GtkBox so this seems more of a fix to me.

to me as well, nothing should change.

Thanks,
Pavel

> 
> > ---
> >  src/usb-device-widget.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
> > index b394499..747887c 100644
> > --- a/src/usb-device-widget.c
> > +++ b/src/usb-device-widget.c
> > @@ -40,14 +40,14 @@
> >  
> >  struct _SpiceUsbDeviceWidget
> >  {
> > -GtkVBox parent;
> > +GtkBox parent;
> >  
> >  SpiceUsbDeviceWidgetPrivate *priv;
> >  };
> >  
> >  struct _SpiceUsbDeviceWidgetClass
> >  {
> > -GtkVBoxClass parent_class;
> > +GtkBoxClass parent_class;
> >  
> >  /* signals */
> >  void (*connect_failed) (SpiceUsbDeviceWidget *widget,
> 
> Patch looks good to me, just not an expert of either this widget
> and Gtk.
> 
> Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] usb-device-widget: Migrate to GtkContainer api

[Pavel Grunt]

On Mon, 2017-06-26 at 06:08 -0400, Frediano Ziglio wrote:
> > 
> > Hi,
> > 
> > On Fri, 2017-06-23 at 11:35 -0400, Frediano Ziglio wrote:
> > > > 
> > > > GtkVBox is deprecated since Gtk 3.2, GtkBox is going to be
> > > > deprecated. Switch to GtkContainer api if possible.
> > > > ---
> > > >  src/usb-device-widget.c | 15 ---
> > > >  1 file changed, 8 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
> > > > index b394499..e87bdff 100644
> > > > --- a/src/usb-device-widget.c
> > > > +++ b/src/usb-device-widget.c
> > > > @@ -40,14 +40,14 @@
> > > >  
> > > >  struct _SpiceUsbDeviceWidget
> > > >  {
> > > > -GtkVBox parent;
> > > > +GtkBox parent;
> > > >  
> > > >  SpiceUsbDeviceWidgetPrivate *priv;
> > > >  };
> > > >  
> > > >  struct _SpiceUsbDeviceWidgetClass
> > > >  {
> > > > -GtkVBoxClass parent_class;
> > > > +GtkBoxClass parent_class;
> > > >  
> > > >  /* signals */
> > > >  void (*connect_failed) (SpiceUsbDeviceWidget *widget,
> > > > @@ -168,15 +168,16 @@
> > > > spice_usb_device_widget_show_info_bar(SpiceUsbDeviceWidget
> > > > *self,
> > > >  
> > > >  widget = gtk_image_new_from_icon_name(stock_icon_id,
> > > >GTK_ICON_SIZE_SMALL
> > > > _TOO
> > > > LBAR);
> > > > -gtk_box_pack_start(GTK_BOX(hbox), widget, FALSE, FALSE,
> > > > 0);
> > > > +gtk_container_add(GTK_CONTAINER(hbox), widget);
> > > >  
> > > >  widget = gtk_label_new(message);
> > > > -gtk_box_pack_start(GTK_BOX(hbox), widget, TRUE, TRUE, 0);
> > > > +g_object_set(G_OBJECT(widget), "expand", TRUE, NULL);
> > > > +gtk_container_add(GTK_CONTAINER(hbox), widget);
> > > >  
> > > >  priv->info_bar = gtk_alignment_new(0.0, 0.0, 1.0, 0.0);
> > > >  gtk_alignment_set_padding(GTK_ALIGNMENT(priv->info_bar),
> > > > 0,
> > > > 0, 12, 0);
> > > >  gtk_container_add(GTK_CONTAINER(priv->info_bar),
> > > > info_bar);
> > > > -gtk_box_pack_start(GTK_BOX(self), priv->info_bar, FALSE,
> > > > FALSE, 0);
> > > > +gtk_container_add(GTK_CONTAINER(self), priv->info_bar);
> > > >  gtk_widget_show_all(priv->info_bar);
> > > >  }
> > > >  
> > > > @@ -208,7 +209,7 @@ static GObject
> > > > *spice_usb_device_widget_constructor(
> > > >  gtk_label_set_markup(GTK_LABEL (priv->label), str);
> > > >  g_free(str);
> > > >  gtk_misc_set_alignment(GTK_MISC(priv->label), 0.0, 0.5);
> > > > -gtk_box_pack_start(GTK_BOX(self), priv->label, FALSE,
> > > > FALSE,
> > > > 0);
> > > > +gtk_container_add(GTK_CONTAINER(self), priv->label);
> > > >  
> > > >  priv->manager = spice_usb_device_manager_get(priv-
> > > > >session,
> > > > );
> > > >  if (err) {
> > > > @@ -572,7 +573,7 @@ static void
> > > > device_added_cb(SpiceUsbDeviceManager
> > > > *manager,
> > > >  align = gtk_alignment_new(0, 0, 0, 0);
> > > >  gtk_alignment_set_padding(GTK_ALIGNMENT(align), 0, 0, 12,
> > > > 0);
> > > >  gtk_container_add(GTK_CONTAINER(align), check);
> > > > -gtk_box_pack_end(GTK_BOX(self), align, FALSE, FALSE, 0);
> > > > +gtk_container_add(GTK_CONTAINER(self), align);
> > > >  spice_usb_device_widget_update_status(self);
> > > >  gtk_widget_show_all(align);
> > > >  }
> > > 
> > > This patch looks like a partial attempt to remove GtkVBox (full)
> > > and
> > > GtkBox (partial, still SpiceUsbDeviceWidget base).
> > 
> > in fact it is a fix of the parent type - the widget is defined as
> > GTK_TYPE_BOX (not as GTK_TYPE_VBOX). There are no issues, because
> > the
> > structure is the *same*. I'll split it.
> > 
> 
> What I was trying to say is that you replaced multiple calls to
> gtk_box_pack_start to gtk_container_add but the object is still
> based on GtkBox while on the comment you wrote "GtkBox is going
> to be deprecated. Switch to GtkContainer api if possible" maybe
> I'm confused by the "if possible" that seems to indicate that
> is not possible to move away from GtkBox.

Ah, okay. I've changed the commit message.

> 
> OT: it seems Spicy is using GtkBox too.

spicy is mostly using deprecated stuff :( I plan to clean it in a
different commit

Pavel

> 
> > > 
> > > Would not be better to have a patch that fully remove GtkVBox
> > > only
> > > and
> > > then another that fully remove GtkBox (using GtkContainer or
> > > GtkGrid,
> > > don't know if GtkGrid is going to be deprecated too) ?
> > 
> > I checked that GtkBox is still in gtk+ master (gtk4). Changing the
> > G_DEFINE_TYPE is an abi change (It can be done for gtk4 version of
> > spice-gtk).
> > 
> > Pavel
> > 
> 
> Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk v2 1/2] usb-device-widget: Fix parent class type

[Pavel Grunt]

The widget is defined as GTK_TYPE_BOX, use GtkBox instead of GtkVBox.
---
 src/usb-device-widget.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
index b394499..747887c 100644
--- a/src/usb-device-widget.c
+++ b/src/usb-device-widget.c
@@ -40,14 +40,14 @@
 
 struct _SpiceUsbDeviceWidget
 {
-GtkVBox parent;
+GtkBox parent;
 
 SpiceUsbDeviceWidgetPrivate *priv;
 };
 
 struct _SpiceUsbDeviceWidgetClass
 {
-GtkVBoxClass parent_class;
+GtkBoxClass parent_class;
 
 /* signals */
 void (*connect_failed) (SpiceUsbDeviceWidget *widget,
-- 
2.13.0

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

[Spice-devel] [PATCH spice-gtk v2 2/2] usb-device-widget: Migrate to GtkContainer api

[Pavel Grunt]

It is enough for us. Also GtkBox api has changed recently in gtk master.
---
 src/usb-device-widget.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
index 747887c..e87bdff 100644
--- a/src/usb-device-widget.c
+++ b/src/usb-device-widget.c
@@ -168,15 +168,16 @@ 
spice_usb_device_widget_show_info_bar(SpiceUsbDeviceWidget *self,
 
 widget = gtk_image_new_from_icon_name(stock_icon_id,
   GTK_ICON_SIZE_SMALL_TOOLBAR);
-gtk_box_pack_start(GTK_BOX(hbox), widget, FALSE, FALSE, 0);
+gtk_container_add(GTK_CONTAINER(hbox), widget);
 
 widget = gtk_label_new(message);
-gtk_box_pack_start(GTK_BOX(hbox), widget, TRUE, TRUE, 0);
+g_object_set(G_OBJECT(widget), "expand", TRUE, NULL);
+gtk_container_add(GTK_CONTAINER(hbox), widget);
 
 priv->info_bar = gtk_alignment_new(0.0, 0.0, 1.0, 0.0);
 gtk_alignment_set_padding(GTK_ALIGNMENT(priv->info_bar), 0, 0, 12, 0);
 gtk_container_add(GTK_CONTAINER(priv->info_bar), info_bar);
-gtk_box_pack_start(GTK_BOX(self), priv->info_bar, FALSE, FALSE, 0);
+gtk_container_add(GTK_CONTAINER(self), priv->info_bar);
 gtk_widget_show_all(priv->info_bar);
 }
 
@@ -208,7 +209,7 @@ static GObject *spice_usb_device_widget_constructor(
 gtk_label_set_markup(GTK_LABEL (priv->label), str);
 g_free(str);
 gtk_misc_set_alignment(GTK_MISC(priv->label), 0.0, 0.5);
-gtk_box_pack_start(GTK_BOX(self), priv->label, FALSE, FALSE, 0);
+gtk_container_add(GTK_CONTAINER(self), priv->label);
 
 priv->manager = spice_usb_device_manager_get(priv->session, );
 if (err) {
@@ -572,7 +573,7 @@ static void device_added_cb(SpiceUsbDeviceManager *manager,
 align = gtk_alignment_new(0, 0, 0, 0);
 gtk_alignment_set_padding(GTK_ALIGNMENT(align), 0, 0, 12, 0);
 gtk_container_add(GTK_CONTAINER(align), check);
-gtk_box_pack_end(GTK_BOX(self), align, FALSE, FALSE, 0);
+gtk_container_add(GTK_CONTAINER(self), align);
 spice_usb_device_widget_update_status(self);
 gtk_widget_show_all(align);
 }
-- 
2.13.0

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

Re: [Spice-devel] [PATCH spice-gtk] usb-device-widget: Migrate to GtkContainer api

[Pavel Grunt]

Hi,

On Fri, 2017-06-23 at 11:35 -0400, Frediano Ziglio wrote:
> > 
> > GtkVBox is deprecated since Gtk 3.2, GtkBox is going to be
> > deprecated. Switch to GtkContainer api if possible.
> > ---
> >  src/usb-device-widget.c | 15 ---
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> > 
> > diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
> > index b394499..e87bdff 100644
> > --- a/src/usb-device-widget.c
> > +++ b/src/usb-device-widget.c
> > @@ -40,14 +40,14 @@
> >  
> >  struct _SpiceUsbDeviceWidget
> >  {
> > -GtkVBox parent;
> > +GtkBox parent;
> >  
> >  SpiceUsbDeviceWidgetPrivate *priv;
> >  };
> >  
> >  struct _SpiceUsbDeviceWidgetClass
> >  {
> > -GtkVBoxClass parent_class;
> > +GtkBoxClass parent_class;
> >  
> >  /* signals */
> >  void (*connect_failed) (SpiceUsbDeviceWidget *widget,
> > @@ -168,15 +168,16 @@
> > spice_usb_device_widget_show_info_bar(SpiceUsbDeviceWidget *self,
> >  
> >  widget = gtk_image_new_from_icon_name(stock_icon_id,
> >GTK_ICON_SIZE_SMALL_TOO
> > LBAR);
> > -gtk_box_pack_start(GTK_BOX(hbox), widget, FALSE, FALSE, 0);
> > +gtk_container_add(GTK_CONTAINER(hbox), widget);
> >  
> >  widget = gtk_label_new(message);
> > -gtk_box_pack_start(GTK_BOX(hbox), widget, TRUE, TRUE, 0);
> > +g_object_set(G_OBJECT(widget), "expand", TRUE, NULL);
> > +gtk_container_add(GTK_CONTAINER(hbox), widget);
> >  
> >  priv->info_bar = gtk_alignment_new(0.0, 0.0, 1.0, 0.0);
> >  gtk_alignment_set_padding(GTK_ALIGNMENT(priv->info_bar), 0,
> > 0, 12, 0);
> >  gtk_container_add(GTK_CONTAINER(priv->info_bar), info_bar);
> > -gtk_box_pack_start(GTK_BOX(self), priv->info_bar, FALSE,
> > FALSE, 0);
> > +gtk_container_add(GTK_CONTAINER(self), priv->info_bar);
> >  gtk_widget_show_all(priv->info_bar);
> >  }
> >  
> > @@ -208,7 +209,7 @@ static GObject
> > *spice_usb_device_widget_constructor(
> >  gtk_label_set_markup(GTK_LABEL (priv->label), str);
> >  g_free(str);
> >  gtk_misc_set_alignment(GTK_MISC(priv->label), 0.0, 0.5);
> > -gtk_box_pack_start(GTK_BOX(self), priv->label, FALSE, FALSE,
> > 0);
> > +gtk_container_add(GTK_CONTAINER(self), priv->label);
> >  
> >  priv->manager = spice_usb_device_manager_get(priv->session,
> > );
> >  if (err) {
> > @@ -572,7 +573,7 @@ static void
> > device_added_cb(SpiceUsbDeviceManager
> > *manager,
> >  align = gtk_alignment_new(0, 0, 0, 0);
> >  gtk_alignment_set_padding(GTK_ALIGNMENT(align), 0, 0, 12, 0);
> >  gtk_container_add(GTK_CONTAINER(align), check);
> > -gtk_box_pack_end(GTK_BOX(self), align, FALSE, FALSE, 0);
> > +gtk_container_add(GTK_CONTAINER(self), align);
> >  spice_usb_device_widget_update_status(self);
> >  gtk_widget_show_all(align);
> >  }
> 
> This patch looks like a partial attempt to remove GtkVBox (full) and
> GtkBox (partial, still SpiceUsbDeviceWidget base).

in fact it is a fix of the parent type - the widget is defined as
GTK_TYPE_BOX (not as GTK_TYPE_VBOX). There are no issues, because the
structure is the *same*. I'll split it.

> 
> Would not be better to have a patch that fully remove GtkVBox only
> and
> then another that fully remove GtkBox (using GtkContainer or
> GtkGrid,
> don't know if GtkGrid is going to be deprecated too) ?

I checked that GtkBox is still in gtk+ master (gtk4). Changing the
G_DEFINE_TYPE is an abi change (It can be done for gtk4 version of
spice-gtk).

Pavel

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

Re: [Spice-devel] SSL-problem occurs with Spice-glib on Arch linux (when connecting from Proxmox)

[Pavel Grunt]

Hello,

On Sun, 2017-06-25 at 01:15 +0200, AmigAsger wrote:
> Dear Spice-Devel,
> 
> I have been investigating an SSL-issue, which all of a sudden
> occured on my Arch Linux distribution (when connecting to my proxmox
> virtualization center).
> 
> Something seems to break from spice-glib-0.33-3-x86_64.pkg.tar.xz
> to spice-glib-0.33-4-x86_64.pkg.tar.xz when using spice-gtk3-0.33-6.
> 
Then its your distro (packaging) related issue - we distribute only
0.33 tarball upstream.

> If I update to spice-glib-0.33-4 (or later) then I get the "Cannot
> connect to graphics server [path]" - and spice-debug gives following
> SSL-error:

Just a guess: Check your openssl library version. spice-gtk could be
compiled using different openssl version than the one in your system.

Pavel


> remote-viewer --spice-debug ~/Hentninger/download 
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:285 New session
> (compiled from package spice-gtk 0.33)
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:289 Supported
> channels: main, display, inputs, cursor, playback, record,
> smartcard, usbredir
> (remote-viewer:6416): GSpice-DEBUG: usb-device-manager.c:523 auto-
> connect filter set to 0x03,-1,-1,-1,0|-1,-1,-1,-1,1
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:1736 no
> migration in progress
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:146 main-1:0:
> spice_channel_constructed
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:2239 main-1:0:
> new main channel, switching
> (remote-viewer:6416): GSpice-DEBUG: spice-gtk-session.c:1099
> Changing main channel from (nil) to 0x206e400
> (remote-viewer:6416): GSpice-DEBUG: usb-device-manager.c:1008 device
> added 05c6:9204 (0x1ec2490)
> (remote-viewer:6416): GSpice-DEBUG: usb-device-manager.c:1008 device
> added 17ef:4816 (0x2015fd0)
> (remote-viewer:6416): GSpice-DEBUG: usb-device-manager.c:1008 device
> added 0a5c:217f (0x1e6da70)
> (remote-viewer:6416): GSpice-DEBUG: usb-device-manager.c:1008 device
> added 147e:2016 (0x1f14590)
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:2614 main-1:0:
> Open coroutine starting 0x206e400
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:2455 main-1:0:
> Started background coroutine 0x206e290
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:2173 Missing
> port value, not attempting unencrypted connection.
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:2481 main-1:0:
> trying with TLS port
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:2185 main-1:0:
> Using TLS, port 61000
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:2133 (with proxy
> http://10.0.10.10:3128)
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:2057 proxy
> lookup ready
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:2040 main-1:0:
> connecting 0x7f3bcebfcab0...
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:2024 main-1:0:
> connect ready
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:2382 main-1:0:
> Load CA, file: (null), data: 0x204c030
> 
> (remote-viewer:6416): GSpice-WARNING **: main-1:0: SSL_connect:
> error:0001:lib(0):func(0):reason(1)
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:2591 main-1:0:
> Coroutine exit main-1:0
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:2784 main-1:0:
> reset 
> (remote-viewer:6416): GSpice-DEBUG: channel-main.c:1537 agent
> connected: no
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:2726 main-1:0:
> channel reset
> (remote-viewer:6416): GSpice-DEBUG: spice-channel.c:2337 main-1:0:
> Delayed unref channel 0x206e400
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:1930 session:
> disconnecting 0
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:285 New session
> (compiled from package spice-gtk 0.33)
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:289 Supported
> channels: main, display, inputs, cursor, playback, record,
> smartcard, usbredir
> (remote-viewer:6416): GSpice-DEBUG: usb-device-manager.c:523 auto-
> connect filter set to 0x03,-1,-1,-1,0|-1,-1,-1,-1,1
> (remote-viewer:6416): GSpice-DEBUG: spice-session.c:1930 session:
> disconnecting 0
> 
> If I downgrade again to:
> spice-glib-0.33-3-x86_64.pkg.tar.xz  - then the problem dissappears.
> 
> Here is log from working library:
> 
> (remote-viewer:6511): GSpice-DEBUG: spice-session.c:2133 (with proxy
> http://10.0.10.10:3128)
> (remote-viewer:6511): GSpice-DEBUG: spice-session.c:2057 proxy
> lookup ready
> (remote-viewer:6511): GSpice-DEBUG: spice-session.c:2040 inputs-3:0: 
> connecting 0x7f4805ffcb40...
> (remote-viewer:6511): GSpice-DEBUG: spice-session.c:2057 proxy
> lookup ready
> (remote-viewer:6511): GSpice-DEBUG: spice-session.c:2040 cursor-4:0: 
> connecting 0x7f47e7ffeb40...
> (remote-viewer:6511): GSpice-DEBUG: spice-session.c:2024 inputs-3:0: 
> connect ready
> (remote-viewer:6511): GSpice-DEBUG: spice-channel.c:2379 inputs-3:0: 
> Load CA, file: (null), data: 0x13f9830
> (remote-viewer:6511): GSpice-DEBUG: spice-session.c:2024 cursor-4:0: 
> 

Re: [Spice-devel] [PATCH spice-gtk] usb-device-widget: Remove deprecated GTK_MISC

[Pavel Grunt]

On Fri, 2017-06-23 at 11:39 -0400, Frediano Ziglio wrote:
> > 
> > ---
> >  src/usb-device-widget.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
> > index e87bdff..2d07468 100644
> > --- a/src/usb-device-widget.c
> > +++ b/src/usb-device-widget.c
> > @@ -208,7 +208,7 @@ static GObject
> > *spice_usb_device_widget_constructor(
> >  str = g_strdup_printf("%s", _("Select USB devices to
> > redirect"));
> >  gtk_label_set_markup(GTK_LABEL (priv->label), str);
> >  g_free(str);
> > -gtk_misc_set_alignment(GTK_MISC(priv->label), 0.0, 0.5);
> > +g_object_set(G_OBJECT(priv->label), "xalign", 0.0, "yalign",
> > 0.5, NULL);
> >  gtk_container_add(GTK_CONTAINER(self), priv->label);
> >  
> >  priv->manager = spice_usb_device_manager_get(priv->session,
> > );
> 
> Why not using gtk_label_set_xalign/gtk_label_set_yalign ?

I followed the documentation:
"gtk_misc_set_alignment has been deprecated since version 3.14 and
should not be used in newly-written code.
Use GtkWidget's alignment (“halign” and “valign”) and margin
properties or GtkLabel's “xalign” and “yalign” properties."

Pavel

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

[Spice-devel] [PATCH spice-gtk] usb-device-widget: Remove deprecated GTK_MISC

[Pavel Grunt]

---
 src/usb-device-widget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
index e87bdff..2d07468 100644
--- a/src/usb-device-widget.c
+++ b/src/usb-device-widget.c
@@ -208,7 +208,7 @@ static GObject *spice_usb_device_widget_constructor(
 str = g_strdup_printf("%s", _("Select USB devices to redirect"));
 gtk_label_set_markup(GTK_LABEL (priv->label), str);
 g_free(str);
-gtk_misc_set_alignment(GTK_MISC(priv->label), 0.0, 0.5);
+g_object_set(G_OBJECT(priv->label), "xalign", 0.0, "yalign", 0.5, NULL);
 gtk_container_add(GTK_CONTAINER(self), priv->label);
 
 priv->manager = spice_usb_device_manager_get(priv->session, );
-- 
2.13.0

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

[Spice-devel] [PATCH spice-gtk] usb-device-widget: Migrate to GtkContainer api

[Pavel Grunt]

GtkVBox is deprecated since Gtk 3.2, GtkBox is going to be
deprecated. Switch to GtkContainer api if possible.
---
 src/usb-device-widget.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
index b394499..e87bdff 100644
--- a/src/usb-device-widget.c
+++ b/src/usb-device-widget.c
@@ -40,14 +40,14 @@
 
 struct _SpiceUsbDeviceWidget
 {
-GtkVBox parent;
+GtkBox parent;
 
 SpiceUsbDeviceWidgetPrivate *priv;
 };
 
 struct _SpiceUsbDeviceWidgetClass
 {
-GtkVBoxClass parent_class;
+GtkBoxClass parent_class;
 
 /* signals */
 void (*connect_failed) (SpiceUsbDeviceWidget *widget,
@@ -168,15 +168,16 @@ 
spice_usb_device_widget_show_info_bar(SpiceUsbDeviceWidget *self,
 
 widget = gtk_image_new_from_icon_name(stock_icon_id,
   GTK_ICON_SIZE_SMALL_TOOLBAR);
-gtk_box_pack_start(GTK_BOX(hbox), widget, FALSE, FALSE, 0);
+gtk_container_add(GTK_CONTAINER(hbox), widget);
 
 widget = gtk_label_new(message);
-gtk_box_pack_start(GTK_BOX(hbox), widget, TRUE, TRUE, 0);
+g_object_set(G_OBJECT(widget), "expand", TRUE, NULL);
+gtk_container_add(GTK_CONTAINER(hbox), widget);
 
 priv->info_bar = gtk_alignment_new(0.0, 0.0, 1.0, 0.0);
 gtk_alignment_set_padding(GTK_ALIGNMENT(priv->info_bar), 0, 0, 12, 0);
 gtk_container_add(GTK_CONTAINER(priv->info_bar), info_bar);
-gtk_box_pack_start(GTK_BOX(self), priv->info_bar, FALSE, FALSE, 0);
+gtk_container_add(GTK_CONTAINER(self), priv->info_bar);
 gtk_widget_show_all(priv->info_bar);
 }
 
@@ -208,7 +209,7 @@ static GObject *spice_usb_device_widget_constructor(
 gtk_label_set_markup(GTK_LABEL (priv->label), str);
 g_free(str);
 gtk_misc_set_alignment(GTK_MISC(priv->label), 0.0, 0.5);
-gtk_box_pack_start(GTK_BOX(self), priv->label, FALSE, FALSE, 0);
+gtk_container_add(GTK_CONTAINER(self), priv->label);
 
 priv->manager = spice_usb_device_manager_get(priv->session, );
 if (err) {
@@ -572,7 +573,7 @@ static void device_added_cb(SpiceUsbDeviceManager *manager,
 align = gtk_alignment_new(0, 0, 0, 0);
 gtk_alignment_set_padding(GTK_ALIGNMENT(align), 0, 0, 12, 0);
 gtk_container_add(GTK_CONTAINER(align), check);
-gtk_box_pack_end(GTK_BOX(self), align, FALSE, FALSE, 0);
+gtk_container_add(GTK_CONTAINER(self), align);
 spice_usb_device_widget_update_status(self);
 gtk_widget_show_all(align);
 }
-- 
2.13.0

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

Re: [Spice-devel] can't drag windows after virt-viewer upgrade

[Pavel Grunt]

On Fri, 2017-06-23 at 13:46 +0200, Daniel Pocock wrote:
> 
> On 23/06/17 13:33, Pavel Grunt wrote:
> > On Fri, 2017-06-23 at 12:55 +0200, Daniel Pocock wrote:
> > > I recently updated a Debian system, here are the new and old
> > > versions of
> > > each package from dpkg.log
> > > 
> > > upgrade virt-viewer:amd64 1.0-1 5.0-1
> > > upgrade virt-manager:all 1:1.0.1-5 1:1.4.0-5
> > > upgrade spice-client-gtk:amd64 0.25-1+b1 0.33-3.3
> > > upgrade libspice-client-glib-2.0-8:amd64 0.25-1+b1 0.33-3.3
> > > 
> > > 
> > > I connected to an existing session where GNOME 3 is running in a
> > > guest
> > > and I found that I can't drag and drop the windows any more and
> > > I
> > > can't
> > > click the "Activities" control.  Clicking other things on the
> > > top-
> > > bar
> > > (e.g. the clock) behaves normally.
> > 
> > In the guest? What do you mean by 'drag and drop the windows' ?
> > 
> 
> I point at the title bar of a window in the guest, I press the
> mouse button and try to move the window around in the guest desktop.
> 
> I try double clicking a window title bar and the window maximizes
> successfully.
> 
> Other controls for resizing a window (dragging the border) are not
> successful.
> 
> > > 
> > > I am connecting over ssh
> > > 
> > > Is this a known problem?
> > 
> > it is not. Wayland guest or client? (afaik X forwarding does not
> > work
> > in wayland)
> > 
> 
> 
> The guest is Debian jessie with Xorg
> 
> The client system is Debian stretch where the default is Xwayland
> now.
> I just modified /etc/gdm3/daemon.conf to uncomment this line:
> 
> WaylandEnable=false
> 
> and it restarted with Xorg instead of Xwayland but that didn't
> resolve
> the issue.
> 
> The release notes mention a change from evdev to libinput too, could
> that be relevant to the client?

hmmm. Do you have spice-vdagent running in the guest? spicy has an
option to change the mouse mode (Options -> Toggle mouse mode) - does
it change anything?

> 
> I also opened a Debian bug[2]

Does the old version of spice-gtk and virt-viewer work fine? 

Thanks,
Pavel

> 
> Regards,
> 
> Daniel
> 
> 1.
> https://www.debian.org/releases/stretch/i386/release-notes/ch-inform
> ation.en.html#default-xorg-input-driver-libinput
> 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865633
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] can't drag windows after virt-viewer upgrade

[Pavel Grunt]

On Fri, 2017-06-23 at 12:55 +0200, Daniel Pocock wrote:
> I recently updated a Debian system, here are the new and old
> versions of
> each package from dpkg.log
> 
> upgrade virt-viewer:amd64 1.0-1 5.0-1
> upgrade virt-manager:all 1:1.0.1-5 1:1.4.0-5
> upgrade spice-client-gtk:amd64 0.25-1+b1 0.33-3.3
> upgrade libspice-client-glib-2.0-8:amd64 0.25-1+b1 0.33-3.3
> 
> 
> I connected to an existing session where GNOME 3 is running in a
> guest
> and I found that I can't drag and drop the windows any more and I
> can't
> click the "Activities" control.  Clicking other things on the top-
> bar
> (e.g. the clock) behaves normally.

In the guest? What do you mean by 'drag and drop the windows' ?

> 
> I am connecting over ssh
> 
> Is this a known problem?

it is not. Wayland guest or client? (afaik X forwarding does not work
in wayland)

Thanks,
Pavel

> 
> Regards,
> 
> Daniel
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-html5 v2 4/4] Display: Add support for the VP9 codec type

[Pavel Grunt]

From: Tomáš Bohdálek 

---
v2: Be consistent with '=='/'===' in the expressions
---
 display.js   | 26 --
 spiceconn.js |  2 ++
 webm.js  | 12 ++--
 3 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/display.js b/display.js
index 0868f91..abd5b1a 100644
--- a/display.js
+++ b/display.js
@@ -543,7 +543,8 @@ SpiceDisplayConn.prototype.process_channel_message = 
function(msg)
 else
 this.streams[m.id] = m;
 
-if (m.codec_type == SPICE_VIDEO_CODEC_TYPE_VP8)
+if (m.codec_type == SPICE_VIDEO_CODEC_TYPE_VP8 ||
+m.codec_type == SPICE_VIDEO_CODEC_TYPE_VP9)
 {
 var media = new MediaSource();
 var v = document.createElement("video");
@@ -606,7 +607,8 @@ SpiceDisplayConn.prototype.process_channel_message = 
function(msg)
 if (this.streams[m.base.id].codec_type === 
SPICE_VIDEO_CODEC_TYPE_MJPEG)
 process_mjpeg_stream_data(this, m, time_until_due);
 
-if (this.streams[m.base.id].codec_type === SPICE_VIDEO_CODEC_TYPE_VP8)
+if (this.streams[m.base.id].codec_type === SPICE_VIDEO_CODEC_TYPE_VP8 
||
+this.streams[m.base.id].codec_type === SPICE_VIDEO_CODEC_TYPE_VP9)
 process_video_stream_data(this.streams[m.base.id], m);
 
 return true;
@@ -640,7 +642,8 @@ SpiceDisplayConn.prototype.process_channel_message = 
function(msg)
 var m = new SpiceMsgDisplayStreamDestroy(msg.data);
 STREAM_DEBUG > 0 && console.log(this.type + ": MsgStreamDestroy id" + 
m.id);
 
-if (this.streams[m.id].codec_type == SPICE_VIDEO_CODEC_TYPE_VP8)
+if (this.streams[m.id].codec_type == SPICE_VIDEO_CODEC_TYPE_VP8 ||
+this.streams[m.id].codec_type == SPICE_VIDEO_CODEC_TYPE_VP9)
 {
 
document.getElementById(this.parent.screen_id).removeChild(this.streams[m.id].video);
 this.streams[m.id].source_buffer = null;
@@ -1036,14 +1039,24 @@ function handle_video_source_open(e)
 {
 var stream = this.stream;
 var p = this.spiceconn;
+var codec_type;
 
 if (stream.source_buffer)
 return;
 
-var s = this.addSourceBuffer(SPICE_VP8_CODEC);
+if (this.stream.codec_type == SPICE_VIDEO_CODEC_TYPE_VP8)
+{
+codec_type = SPICE_VP8_CODEC;
+}
+else
+{
+codec_type = SPICE_VP9_CODEC;
+}
+
+var s = this.addSourceBuffer(codec_type);
 if (! s)
 {
-p.log_err('Codec ' + SPICE_VP8_CODEC + ' not available.');
+p.log_err('Codec ' + codec_type + ' not available.');
 return;
 }
 
@@ -1054,7 +1067,8 @@ function handle_video_source_open(e)
 listen_for_video_events(stream);
 
 var h = new webm_Header();
-var te = new webm_VideoTrackEntry(this.stream.stream_width, 
this.stream.stream_height);
+var te = new webm_VideoTrackEntry(this.stream.stream_width, 
this.stream.stream_height,
+  this.stream.codec_type);
 var t = new webm_Tracks(te);
 
 var mb = new ArrayBuffer(h.buffer_size() + t.buffer_size())
diff --git a/spiceconn.js b/spiceconn.js
index d76f8e2..72b7934 100644
--- a/spiceconn.js
+++ b/spiceconn.js
@@ -147,6 +147,8 @@ SpiceConn.prototype =
 (1 << SPICE_DISPLAY_CAP_CODEC_MJPEG);
 if ('MediaSource' in window && 
MediaSource.isTypeSupported(SPICE_VP8_CODEC))
 caps |= (1 << SPICE_DISPLAY_CAP_CODEC_VP8);
+if ('MediaSource' in window && 
MediaSource.isTypeSupported(SPICE_VP9_CODEC))
+caps |= (1 << SPICE_DISPLAY_CAP_CODEC_VP9);
 msg.channel_caps.push(caps);
 }
 
diff --git a/webm.js b/webm.js
index 789da14..c697135 100644
--- a/webm.js
+++ b/webm.js
@@ -88,6 +88,7 @@ var EXPECTED_PACKET_DURATION= 10;
 var GAP_DETECTION_THRESHOLD = 50;
 
 var SPICE_VP8_CODEC = 'video/webm; codecs="vp8"';
+var SPICE_VP9_CODEC = 'video/webm; codecs="vp9"';
 
 /*
 **  EBML utility functions
@@ -467,7 +468,7 @@ webm_AudioTrackEntry.prototype =
 },
 }
 
-function webm_VideoTrackEntry(width, height)
+function webm_VideoTrackEntry(width, height, codec_type)
 {
 this.id = WEBM_TRACK_ENTRY;
 this.number = 1;
@@ -482,8 +483,15 @@ function webm_VideoTrackEntry(width, height)
 this.codec_decode_all = 0; // fixme - check
 this.seek_pre_roll = 0; // 8000; // fixme - check
 this.codec_delay =   8000; // Must match codec_private.preskip
-this.codec_id = "V_VP8";
 this.video = new webm_Video(width, height);
+if (codec_type == SPICE_VIDEO_CODEC_TYPE_VP8)
+{
+this.codec_id = "V_VP8";
+}
+else
+{
+this.codec_id = "V_VP9";
+}
 }
 
 webm_VideoTrackEntry.prototype =
-- 
2.13.0

___
Spice-devel mailing list

Re: [Spice-devel] [PATCH spice-gtk v3] main: Handle file-xfer detailed errors

[Pavel Grunt]

On Tue, 2017-06-06 at 23:23 +0200, Jakub Janků wrote:
> Log appropriate error messages when we receive
> VD_AGENT_FILE_XFER_STATUS_SESSION_LOCKED,
> VD_AGENT_FILE_XFER_STATUS_VDAGENT_NOT_CONNECTED,
> VD_AGENT_FILE_XFER_STATUS_DISABLED.

Acked-by: Pavel Grunt <pgr...@redhat.com>

Thanks,
Pavel
> ---
>  src/channel-main.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/src/channel-main.c b/src/channel-main.c
> index af1350c..c1bbb89 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -1882,6 +1882,19 @@ static void
> main_agent_handle_xfer_status(SpiceMainChannel *channel,
>  g_free(file_size_str);
>  break;
>  }
> +case VD_AGENT_FILE_XFER_STATUS_SESSION_LOCKED:
> +error = g_error_new_literal(SPICE_CLIENT_ERROR,
> SPICE_CLIENT_ERROR_FAILED,
> +_("User's session is locked and
> cannot transfer files, "
> +  "unlock it and try again."));
> +break;
> +case VD_AGENT_FILE_XFER_STATUS_VDAGENT_NOT_CONNECTED:
> +error = g_error_new_literal(SPICE_CLIENT_ERROR,
> SPICE_CLIENT_ERROR_FAILED,
> +_("Session agent not
> connected."));
> +break;
> +case VD_AGENT_FILE_XFER_STATUS_DISABLED:
> +error = g_error_new_literal(SPICE_CLIENT_ERROR,
> SPICE_CLIENT_ERROR_FAILED,
> +_("File transfer is
> disabled."));
> +break;
>  case VD_AGENT_FILE_XFER_STATUS_SUCCESS:
>  break;
>  default:
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] download: Add x11spice

[Pavel Grunt]

On Thu, 2017-06-22 at 09:22 +0300, Snir Sheriber wrote:
> 
> On 06/22/2017 12:38 AM, Jeremy White wrote:
> > > > Alright, it's up on gitlab now:
> > > >https://gitlab.com/spice/x11spice
> > > > 
> > > > Looks like there isn't any obvious way for me to ask to edit
> > > > the
> > > > pages; I was going to point to this link as a release file:
> > > >https://gitlab.com/spice/x11spice/repository/archive.tar.bz
> > > > 2?ref=v1.1
> > > 
> > > Thanks!
> > > 
> > > The pages are here
> > > https://gitlab.com/spice/spice-space-pages
> > 
> > I fumbled my way through this.  I couldn't figure out how to get
> > pelican
> > to run on my box to do this as I would prefer, and then ended up
> > doing
> > it all online.  Creepy.  If you're not doing a  is it
> > really development?
> 
> Probably not :) but i guess git send-email to here it fine too.
> > In the process, I fumbled and overlooked your patch Snir; that was
> > my
> > mistake.  I think the change I made is fundamentally the same -
> > I'm not
> > sure who is processing pull requests, but in theory, I have one
> > hanging
> > out there for this change.
> > 
> > Sorry for creating confusion on this.
> 
> Seems like the request is from the wiki branch, anyway i would just
> add the link to the release under the "x11spice" , if it's ok with
> you.
> 

Hi,

I've cherry-picked your patch from the wiki branch to the master
branch. The website will be updated automatically in few minutes.

Thanks,
Pavel


> Thanks
> > 
> > Cheers,
> > 
> > Jeremy
> > 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-html5 4/4] Display: Add support for the VP9 codec type

[Pavel Grunt]

Hi, sure. I'll change it to '==='

(I think in this case it does not matter - it's comparing ints not objects,
but as you said, we should be consistent)

On Tue, Jun 20, 2017 at 10:44 PM, Jeremy White <jwh...@codeweavers.com>
wrote:

> Hi,
>
> One tiny niggle:
>
> On 06/08/2017 09:27 AM, Pavel Grunt wrote:
> > @@ -606,7 +607,8 @@ SpiceDisplayConn.prototype.process_channel_message
> = function(msg)
> >  if (this.streams[m.base.id].codec_type ===
> SPICE_VIDEO_CODEC_TYPE_MJPEG)
> >  process_mjpeg_stream_data(this, m, time_until_due);
> >
> > -if (this.streams[m.base.id].codec_type ===
> SPICE_VIDEO_CODEC_TYPE_VP8)
> > +if (this.streams[m.base.id].codec_type ===
> SPICE_VIDEO_CODEC_TYPE_VP8 ||
> > +this.streams[m.base.id].codec_type ==
> SPICE_VIDEO_CODEC_TYPE_VP9)
> >  process_video_stream_data(this.streams[m.base.id], m);
> >
> >  return true;
>
> The original author of this code did a poor job of deciding whether or
> not to use '===' everywhere or whether to use '=='.  There appears to be
> some debate, with the consensus being that '===' is often more
> appropriate.  Sadly, this code base mixes the two, and mostly uses '=='.
>
> I'd ask that this if statement be at least internally consistent.  I
> don't know that it is clear to me whether it should be '==' or '==='.
>
> Cheers,
>
> Jeremy
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk v2] Unrealize egl display only if it has context

[Pavel Grunt]

Avoids a critical to be logged when closing remote-viewer:
 "gl_make_current: assertion 'd->egl.context_ready' failed"
---
 src/spice-widget.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/spice-widget.c b/src/spice-widget.c
index 139510d..c335083 100644
--- a/src/spice-widget.c
+++ b/src/spice-widget.c
@@ -2161,7 +2161,8 @@ static void unrealize(GtkWidget *widget)
 {
 spice_cairo_image_destroy(SPICE_DISPLAY(widget));
 #if HAVE_EGL
-spice_egl_unrealize_display(SPICE_DISPLAY(widget));
+if (SPICE_DISPLAY(widget)->priv->egl.context_ready)
+spice_egl_unrealize_display(SPICE_DISPLAY(widget));
 #endif
 
 GTK_WIDGET_CLASS(spice_display_parent_class)->unrealize(widget);
-- 
2.13.0

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

Re: [Spice-devel] [PATCH spice-gtk] Allow to build without X11 gdk backend

[Pavel Grunt]

On Mon, 2017-06-19 at 10:06 -0400, Frediano Ziglio wrote:
> Question: can GDK have no X11?
chances are low but there may be a distro shipping gtk without the x11
backend

> I suppose only wayland compiled in?
or win32 or quartz (macOS).

The issue I noticed was in egl - which can work with wayland or X11

Pavel

> 
> > 
> > ---
> >  src/spice-gtk-session.c |  2 +-
> >  src/spice-widget-egl.c  | 14 +-
> >  src/spice-widget.c  |  2 +-
> >  3 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > index 33db3c8..e338ce6 100644
> > --- a/src/spice-gtk-session.c
> > +++ b/src/spice-gtk-session.c
> > @@ -18,10 +18,10 @@
> >  #include "config.h"
> >  
> >  #include 
> > +#include 
> >  
> >  #ifdef HAVE_X11_XKBLIB_H
> >  #include 
> > -#include 
> >  #endif
> >  #ifdef GDK_WINDOWING_X11
> >  #include 
> > diff --git a/src/spice-widget-egl.c b/src/spice-widget-egl.c
> > index 7c21113..b50641c 100644
> > --- a/src/spice-widget-egl.c
> > +++ b/src/spice-widget-egl.c
> > @@ -18,6 +18,7 @@
> >  #include "config.h"
> >  
> >  #include 
> > +#include 
> >  
> >  #define EGL_EGLEXT_PROTOTYPES
> >  #define GL_GLEXT_PROTOTYPES
> > @@ -27,7 +28,9 @@
> >  #include "spice-gtk-session-priv.h"
> >  #include 
> >  
> > +#ifdef GDK_WINDOWING_X11
> >  #include 
> > +#endif
> >  #ifdef GDK_WINDOWING_WAYLAND
> >  #include 
> >  #endif
> > @@ -291,6 +294,7 @@ gl_make_current(SpiceDisplay *display, GError
> > **err)
> >  
> >  g_return_val_if_fail(d->egl.context_ready, FALSE);
> >  
> > +#ifdef GDK_WINDOWING_X11
> >  if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
> >  EGLBoolean success = eglMakeCurrent(d->egl.display,
> >  d->egl.surface,
> > @@ -303,8 +307,12 @@ gl_make_current(SpiceDisplay *display, GError
> > **err)
> >  return FALSE;
> >  }
> >  }
> > +#endif
> >  #if GTK_CHECK_VERSION(3,16,0)
> > -else {
> > +#ifdef GDK_WINDOWING_X11
> > +else
> > +#endif
> > +{
> >  /* Ignore GLib's too-new warnings */
> >  G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> >  GtkWidget *area = gtk_stack_get_child_by_name(d->stack,
> > "gl-area");
> > @@ -402,6 +410,7 @@ void spice_egl_unrealize_display(SpiceDisplay
> > *display)
> >  d->egl.prog = 0;
> >  }
> >  
> > +#ifdef GDK_WINDOWING_X11
> >  if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
> >  /* egl.surface && egl.ctx are only created on x11, see
> > spice_egl_init() */
> > @@ -422,6 +431,7 @@ void spice_egl_unrealize_display(SpiceDisplay
> > *display)
> >  /* do not call eglterminate() since egl may be used by
> >   * somebody else code */
> >  }
> > +#endif
> >  }
> >  
> >  G_GNUC_INTERNAL
> > @@ -619,10 +629,12 @@ void spice_egl_update_display(SpiceDisplay
> > *display)
> >   0, 0, 1, 1);
> >  }
> >  
> > +#ifdef GDK_WINDOWING_X11
> >  if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
> >  /* gtk+ does the swap with gtkglarea */
> >  eglSwapBuffers(d->egl.display, d->egl.surface);
> >  }
> > +#endif
> >  
> >  glUseProgram(prog);
> >  }
> > diff --git a/src/spice-widget.c b/src/spice-widget.c
> > index 386724d..139510d 100644
> > --- a/src/spice-widget.c
> > +++ b/src/spice-widget.c
> > @@ -19,10 +19,10 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #ifdef HAVE_X11_XKBLIB_H
> >  #include 
> > -#include 
> >  #endif
> >  #ifdef GDK_WINDOWING_X11
> >  #include 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] Allow to build without X11 gdk backend

[Pavel Grunt]

Hi,

On Mon, 2017-06-19 at 10:05 -0400, Marc-André Lureau wrote:
> Hi, 
> 
> looks fine, how did you reproduce a build issue and make sure it
> fixed it?
> 
I noticed an "unguarded" usage of GDK_IS_X11_DISPLAY(), so i built
gtk+ enabling only the wayland backend (and add the guards where
needed).

what may not be so obvious, it's needed to add
  #include 
because it contains GDK_WINDOWING_* defines


> - Original Message -
> > ---
> >  src/spice-gtk-session.c |  2 +-
> >  src/spice-widget-egl.c  | 14 +-
> >  src/spice-widget.c  |  2 +-
> >  3 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > index 33db3c8..e338ce6 100644
> > --- a/src/spice-gtk-session.c
> > +++ b/src/spice-gtk-session.c
> > @@ -18,10 +18,10 @@
> >  #include "config.h"
> >  
> >  #include 
> > +#include 
> >  
> >  #ifdef HAVE_X11_XKBLIB_H
> >  #include 
> > -#include 
> >  #endif
> >  #ifdef GDK_WINDOWING_X11
> >  #include 
> > diff --git a/src/spice-widget-egl.c b/src/spice-widget-egl.c
> > index 7c21113..b50641c 100644
> > --- a/src/spice-widget-egl.c
> > +++ b/src/spice-widget-egl.c
> > @@ -18,6 +18,7 @@
> >  #include "config.h"
> >  
> >  #include 
> > +#include 
> >  
> >  #define EGL_EGLEXT_PROTOTYPES
> >  #define GL_GLEXT_PROTOTYPES
> > @@ -27,7 +28,9 @@
> >  #include "spice-gtk-session-priv.h"
> >  #include 
> >  
> > +#ifdef GDK_WINDOWING_X11
> >  #include 
> > +#endif
> >  #ifdef GDK_WINDOWING_WAYLAND
> >  #include 
> >  #endif
> > @@ -291,6 +294,7 @@ gl_make_current(SpiceDisplay *display, GError
> > **err)
> >  
> >  g_return_val_if_fail(d->egl.context_ready, FALSE);
> >  
> > +#ifdef GDK_WINDOWING_X11
> >  if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
> >  EGLBoolean success = eglMakeCurrent(d->egl.display,
> >  d->egl.surface,
> > @@ -303,8 +307,12 @@ gl_make_current(SpiceDisplay *display, GError
> > **err)
> >  return FALSE;
> >  }
> >  }
> > +#endif
> >  #if GTK_CHECK_VERSION(3,16,0)
> > -else {
> > +#ifdef GDK_WINDOWING_X11
> > +else
> > +#endif
> > +{
> >  /* Ignore GLib's too-new warnings */
> >  G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> >  GtkWidget *area = gtk_stack_get_child_by_name(d->stack,
> > "gl-area");
> > @@ -402,6 +410,7 @@ void spice_egl_unrealize_display(SpiceDisplay
> > *display)
> >  d->egl.prog = 0;
> >  }
> >  
> > +#ifdef GDK_WINDOWING_X11
> >  if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
> >  /* egl.surface && egl.ctx are only created on x11, see
> > spice_egl_init() */
> > @@ -422,6 +431,7 @@ void spice_egl_unrealize_display(SpiceDisplay
> > *display)
> >  /* do not call eglterminate() since egl may be used by
> >   * somebody else code */
> >  }
> > +#endif
> >  }
> >  
> >  G_GNUC_INTERNAL
> > @@ -619,10 +629,12 @@ void spice_egl_update_display(SpiceDisplay
> > *display)
> >   0, 0, 1, 1);
> >  }
> >  
> > +#ifdef GDK_WINDOWING_X11
> >  if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
> >  /* gtk+ does the swap with gtkglarea */
> >  eglSwapBuffers(d->egl.display, d->egl.surface);
> >  }
> > +#endif
> >  
> >  glUseProgram(prog);
> >  }
> > diff --git a/src/spice-widget.c b/src/spice-widget.c
> > index 386724d..139510d 100644
> > --- a/src/spice-widget.c
> > +++ b/src/spice-widget.c
> > @@ -19,10 +19,10 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #ifdef HAVE_X11_XKBLIB_H
> >  #include 
> > -#include 
> >  #endif
> >  #ifdef GDK_WINDOWING_X11
> >  #include 
> > --
> > 2.13.0
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> > 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Allow to build without X11 gdk backend

[Pavel Grunt]

---
 src/spice-gtk-session.c |  2 +-
 src/spice-widget-egl.c  | 14 +-
 src/spice-widget.c  |  2 +-
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
index 33db3c8..e338ce6 100644
--- a/src/spice-gtk-session.c
+++ b/src/spice-gtk-session.c
@@ -18,10 +18,10 @@
 #include "config.h"
 
 #include 
+#include 
 
 #ifdef HAVE_X11_XKBLIB_H
 #include 
-#include 
 #endif
 #ifdef GDK_WINDOWING_X11
 #include 
diff --git a/src/spice-widget-egl.c b/src/spice-widget-egl.c
index 7c21113..b50641c 100644
--- a/src/spice-widget-egl.c
+++ b/src/spice-widget-egl.c
@@ -18,6 +18,7 @@
 #include "config.h"
 
 #include 
+#include 
 
 #define EGL_EGLEXT_PROTOTYPES
 #define GL_GLEXT_PROTOTYPES
@@ -27,7 +28,9 @@
 #include "spice-gtk-session-priv.h"
 #include 
 
+#ifdef GDK_WINDOWING_X11
 #include 
+#endif
 #ifdef GDK_WINDOWING_WAYLAND
 #include 
 #endif
@@ -291,6 +294,7 @@ gl_make_current(SpiceDisplay *display, GError **err)
 
 g_return_val_if_fail(d->egl.context_ready, FALSE);
 
+#ifdef GDK_WINDOWING_X11
 if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
 EGLBoolean success = eglMakeCurrent(d->egl.display,
 d->egl.surface,
@@ -303,8 +307,12 @@ gl_make_current(SpiceDisplay *display, GError **err)
 return FALSE;
 }
 }
+#endif
 #if GTK_CHECK_VERSION(3,16,0)
-else {
+#ifdef GDK_WINDOWING_X11
+else
+#endif
+{
 /* Ignore GLib's too-new warnings */
 G_GNUC_BEGIN_IGNORE_DEPRECATIONS
 GtkWidget *area = gtk_stack_get_child_by_name(d->stack, "gl-area");
@@ -402,6 +410,7 @@ void spice_egl_unrealize_display(SpiceDisplay *display)
 d->egl.prog = 0;
 }
 
+#ifdef GDK_WINDOWING_X11
 if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
 /* egl.surface && egl.ctx are only created on x11, see
spice_egl_init() */
@@ -422,6 +431,7 @@ void spice_egl_unrealize_display(SpiceDisplay *display)
 /* do not call eglterminate() since egl may be used by
  * somebody else code */
 }
+#endif
 }
 
 G_GNUC_INTERNAL
@@ -619,10 +629,12 @@ void spice_egl_update_display(SpiceDisplay *display)
  0, 0, 1, 1);
 }
 
+#ifdef GDK_WINDOWING_X11
 if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
 /* gtk+ does the swap with gtkglarea */
 eglSwapBuffers(d->egl.display, d->egl.surface);
 }
+#endif
 
 glUseProgram(prog);
 }
diff --git a/src/spice-widget.c b/src/spice-widget.c
index 386724d..139510d 100644
--- a/src/spice-widget.c
+++ b/src/spice-widget.c
@@ -19,10 +19,10 @@
 
 #include 
 #include 
+#include 
 
 #ifdef HAVE_X11_XKBLIB_H
 #include 
-#include 
 #endif
 #ifdef GDK_WINDOWING_X11
 #include 
-- 
2.13.0

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

Re: [Spice-devel] [PATCH spice-gtk] Do not unrealize disabled egl

[Pavel Grunt]

On Mon, 2017-06-19 at 06:00 -0400, Marc-André Lureau wrote:
> 
> - Original Message -
> > 
> > 
> > - Original Message -
> > > Avoids a critical to be logged when closing remote-viewer:
> > >  "gl_make_current: assertion 'd->egl.context_ready' failed"
> > 
> > ack, thanks
> 
> actually, why not check egl.context_ready?

In which cases you want to test the precondition added in
422572c37793bf6141bc58d441bcda37090c74f3 ?

>  (you might be switch back to 2d, and still have egl context to
> clean up)

Yes. (btw I am not sure the switch's worked - eg in rebooting)

Pavel
> 
> > 
> > > ---
> > >  src/spice-widget-egl.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/src/spice-widget-egl.c b/src/spice-widget-egl.c
> > > index 7c21113..5951ae6 100644
> > > --- a/src/spice-widget-egl.c
> > > +++ b/src/spice-widget-egl.c
> > > @@ -374,6 +374,9 @@ void
> > > spice_egl_unrealize_display(SpiceDisplay *display)
> > >  
> > >  DISPLAY_DEBUG(display, "egl unrealize %p", d->egl.surface);
> > >  
> > > +if (!d->egl.enabled)
> > > +return;
> > > +
> > >  if (!gl_make_current(display, NULL))
> > >  return;
> > >  
> > > --
> > > 2.13.0
> > > 
> > > ___
> > > Spice-devel mailing list
> > > Spice-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Do not unrealize disabled egl

[Pavel Grunt]

Avoids a critical to be logged when closing remote-viewer:
 "gl_make_current: assertion 'd->egl.context_ready' failed"
---
 src/spice-widget-egl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/spice-widget-egl.c b/src/spice-widget-egl.c
index 7c21113..5951ae6 100644
--- a/src/spice-widget-egl.c
+++ b/src/spice-widget-egl.c
@@ -374,6 +374,9 @@ void spice_egl_unrealize_display(SpiceDisplay *display)
 
 DISPLAY_DEBUG(display, "egl unrealize %p", d->egl.surface);
 
+if (!d->egl.enabled)
+return;
+
 if (!gl_make_current(display, NULL))
 return;
 
-- 
2.13.0

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

Re: [Spice-devel] [PATCH spice-protocol v3] agent: Add new file-xfer statuses

[Pavel Grunt]

On Tue, 2017-06-06 at 23:21 +0200, Jakub Janků wrote:
> Introduce new error statuses to report more info to clients:
> VD_AGENT_FILE_XFER_STATUS_SESSION_LOCKED,
> VD_AGENT_FILE_XFER_STATUS_VDAGENT_NOT_CONNECTED,
> VD_AGENT_FILE_XFER_STATUS_DISABLED
> 
> These are only sent to clients that feature
> VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS capability.

Acked-by: Pavel Grunt <pgr...@redhat.com>

Thanks!
Pavel

> ---
>  spice/vd_agent.h | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/spice/vd_agent.h b/spice/vd_agent.h
> index 2a168d0..7109ede 100644
> --- a/spice/vd_agent.h
> +++ b/spice/vd_agent.h
> @@ -100,6 +100,9 @@ enum {
>  VD_AGENT_FILE_XFER_STATUS_ERROR,
>  VD_AGENT_FILE_XFER_STATUS_SUCCESS,
>  VD_AGENT_FILE_XFER_STATUS_NOT_ENOUGH_SPACE,
> +VD_AGENT_FILE_XFER_STATUS_SESSION_LOCKED,
> +VD_AGENT_FILE_XFER_STATUS_VDAGENT_NOT_CONNECTED,
> +VD_AGENT_FILE_XFER_STATUS_DISABLED,
>  };
>  
>  typedef struct SPICE_ATTR_PACKED VDAgentFileXferStatusMessage {
> @@ -108,8 +111,11 @@ typedef struct SPICE_ATTR_PACKED
> VDAgentFileXferStatusMessage {
> /* Used to send additional data for detailed error messages
>  * to clients with VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS
> capability.
>  * Type of data varies with the result:
> -* result : data type
> +* result : data type (NULL if no data)
>  * VD_AGENT_FILE_XFER_STATUS_NOT_ENOUGH_SPACE : uint64_t
> +* VD_AGENT_FILE_XFER_STATUS_SESSION_LOCKED : NULL
> +* VD_AGENT_FILE_XFER_STATUS_VDAGENT_NOT_CONNECTED : NULL
> +* VD_AGENT_FILE_XFER_STATUS_DISABLED : NULL
>  */
> uint8_t data[0];
>  } VDAgentFileXferStatusMessage;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v2] gitignore: Reduce html files exclusion

[Pavel Grunt]

Hi,

On Sun, 2017-06-18 at 05:06 -0400, Frediano Ziglio wrote:
> ping

no reply to Uri's questions?

> 
> - Original Message -
> > From: "Uri Lublin" 
> > To: "Frediano Ziglio" , spice-de...@lists.free
> > desktop.org
> > Sent: Thursday, January 26, 2017 1:22:39 PM
> > Subject: Re: [Spice-devel] [PATCH spice-server v2] gitignore:
> > Reduce html files exclusion
> > 
> > On 01/26/2017 12:52 PM, Frediano Ziglio wrote:
> > > ping
> > > 
> > > > 
> > > > Limit the html files ignored.
> > > > Can happen that you are working on some html files on your
> > > > main
> > > > spice-server directory and it's not desirable to ignore them.
> > 
> > Hi Frediano,
> > 
> > How can that happen ?  What html files one may work on ?
> > 
> > I'd add in the commit log that html files under docs/ are still
> > ignored (be more specific with above "Limit").
> > 
> > Uri.
> > 
> > 
> > > > 
> > > > Signed-off-by: Frediano Ziglio 
> > > > ---
> > > >  .gitignore | 3 +--
> > > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > > 
> > > > Changes since v1:
> > > > - remove redundant ignore;
> > > > - move exclusion to get better order.
> > > > 
> > > > diff --git a/.gitignore b/.gitignore
> > > > index cac10f9..85f922b 100644
> > > > --- a/.gitignore
> > > > +++ b/.gitignore
> > > > @@ -4,7 +4,6 @@
> > > >  *.tar.bz2
> > > >  *.tar.gz
> > > >  *.pyc
> > > > -*.html
> > > >  aclocal.m4
> > > >  autom4te.cache
> > > >  compile
> > > > @@ -34,7 +33,7 @@ INSTALL
> > > >  .version
> > > >  .tarball-version
> > > >  docs/manual/manual.chunked/
> > > > -docs/manual/manual.html
> > > > +docs/**/*.html
> > > >  .dirstamp
> > > >  .deps
> > > >  .libs
> > > 
> > > ___
> > > Spice-devel mailing list
> > > Spice-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > 
> > 
> > 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-html5] cursor: Add support for mono cursor type

[Pavel Grunt]

From: Tomáš Bohdálek 

It is used by default on Windows system
---
 cursor.js| 18 ---
 png.js   |  2 +-
 spice.html   |  1 +
 spice_auto.html  |  1 +
 thirdparty/monocursor.js | 79 
 5 files changed, 96 insertions(+), 5 deletions(-)
 create mode 100644 thirdparty/monocursor.js

diff --git a/cursor.js b/cursor.js
index d3f4d55..1fb1ede 100644
--- a/cursor.js
+++ b/cursor.js
@@ -62,7 +62,8 @@ SpiceCursorConn.prototype.process_channel_message = 
function(msg)
 if (cursor_set.flags > 0)
 this.log_warn("FIXME: No support for cursor flags " + 
cursor_set.flags);
 
-if (cursor_set.cursor.header.type != SPICE_CURSOR_TYPE_ALPHA)
+if (cursor_set.cursor.header.type != SPICE_CURSOR_TYPE_ALPHA &&
+cursor_set.cursor.header.type != SPICE_CURSOR_TYPE_MONO)
 {
 this.log_warn("FIXME: No support for cursor type " + 
cursor_set.cursor.header.type);
 return false;
@@ -117,9 +118,18 @@ SpiceCursorConn.prototype.process_channel_message = 
function(msg)
 
 SpiceCursorConn.prototype.set_cursor = function(cursor)
 {
-var pngstr = create_rgba_png(cursor.header.height, cursor.header.width, 
cursor.data);
-var curstr = 'url(data:image/png,' + pngstr + ') ' +
-cursor.header.hot_spot_x + ' ' + cursor.header.hot_spot_y + ", 
default";
+var pngstr = null;
+if (cursor.header.type == SPICE_CURSOR_TYPE_ALPHA)
+{
+pngstr = create_rgba_png(cursor.header.height, cursor.header.width, 
cursor.data);
+}
+if (cursor.header.type == SPICE_CURSOR_TYPE_MONO)
+{
+pngstr = mono_cursor(cursor.header.height, cursor.header.width, 
cursor.data);
+}
+
+var curstr = 'url(' + pngstr + ') ' +
+cursor.header.hot_spot_x + ' ' + cursor.header.hot_spot_y + ", default";
 var screen = document.getElementById(this.parent.screen_id);
 screen.style.cursor = 'auto';
 screen.style.cursor = curstr;
diff --git a/png.js b/png.js
index 6a26151..5b52ed5 100644
--- a/png.js
+++ b/png.js
@@ -252,5 +252,5 @@ function create_rgba_png(width, height, bytes)
 }
 
 
-return "%89PNG%0D%0A%1A%0A" + str;
+return "data:image/png,%89PNG%0D%0A%1A%0A" + str;
 }
diff --git a/spice.html b/spice.html
index d4c9962..8c43dcb 100644
--- a/spice.html
+++ b/spice.html
@@ -54,6 +54,7 @@
 
 
 
+
 
 
 
diff --git a/spice_auto.html b/spice_auto.html
index 2f04fc9..10f5508 100644
--- a/spice_auto.html
+++ b/spice_auto.html
@@ -54,6 +54,7 @@
 
 
 
+
 
 
 
diff --git a/thirdparty/monocursor.js b/thirdparty/monocursor.js
new file mode 100644
index 000..5df6da9
--- /dev/null
+++ b/thirdparty/monocursor.js
@@ -0,0 +1,79 @@
+/*  Downloaded 1/6/2017 from 
https://github.com/eyeos/spice-web-client/blob/master/lib/graphic.js by Tomáš 
Bohdálek.
+
+License reproduce here for completeness:
+
+The MIT License (MIT)
+Copyright (c) 2016 eyeOS S.L.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy 
of this software and associated documentation files (the "Software"), to deal 
in the Software without restriction, including without limitation the rights to 
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies 
of the Software, and to permit persons to whom the Software is furnished to do 
so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all 
copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
+*/
+
+function mono_cursor(height, width, data)
+{
+var monoMask = [1, 2, 4, 8, 16, 32, 64, 128];
+var bytes = new Uint8Array(data);
+var length = bytes.length;
+var half = length / 2;
+
+var canvas = document.createElement("canvas");
+canvas.setAttribute('width', width);
+canvas.setAttribute('height', height);
+var context = canvas.getContext("2d");
+var result = context.createImageData(width, height);
+
+var andMask = [];
+var xorMask = [];
+
+for (var i = 0; i < length; i++) {
+var currentByte = bytes[i];
+var bitsLeft = 8;
+
+if (i >= half) {
+while (bitsLeft--) {
+var bit = (currentByte & monoMask[bitsLeft]) && true;
+andMask.push(bit);
+}
+} else if (i < half) {
+while (bitsLeft--) 

[Spice-devel] [PATCH spice-html5 v3] Add checkbox to toggle debug console

[Pavel Grunt]

From: Tomáš Bohdálek 

This allows show or hide debug console under spice screen.
---
v3: rebased after dropping the patch for checking the minimal height
---
 resize.js  | 16 ++--
 spice.html | 18 ++
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/resize.js b/resize.js
index b572de7..51fb1cc 100644
--- a/resize.js
+++ b/resize.js
@@ -39,8 +39,20 @@ function resize_helper(sc)
  at the bottom, and use the position of the message window
  to figure out how to resize */
 
-/* Show both div elements - spice-area and message-div */
-var h = window.innerHeight - m.offsetHeight - m.clientHeight - 20;
+var h = window.innerHeight - 20;
+
+/* Screen height based on debug console visibility  */
+if (window.getComputedStyle(m).getPropertyValue("display") == 'none')
+{
+/* Get console height from spice.css .spice-message */
+var mh = 
parseInt(window.getComputedStyle(m).getPropertyValue("height"), 10);
+h = h - mh;
+}
+else
+{
+/* Show both div elements - spice-area and message-div */
+h = h - m.offsetHeight - m.clientHeight;
+}
 
 
 /* Xorg requires height be a multiple of 8; round up */
diff --git a/spice.html b/spice.html
index d4c9962..7abfcff 100644
--- a/spice.html
+++ b/spice.html
@@ -143,6 +143,23 @@
 }
 }
 
+function toggle_console()
+{
+var checkbox = document.getElementById('show_console');
+var m = document.getElementById('message-div');
+
+if (checkbox.checked)
+{
+m.style.display = 'block';
+}
+else
+{
+m.style.display = 'none';
+}
+
+window.addEventListener('resize', handle_resize);
+resize_helper(sc);
+}
 /* SPICE port event listeners
 window.addEventListener('spice-port-data', function(event) {
 // Here we convert data to text, but really we can obtain 
binary data also
@@ -166,6 +183,7 @@
 Host:  
 Port: 
 Password: 
+Show console 
 Start
 
 
-- 
2.13.0

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

[Spice-devel] [PATCH spice-html5 1/4] spiceconn: Add function to test channel capabilities

[Pavel Grunt]

From: Tomáš Bohdálek 

This will be used in other commits.
---
 spiceconn.js | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/spiceconn.js b/spiceconn.js
index 33e7388..d76f8e2 100644
--- a/spiceconn.js
+++ b/spiceconn.js
@@ -243,6 +243,9 @@ SpiceConn.prototype =
 else if (this.state == "link")
 {
 this.reply_link = new SpiceLinkReply(mb);
+this.common_caps = this.reply_link.common_caps;
+this.channel_caps = this.reply_link.channel_caps;
+
  // FIXME - Screen the caps - require minihdr at least, right?
 if (this.reply_link.error)
 {
@@ -495,6 +498,22 @@ SpiceConn.prototype =
 var e = new Error("Connection timed out.");
 this.report_error(e);
 },
+
+test_capability: function(caps, cap)
+{
+var ret = (caps >> cap).toString(2) & 1;
+return ret;
+},
+
+channel_test_capability: function(cap)
+{
+return this.test_capability(this.channel_caps, cap);
+},
+
+channel_test_common_capability: function(cap)
+{
+return this.test_capability(this.common_caps, cap);
+}
 }
 
 function spiceconn_timeout(sc)
-- 
2.13.0

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