Re: [Spice-devel] [PATCH spice-gtk] gettext: fix ngettext usage

[Jakub Janku]

On Wed, Apr 17, 2019 at 5:25 PM Frediano Ziglio  wrote:
>
> >
> > _() should not be used in conjunction with ngettext(),
> > otherwise it's impossible to properly translate the message into
> > languages that have multiple plural forms, such as Czech.
> >
> > Fix ngettext usage in usb-device-widget.c and
> > update the PO files accordingly.
> >
> > Signed-off-by: Jakub Janků 
>
> Sounds good, I'll have a small try before.
>
> Can you review David Jaša patch sent on Apr 12th?

Sure, I've already started looking at it, that's how I discovered this issue.

Cheers,
Jakub
>
> > ---
> >  po/de.po|  9 +++--
> >  po/fr.po| 11 ---
> >  po/it.po| 12 +---
> >  src/usb-device-widget.c |  4 ++--
> >  4 files changed, 14 insertions(+), 22 deletions(-)
> >
> > diff --git a/po/de.po b/po/de.po
> > index eb24de7..3ae6ae0 100644
> > --- a/po/de.po
> > +++ b/po/de.po
> > @@ -288,12 +288,9 @@ msgstr "Auswahl des USB-Geräts zum Weiterleiten"
> >  #: src/usb-device-widget.c:393
> >  #, c-format
> >  msgid "Select USB devices to redirect (%d free channel)"
> > -msgstr "Auswahl des USB-Geräts zum Weiterleiten (%d freier Kanal)"
> > -
> > -#: src/usb-device-widget.c:394
> > -#, c-format
> > -msgid "Select USB devices to redirect (%d free channels)"
> > -msgstr "Auswahl des USB-Geräts zum Weiterleiten (%d freie Kanäle)"
> > +msgid_plural "Select USB devices to redirect (%d free channels)"
> > +msgstr[0] "Auswahl des USB-Geräts zum Weiterleiten (%d freier Kanal)"
> > +msgstr[1] "Auswahl des USB-Geräts zum Weiterleiten (%d freie Kanäle)"
> >
> >  #: src/usb-device-widget.c:411
> >  msgid "Redirecting USB Device..."
> > diff --git a/po/fr.po b/po/fr.po
> > index e2dd3ad..6120ee0 100644
> > --- a/po/fr.po
> > +++ b/po/fr.po
> > @@ -271,15 +271,12 @@ msgstr ""
> >  msgid "Select USB devices to redirect"
> >  msgstr ""
> >
> > -#: src/usb-device-widget.c:420
> > +#: src/usb-device-widget.c:393
> >  #, c-format
> >  msgid "Select USB devices to redirect (%d free channel)"
> > -msgstr ""
> > -
> > -#: src/usb-device-widget.c:421
> > -#, c-format
> > -msgid "Select USB devices to redirect (%d free channels)"
> > -msgstr ""
> > +msgid_plural "Select USB devices to redirect (%d free channels)"
> > +msgstr[0] ""
> > +msgstr[1] ""
> >
> >  #: src/usb-device-widget.c:439
> >  msgid "Redirecting USB Device..."
> > diff --git a/po/it.po b/po/it.po
> > index a4e40e9..b7899a8 100644
> > --- a/po/it.po
> > +++ b/po/it.po
> > @@ -16,6 +16,7 @@ msgstr ""
> >  "MIME-Version: 1.0\n"
> >  "Content-Type: text/plain; charset=UTF-8\n"
> >  "Content-Transfer-Encoding: 8bit\n"
> > +"Plural-Forms: nplurals=2; plural=n != 1;\n"
> >  "X-Generator: Poedit 1.8.8\n"
> >
> >  #: src/channel-main.c:1868
> > @@ -286,15 +287,12 @@ msgstr "%s %s %s a %d-%d"
> >  msgid "Select USB devices to redirect"
> >  msgstr "Selezionare dispositivo USB da redirigere"
> >
> > -#: src/usb-device-widget.c:420
> > +#: src/usb-device-widget.c:393
> >  #, c-format
> >  msgid "Select USB devices to redirect (%d free channel)"
> > -msgstr "Selezionare dispositivo USB da redirigere (%d canale libero)"
> > -
> > -#: src/usb-device-widget.c:421
> > -#, c-format
> > -msgid "Select USB devices to redirect (%d free channels)"
> > -msgstr "Selezionare dispositivo USB da redirigere (%d canali liberi)"
> > +msgid_plural "Select USB devices to redirect (%d free channels)"
> > +msgstr[0] "Selezionare dispositivo USB da redirigere (%d canale libero)"
> > +msgstr[1] "Selezionare dispositivo USB da redirigere (%d canali liberi)"
> >
> >  #: src/usb-device-widget.c:439
> >  msgid "Redirecting USB Device..."
> > diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
> > index de62564..7979a2c 100644
> > --- a/src/usb-device-widget.c
> > +++ b/src/usb-device-widget.c
> > @@ -390,8 +390,8 @@ static gboolean
> > spice_usb_device_widget_update_status(gpointer user_data)
> >  redirecting = spice_usb_device_manager_is_redirecting(priv->manager);
> >
> >  g_object_get(priv->manager, "free-channels", &free_channels, NULL);
> > -free_channels_str = ngettext(_("Select USB devices to redirect (%d free
> > channel)"),
> > - _("Select USB devices to redirect (%d free
> > channels)"),
> > +free_channels_str = ngettext("Select USB devices to redirect (%d free
> > channel)",
> > + "Select USB devices to redirect (%d free
> > channels)",
> >   free_channels);
> >  str = g_strdup_printf(free_channels_str, free_channels);
> >  markup_str = g_strdup_printf("%s", str);
>
> Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] gettext: fix ngettext usage

[Jakub Janku]

On Wed, Apr 17, 2019 at 6:24 PM Frediano Ziglio  wrote:
>
> >
> > _() should not be used in conjunction with ngettext(),
> > otherwise it's impossible to properly translate the message into
> > languages that have multiple plural forms, such as Czech.
> >
> > Fix ngettext usage in usb-device-widget.c and
> > update the PO files accordingly.
> >
> > Signed-off-by: Jakub Janků 
> > ---
> >  po/de.po|  9 +++--
> >  po/fr.po| 11 ---
> >  po/it.po| 12 +---
> >  src/usb-device-widget.c |  4 ++--
> >  4 files changed, 14 insertions(+), 22 deletions(-)
> >
> > diff --git a/po/de.po b/po/de.po
> > index eb24de7..3ae6ae0 100644
> > --- a/po/de.po
> > +++ b/po/de.po
> > @@ -288,12 +288,9 @@ msgstr "Auswahl des USB-Geräts zum Weiterleiten"
> >  #: src/usb-device-widget.c:393
> >  #, c-format
> >  msgid "Select USB devices to redirect (%d free channel)"
> > -msgstr "Auswahl des USB-Geräts zum Weiterleiten (%d freier Kanal)"
> > -
> > -#: src/usb-device-widget.c:394
> > -#, c-format
> > -msgid "Select USB devices to redirect (%d free channels)"
> > -msgstr "Auswahl des USB-Geräts zum Weiterleiten (%d freie Kanäle)"
> > +msgid_plural "Select USB devices to redirect (%d free channels)"
> > +msgstr[0] "Auswahl des USB-Geräts zum Weiterleiten (%d freier Kanal)"
> > +msgstr[1] "Auswahl des USB-Geräts zum Weiterleiten (%d freie Kanäle)"
> >
> >  #: src/usb-device-widget.c:411
> >  msgid "Redirecting USB Device..."
> > diff --git a/po/fr.po b/po/fr.po
> > index e2dd3ad..6120ee0 100644
> > --- a/po/fr.po
> > +++ b/po/fr.po
> > @@ -271,15 +271,12 @@ msgstr ""
> >  msgid "Select USB devices to redirect"
> >  msgstr ""
> >
> > -#: src/usb-device-widget.c:420
> > +#: src/usb-device-widget.c:393
> >  #, c-format
> >  msgid "Select USB devices to redirect (%d free channel)"
> > -msgstr ""
> > -
> > -#: src/usb-device-widget.c:421
> > -#, c-format
> > -msgid "Select USB devices to redirect (%d free channels)"
> > -msgstr ""
> > +msgid_plural "Select USB devices to redirect (%d free channels)"
> > +msgstr[0] ""
> > +msgstr[1] ""
> >
> >  #: src/usb-device-widget.c:439
> >  msgid "Redirecting USB Device..."
> > diff --git a/po/it.po b/po/it.po
> > index a4e40e9..b7899a8 100644
> > --- a/po/it.po
> > +++ b/po/it.po
> > @@ -16,6 +16,7 @@ msgstr ""
> >  "MIME-Version: 1.0\n"
> >  "Content-Type: text/plain; charset=UTF-8\n"
> >  "Content-Transfer-Encoding: 8bit\n"
> > +"Plural-Forms: nplurals=2; plural=n != 1;\n"
> >  "X-Generator: Poedit 1.8.8\n"
> >
> >  #: src/channel-main.c:1868
> > @@ -286,15 +287,12 @@ msgstr "%s %s %s a %d-%d"
> >  msgid "Select USB devices to redirect"
> >  msgstr "Selezionare dispositivo USB da redirigere"
> >
> > -#: src/usb-device-widget.c:420
> > +#: src/usb-device-widget.c:393
> >  #, c-format
> >  msgid "Select USB devices to redirect (%d free channel)"
> > -msgstr "Selezionare dispositivo USB da redirigere (%d canale libero)"
> > -
> > -#: src/usb-device-widget.c:421
> > -#, c-format
> > -msgid "Select USB devices to redirect (%d free channels)"
> > -msgstr "Selezionare dispositivo USB da redirigere (%d canali liberi)"
> > +msgid_plural "Select USB devices to redirect (%d free channels)"
> > +msgstr[0] "Selezionare dispositivo USB da redirigere (%d canale libero)"
> > +msgstr[1] "Selezionare dispositivo USB da redirigere (%d canali liberi)"
> >
>
> Applied the patch, set lang to it_IT.utf-8, most strings work, this
> no way! I did an strace to check the file used are correct, they are.
> I removed all .gmo and .mo, rebuilt, reinstalled, checked I'm using
> the new. Still not working. Probably I'm doing something really silly
> but I cannot understand what I'm doing wrong.
> I also checked if that specific string is inside virt-viewer strings,
> no.
>
> It seems this hunk solve the issue:
>
>
> @@ -390,7 +390,7 @@ static gboolean 
> spice_usb_device_widget_update_status(gpointer user_data)
>  redirecting = spice_usb_device_manager_is_redirecting(priv->manager);
>
>  g_object_get(priv->manager, "free-channels", &free_channels, NULL);
> -free_channels_str = ngettext("Select USB devices to redirect (%d free 
> channel)",
> +free_channels_str = dngettext(GETTEXT_PACKAGE, "Select USB devices to 
> redirect (%d free channel)",
>   "Select USB devices to redirect (%d free 
> channels)",
>   free_channels);
>  str = g_strdup_printf(free_channels_str, free_channels);

Ah, I see, so this is another mistake. Spice-gtk, as a library, should
be using the dngettext function instead of ngettext, otherwise the
translation string is searched in the "virt-viewer" domain and hence
not found.
I'll be sending v2.

Thanks,
Jakub
>
>
> >  #: src/usb-device-widget.c:439
> >  msgid "Redirecting USB Device..."
> > diff --git a/src/usb-device-widget.c b/src/usb-device-widget.c
> > index de62564..7979a2c 100644
> > --- a/src/usb-device-widget.c
> > +++ b/src/usb-device-widget.c
> > @@ -39

Re: [Spice-devel] [PATCH spice-gtk] Add Czech translation

[Jakub Janku]

Hi David,

On Fri, Apr 12, 2019 at 3:15 PM David Jaša  wrote:
>
> At last. :)

Great, thanks a lot!
>
> Signed-off-by: David Jaša 
> ---
>  po/cs.po | 336 +++
>  1 file changed, 336 insertions(+)
>  create mode 100644 po/cs.po
>
> diff --git a/po/cs.po b/po/cs.po
> new file mode 100644
> index 000..f5cbc5f
> --- /dev/null
> +++ b/po/cs.po
> @@ -0,0 +1,336 @@
> +# Czech translations for spice-gtk package.
> +# Copyright (C) 2009-2019 Red Hat, Inc.
> +# This file is distributed under the same license as the spice-gtk package.
> +# David Jaša , 2019.
> +#
> +msgid ""
> +msgstr ""
> +"Project-Id-Version: spice-gtk master\n"
> +"Report-Msgid-Bugs-To: spice-devel@lists.freedesktop.org\n"
> +"POT-Creation-Date: 2019-04-11 15:17+0200\n"
> +"PO-Revision-Date: 2019-04-12 09:22+0200\n"
> +"Last-Translator: David Jaša \n"
> +"Language-Team: Czech < >\n"
> +"Language: cs\n"
> +"MIME-Version: 1.0\n"
> +"Content-Type: text/plain; charset=UTF-8\n"
> +"Content-Transfer-Encoding: 8bit\n"
> +"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2\n"
> +"X-Generator: Gtranslator 3.32.0\n"

The new language must be listed in the LINGUAS file.

As far as the translations are concerned, feel free to ignore my
suggestions which I list below, I don't want to be too nitpicky.
> +
> +#: src/channel-main.c:1896
> +msgid "The spice agent cancelled the file transfer"
> +msgstr "Spice agent zrušil přenos souboru"
> +
> +#: src/channel-main.c:1900
> +msgid "The spice agent reported an error during the file transfer"
> +msgstr "Spice agent hlásí chybu při přenosu souboru"
> +
> +#: src/channel-main.c:1907
> +#, c-format
> +msgid ""
> +"File transfer failed due to lack of free space on remote machine (%s free, "
> +"%s to transfer)"
> +msgstr ""
> +"Přenos souboru zrušen kvůli nedostatku místa na vzdáleném stroji (%s "
> +"volných, %s zbývá přenést)"

I would go for "%s k přenosu", since we say that the transfer has been
cancelled.
> +
> +#: src/channel-main.c:1915
> +msgid ""
> +"User's session is locked and cannot transfer files, unlock it and try 
> again."
> +msgstr ""
> +"Sezení je zamčené a nemůže přijímat soubory, odemčete ho a zkuste znovu."

The last verb needs an object, so "zkuste to znovu" or "zkuste soubor
přenést znovu" or...
> +
> +#: src/channel-main.c:1920
> +msgid "Session agent not connected."
> +msgstr "Agent sezení není připojen"

The original string has a full stop at the end, but I feel like we're
pretty inconsistent here, so it doesn't matter.
> +
> +#: src/channel-main.c:1924
> +msgid "File transfer is disabled."
> +msgstr "Přenos souboru je vypnutý."

maybe plural "souborů" ?
> +
> +#: src/channel-main.c:3307
> +#, c-format
> +msgid "The file transfer is disabled"
> +msgstr "Přenos souboru je vypnutý!"
> +
> +#: src/channel-usbredir.c:914
> +#, c-format
> +msgid "usbredir protocol parse error for %s"
> +msgstr "Chyba zpracování protokolu usbredir pro %s"
> +
> +#: src/channel-usbredir.c:919
> +#, c-format
> +msgid "%s rejected by host"
> +msgstr "%s byl hostitelem odmítnut"
> +
> +#: src/channel-usbredir.c:924
> +#, c-format
> +msgid "%s disconnected (fatal IO error)"
> +msgstr "%s odpojeno (fatální chyba vstupu/výstupu)"

These two translations above: in one, you're reffering to "%s" as a
masculine noun and in the other as a neuter one.
So I would consider prepending "Zařízení" before "%s" and using neuter
gender in both.
> +
> +#: src/channel-usbredir.c:928
> +#, c-format
> +msgid "Unknown error (%d) for %s"
> +msgstr "Neznámá chyba (%d) pro %s"
> +
> +#: src/desktop-integration.c:99
> +msgid "Automounting has been inhibited for USB auto-redirecting"
> +msgstr ""
> +"Automatické připojování je potlačené kvůli automatickému přesměrování USB"

This could be more specific, maybe "automatické připojování disků" ?
> +
> +#: src/spice-channel.c:1177
> +msgid "Authentication failed"
> +msgstr "Přihlášení selhalo"
> +
> +#: src/spice-channel.c:1195
> +msgid "Authentication failed: password is too long"
> +msgstr "Přihlášení selhalo: příliš dlouhé heslo"
> +
> +#: src/spice-channel.c:1200
> +msgid "Authentication failed: wrong password?"
> +msgstr "Přihlášení selhalo: špatné heslo?"
> +
> +#: src/spice-option.c:60
> +msgid "--spice-color-depth is deprecated. Use guest's display settings 
> instead"
> +msgstr "--spice-color-depth je zastaralé. Použijte natavení obrazovky"
> +
> +#: src/spice-option.c:80
> +#, c-format
> +msgid ""
> +"invalid effect name (%s), must be 'wallpaper', 'font-smooth', 'animation' 
> or "
> +"'all'"
> +msgstr ""
> +"Neplatné jméno efektu (%s), musí být „wallpaper“ (pozadí), „font-"
> +"smooth“ (vyhlazení písem), „animation“ (animace) nebo „all“ (vše)"
> +
> +#: src/spice-option.c:104
> +#, c-format
> +msgid "invalid channel name (%s), valid names: all, %s"
> +msgstr "neplatný název kanálu (%s), platné názvy: all, %s"
> +
> +#: src/spice-option.c:140
> +#, c-format
> +msgid "Image compression algorithm %s not supported"
> +msgst

Re: [Spice-devel] [PATCH spice-gtk v2] Add Czech Translation

[Jakub Janku]

On Thu, Apr 18, 2019 at 1:27 PM David Jaša  wrote:
>
> Changes since v1:
> * added 'cs' to LINGUAS
> * added both plurals after fix of 
> https://gitlab.freedesktop.org/spice/spice-gtk/issues/95
> * tried to address review comments by Jakub
>
> Signed-off-by: David Jaša 
> ---
>  po/LINGUAS |   1 +
>  po/cs.po   | 336 +
>  2 files changed, 337 insertions(+)
>  create mode 100644 po/cs.po
>
> diff --git a/po/LINGUAS b/po/LINGUAS
> index b703d74..8480346 100644
> --- a/po/LINGUAS
> +++ b/po/LINGUAS
> @@ -1,4 +1,5 @@
>  # keep this file sorted alphabetically, one language code per line
> +cs
>  de
>  fr
>  it
> diff --git a/po/cs.po b/po/cs.po
> new file mode 100644
> index 000..46fa1c6
> --- /dev/null
> +++ b/po/cs.po
> @@ -0,0 +1,336 @@
> +# Czech translations for spice-gtk package.
> +# Copyright (C) 2009-2019 Red Hat, Inc.
> +# This file is distributed under the same license as the spice-gtk package.
> +# David Jaša , 2019.
> +#
> +msgid ""
> +msgstr ""
> +"Project-Id-Version: spice-gtk master\n"
> +"Report-Msgid-Bugs-To: \n"
> +"POT-Creation-Date: 2019-04-18 10:54+0200\n"
> +"PO-Revision-Date: 2019-04-12 09:22+0200\n"
> +"Last-Translator: David Jaša \n"
> +"Language-Team: Czech < >\n"
> +"Language: cs\n"
> +"MIME-Version: 1.0\n"
> +"Content-Type: text/plain; charset=UTF-8\n"
> +"Content-Transfer-Encoding: 8bit\n"
> +"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2\n"
> +"X-Generator: Gtranslator 3.32.0\n"
> +
> +#: src/channel-main.c:1896
> +msgid "The spice agent cancelled the file transfer"
> +msgstr "Spice agent zrušil přenos souboru"
> +
> +#: src/channel-main.c:1900
> +msgid "The spice agent reported an error during the file transfer"
> +msgstr "Spice agent hlásí chybu při přenosu souboru"
> +
> +#: src/channel-main.c:1907
> +#, c-format
> +msgid ""
> +"File transfer failed due to lack of free space on remote machine (%s free, "
> +"%s to transfer)"
> +msgstr ""
> +"Přenos souboru zrušen kvůli nedostatku místa na vzdáleném stroji (%s "
> +"volných, %s k přenosu)"
> +
> +#: src/channel-main.c:1915
> +msgid ""
> +"User's session is locked and cannot transfer files, unlock it and try 
> again."
> +msgstr ""
> +"Obrazovka vzdáleného počítače je zamčena a ten tedy nemůže přijímat 
> soubory, "
> +"odemčete ji a zkuste soubor přenést znovu."

"odemčete" --> "odemkněte"
> +
> +#: src/channel-main.c:1920
> +msgid "Session agent not connected."
> +msgstr "Uživatelská část agenta není připojena."
> +
> +#: src/channel-main.c:1924
> +msgid "File transfer is disabled."
> +msgstr "Přenos souborů je vypnutý."
> +
> +#: src/channel-main.c:3307
> +#, c-format
> +msgid "The file transfer is disabled"
> +msgstr "Přenos souborů je vypnutý"
> +
> +#: src/channel-usbredir.c:914
> +#, c-format
> +msgid "usbredir protocol parse error for %s"
> +msgstr "Chyba zpracování protokolu usbredir pro %s"
> +
> +#: src/channel-usbredir.c:919
> +#, c-format
> +msgid "%s rejected by host"
> +msgstr "Zařízení %s byl hostitelem odmítnuto"

"byl" --> "bylo"
> +
> +#: src/channel-usbredir.c:924
> +#, c-format
> +msgid "%s disconnected (fatal IO error)"
> +msgstr "Zařízení %s odpojeno (fatální chyba vstupu/výstupu)"
> +
> +#: src/channel-usbredir.c:928
> +#, c-format
> +msgid "Unknown error (%d) for %s"
> +msgstr "Neznámá chyba (%d) pro %s"
> +
> +#: src/desktop-integration.c:99
> +msgid "Automounting has been inhibited for USB auto-redirecting"
> +msgstr ""
> +"Automatické připojování USB disků je potlačeno kvůli automatickému "
> +"přesměrování USB"
> +
> +#: src/spice-channel.c:1177
> +msgid "Authentication failed"
> +msgstr "Přihlášení selhalo"
> +
> +#: src/spice-channel.c:1195
> +msgid "Authentication failed: password is too long"
> +msgstr "Přihlášení selhalo: příliš dlouhé heslo"
> +
> +#: src/spice-channel.c:1200
> +msgid "Authentication failed: wrong password?"
> +msgstr "Přihlášení selhalo: špatné heslo?"
> +
> +#: src/spice-option.c:60
> +msgid "--spice-color-depth is deprecated. Use guest's display settings 
> instead"
> +msgstr "--spice-color-depth je zastaralé. Použijte natavení obrazovky"
> +
> +#: src/spice-option.c:80
> +#, c-format
> +msgid ""
> +"invalid effect name (%s), must be 'wallpaper', 'font-smooth', 'animation' 
> or "
> +"'all'"
> +msgstr ""
> +"Neplatné jméno efektu (%s), musí být „wallpaper“ (pozadí), „font-"
> +"smooth“ (vyhlazení písem), „animation“ (animace) nebo „all“ (vše)"
> +
> +#: src/spice-option.c:104
> +#, c-format
> +msgid "invalid channel name (%s), valid names: all, %s"
> +msgstr "neplatný název kanálu (%s), platné názvy: all, %s"
> +
> +#: src/spice-option.c:140
> +#, c-format
> +msgid "Image compression algorithm %s not supported"
> +msgstr "Algoritmus komprese obrazu %s není podporován"
> +
> +#: src/spice-option.c:162
> +msgid "Force the specified channels to be secured"
> +msgstr "Vynutit šifrování vyjmenovaných kanálů"
> +
> +#: src/spice-option.c:164
> +msgid "Disable guest display effects"
> +msgstr "Vypnout ef

Re: [Spice-devel] [PATCH phodav 03/13] spice: handle SIGINT properly

[Jakub Janku]

Hi,

On Thu, May 23, 2019 at 3:31 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Thu, May 23, 2019 at 10:37 AM Jakub Janků  wrote:
> >
> > According to [0], g_debug should not be used in a signal handler.
> > So, to avoid reentrancy, do not print debug message when quit is
> > called with SIGINT.
> >
> > [0] 
> > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/signal?view=vs-2019
> >
> > Signed-off-by: Jakub Janků 
> > ---
> >  spice/spice-webdavd.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/spice/spice-webdavd.c b/spice/spice-webdavd.c
> > index e494692..cdfa73d 100644
> > --- a/spice/spice-webdavd.c
> > +++ b/spice/spice-webdavd.c
> > @@ -237,7 +237,8 @@ static void mdns_unregister_service (void);
> >  static void
> >  quit (int sig)
> >  {
> > -  g_debug ("quit %d", sig);
> > +  if (sig != SIGINT)
> > +g_debug ("quit %d", sig);
> >
>
> I would simply remove the g_debug() call then.

Ok then.

On Unix, we could use g_unix_signal_add, I'll change it.
But sadly there doesn't seem to be a Windows equivalent.

Cheers,
Jakub
>
> (maybe we should have a different function for the signal handler)
>
> >if (sig == SIGINT || sig == SIGTERM)
> >quit_service = TRUE;
> > --
> > 2.21.0
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
> --
> Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH phodav 03/13] spice: handle SIGINT properly

[Jakub Janku]

Hi,

On Mon, May 27, 2019 at 5:58 PM Frediano Ziglio  wrote:
>
> >
> > Hi,
> >
> > On Thu, May 23, 2019 at 3:31 PM Marc-André Lureau
> >  wrote:
> > >
> > > Hi
> > >
> > > On Thu, May 23, 2019 at 10:37 AM Jakub Janků  wrote:
> > > >
> > > > According to [0], g_debug should not be used in a signal handler.
> > > > So, to avoid reentrancy, do not print debug message when quit is
> > > > called with SIGINT.
> > > >
> > > > [0]
> > > > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/signal?view=vs-2019
> > > >
>
> 
>
> The quit function is called by signal handler or "manually".
> If called manually it's not a problem.
> The only signal registered for this function is SIGINT which in Windows
> is managed by another thread (as written in the link you sent, and by the
> way is handled by SetConsoleCtrlHandler) so it's not a problem to call
> g_debug. Note that this function is also called manually with SIGTERM but
> still not a problem on Windows as service_ctrl_handler is run in another
> thread.

Oh, I somehow missed the big purple box that says Ctrl+C creates a new
thread and I supposed it behaves like on unix, sorry, my bad.
>
> The problems I see is that quit_service should be defined volatile and
> g_main_loop_quit should not be called on Unix! If a lock used by
> g_main_loop_quit is retained while the signal is called you'll have
> a deadlock.
> Maybe I'm wrong but I didn't find a note if g_main_loop_quit is signal
> safe so better not to call it from a signal handler.
> g_unix_signal_add seems a good solution for Unix.

Hopefully better this time:
https://gitlab.gnome.org/GNOME/phodav/merge_requests/3/

Thanks,
Jakub
>
> > > > Signed-off-by: Jakub Janků 
> > > > ---
> > > >  spice/spice-webdavd.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/spice/spice-webdavd.c b/spice/spice-webdavd.c
> > > > index e494692..cdfa73d 100644
> > > > --- a/spice/spice-webdavd.c
> > > > +++ b/spice/spice-webdavd.c
> > > > @@ -237,7 +237,8 @@ static void mdns_unregister_service (void);
> > > >  static void
> > > >  quit (int sig)
> > > >  {
> > > > -  g_debug ("quit %d", sig);
> > > > +  if (sig != SIGINT)
> > > > +g_debug ("quit %d", sig);
> > > >
> > >
> > > I would simply remove the g_debug() call then.
> >
> > Ok then.
> >
> > On Unix, we could use g_unix_signal_add, I'll change it.
> > But sadly there doesn't seem to be a Windows equivalent.
> >
> > Cheers,
> > Jakub
> > >
> > > (maybe we should have a different function for the signal handler)
> > >
>
> It sounds a great idea.
>
> > > >if (sig == SIGINT || sig == SIGTERM)
> > > >quit_service = TRUE;
>
> Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk 4/5] webdav: remove client on empty message

[Jakub Janku]

Hi,

On Wed, Jun 19, 2019 at 11:59 AM Frediano Ziglio  wrote:
>
> >
> > Message with no data from spice-webdav daemon means
> > the client disconnected.
> >
> > In this case, the client connection to phodav
> > should be closed as well.
> >
> > This can happen e.g. when file transfer gets cancelled.
> >
> > Signed-off-by: Jakub Janků 
> > ---
> >  src/channel-webdav.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/channel-webdav.c b/src/channel-webdav.c
> > index ea287f1..34d88a9 100644
> > --- a/src/channel-webdav.c
> > +++ b/src/channel-webdav.c
> > @@ -341,8 +341,8 @@ static void demux_to_client(Client *client)
> >  c->cancellable, demux_to_client_cb,
> >  client);
> >  return;
> >  } else {
> > -/* Nothing to write */
> > -demux_to_client_finish(client, FALSE);
> > +/* Client disconnected */
> > +demux_to_client_finish(client, TRUE);
>
> Minor style: as we are changing this. Previous if block ends with a "return",
> why not removing the "else" and reduce indentation too?

I think it would actually make better sense to put the
demux_to_client_finish() call in an if-return block, as this is the
"special" case.
So I would change it to that, if you don't mind.

Jakub
>
> >  }
> >  #endif
> >  }
>
> Otherwise,
>   Acked-by: Frediano Ziglio 
>
> Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] channel-main: Fix typo in comment

[Jakub Janku]

Sure,

Acked-by: Jakub Janků 

On Tue, Jun 25, 2019 at 12:13 PM Frediano Ziglio  wrote:
>
> explicitely -> explicitly
>
> Signed-off-by: Frediano Ziglio 
> ---
>  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 10c31ac4..afdc1cef 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -1755,7 +1755,7 @@ static void main_handle_channels_list(SpiceChannel 
> *channel, SpiceMsgIn *in)
>  c->session = g_object_ref(session);
>  c->type = msg->channels[i].type;
>  c->id = msg->channels[i].id;
> -/* no need to explicitely switch to main context, since
> +/* no need to explicitly switch to main context, since
> synchronous call is not needed. */
>  /* no need to track idle, session is refed */
>  g_idle_add((GSourceFunc)_channel_new, c);
> --
> 2.20.1
>
> ___
> 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] spice-channel: return if has_error is TRUE in spice_channel_write_msg

[Jakub Janku]

Hi,

On Thu, Jun 27, 2019 at 10:10 AM Frediano Ziglio  wrote:
>
> >
> > Avoid linearizing if the message isn't written out anyway
>
> "linearizing" ? What do you mean about that?
> Looking at definitions it seems not correct to me.

I was simply referring to the spice_marshaller_linearize() call.
>
> > (spice_channel_flush_wire checks() this condition as well).
> >
> > This also silences the following error:
> >
> > (spicy:32087): GSpice-CRITICAL **: 16:22:03.147:
> > spice_session_get_read_only: assertion 'SPICE_IS_SESSION(self)' failed
> >
> > that can be seen if the channel gets disconnected
> > by the session while having non-empty write queue.
> >
> > spice_session_channel_destroy() sets channel->priv->session to NULL,
> > but spice_channel_write_msg() subsequently attempts to call
> > spice_session_get_read_only() with NULL pointer.
> >
>
> Minor: this is the explanation why the error on the previous
> paragraph should not be treated like an error, I think it should
> be the same paragraphs.

Makes sense.
>
> OT: maybe channel session should never be NULL?

It indeed does seem weird that
g_clear_object(&channel->priv->session); is called when the
"spice-session" property of the channel is G_PARAM_CONSTRUCT_ONLY --
with this flag, I would expect the property to not change after the
construction.

Spice session waits for the channel destruction anyway
(channel_finally_destroyed callback), so it should be imho fine that
the channel holds a reference to the session while it is being
destroyed. So I think we could remove that
g_clear_object(&channel->priv->session); call in
spice_session_channel_destroy().
>
> > Signed-off-by: Jakub Janků 
> > ---
> >  src/spice-channel.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/src/spice-channel.c b/src/spice-channel.c
> > index 61de177..aa80edf 100644
> > --- a/src/spice-channel.c
> > +++ b/src/spice-channel.c
> > @@ -897,6 +897,11 @@ static void spice_channel_write_msg(SpiceChannel
> > *channel, SpiceMsgOut *out)
> >  g_return_if_fail(out != NULL);
> >  g_return_if_fail(channel == out->channel);
> >
> > +if (channel->priv->has_error) {
> > +spice_msg_out_unref(out);
> > +return;
> > +}
> > +
> >  if (out->ro_check &&
> >  spice_channel_get_read_only(channel)) {
> >  g_warning("Try to send message while read-only. Please report a
> >  bug.");
>
> Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] webdav: don't buffer input from phodav

[Jakub Janku]

Hi,

On Mon, Jul 1, 2019 at 1:02 PM Frediano Ziglio  wrote:
>
> >
> > The current approach with OutputQueue in webdav has several problems:
> >
> > * if the connection is slow, webdav keeps reading from phodav
> > and pushing messages to the internal channel xmit_queue.
> > This way, the queue can grow very quickly and the whole file
> > that is being transferred using webdav essentially gets loaded into memory.
> >
> > * spice channel first flushes all messages in the xmit_queue and
> > then proceeds to reading. If webdav floods the xmit_queue with
> > a ton of messages, spice channel does not leave iterate_write until
> > the queue gets empty. This way, reading from the channel is blocked
> > till the whole file is transferred.
> >
> > * OutputQueue uses g_output_stream_flush_async() on SpiceVmcOutputStream
> > that does not implement flush
> >
> > To solve these issues, don't read from phodav until the last message
> > for a given client is written out to the socket.
> > (main channel currently uses the same approach when transferring files)
> >
> > OutputQueue used an idle function to schedule the write and then
> > called mux_pushed_cb which started reading from phodav with priority
> > G_PRIORITY_DEFAULT.
> > Since this new approach does not utilize the idle scheduling,
> > lower the priority in client_start_read() to G_PRIORITY_DEFAULT_IDLE
> > to make sure webdav does not block other channels.
> >
>
> This sounds a bit worrying. Why with all coroutine/async code we
> have we should have a blockage? This sounds wrong.

To be honest, I did not spent much time looking at why this blocks.
Lowering the priority of webdav makes sense to me regardless of this issue.
Another thing is that with your spice-server series concerning
spicevmc and DoS, this isn't an issue.
>
> > Also implement spice_webdav_channel_reset(). This is necessary because
> > spice_vmc_write_async() references the channel. If the channel is to be
> > disconnected, the write operations need to be cancelled so that
> > the references to the channel are released asap. Otherwise,
> > spice session would be stuck waiting for the channel to finalize.
> >
> > Signed-off-by: Jakub Janků 
> > ---
> >
> > Note: I left the OutputQueue code still in place since I'm considering
> > using it for the drag&drop functionality.
> >
> >  src/channel-webdav.c | 49 
> >  1 file changed, 36 insertions(+), 13 deletions(-)
> >
> > diff --git a/src/channel-webdav.c b/src/channel-webdav.c
> > index f5a38ad..66f8a5b 100644
> > --- a/src/channel-webdav.c
> > +++ b/src/channel-webdav.c
> > @@ -45,13 +45,12 @@
> >   * Since: 0.24
> >   */
> >
> > -typedef struct _OutputQueue OutputQueue;
> > +/* typedef struct _OutputQueue OutputQueue; */
> >
> >  struct _SpiceWebdavChannelPrivate {
> >  SpiceVmcStream *stream;
> >  GCancellable *cancellable;
> >  GHashTable *clients;
> > -OutputQueue *queue;
> >
> >  gboolean demuxing;
> >  struct _demux {
> > @@ -65,6 +64,7 @@ G_DEFINE_TYPE_WITH_PRIVATE(SpiceWebdavChannel,
> > spice_webdav_channel, SPICE_TYPE_
> >
> >  static void spice_webdav_handle_msg(SpiceChannel *channel, SpiceMsgIn 
> > *msg);
> >
> > +#if 0
> >  struct _OutputQueue {
> >  GOutputStream *output;
> >  gboolean flushing;
> > @@ -179,6 +179,8 @@ static void output_queue_push(OutputQueue *q, const
> > guint8 *buf, gsize size,
> >  q->idle_id = g_idle_add(output_queue_idle, q);
> >  }
> >
> > +#endif
> > +
> >  typedef struct Client
> >  {
> >  guint refs;
> > @@ -227,10 +229,17 @@ static void remove_client(Client *client)
> >  g_hash_table_remove(client->self->priv->clients, &client->id);
> >  }
> >
> > -static void mux_pushed_cb(OutputQueue *q, gpointer user_data)
> > +#define MAX_MUX_SIZE G_MAXUINT16
> > +
> > +static void
> > +mux_msg_flushed_cb(GObject *source_object,
> > +   GAsyncResult *result,
> > +   gpointer user_data)
> >  {
> >  Client *client = user_data;
> >
> > +g_output_stream_write_finish(G_OUTPUT_STREAM(source_object), result,
> > NULL);
> > +
> >  if (client->mux.size == 0 ||
> >  !client_start_read(client)) {
> >  remove_client(client);
> > @@ -239,14 +248,13 @@ static void mux_pushed_cb(OutputQueue *q, gpointer
> > user_data)
> >  client_unref(client);
> >  }
> >
> > -#define MAX_MUX_SIZE G_MAXUINT16
> > -
> >  static void server_reply_cb(GObject *source_object,
> >  GAsyncResult *res,
> >  gpointer user_data)
> >  {
> >  Client *client = user_data;
> >  SpiceWebdavChannelPrivate *c = client->self->priv;
> > +GOutputStream *mux_out;
> >  GError *err = NULL;
> >  gssize size;
> >
> > @@ -258,10 +266,15 @@ static void server_reply_cb(GObject *source_object,
> >  g_return_if_fail(size >= 0);
> >  client->mux.size = size;
> >
> > -output_queue_push(c->queue, (guint8 *)&client->mux.id, sizeof(gint64),
> > 

Re: [Spice-devel] [PATCH spice-gtk] webdav: don't buffer input from phodav

[Jakub Janku]

Hi again,

On Mon, Jul 1, 2019 at 3:16 PM Jakub Janku  wrote:
>
> Hi,
>
> On Mon, Jul 1, 2019 at 1:02 PM Frediano Ziglio  wrote:
> >
> > >
> > > The current approach with OutputQueue in webdav has several problems:
> > >
> > > * if the connection is slow, webdav keeps reading from phodav
> > > and pushing messages to the internal channel xmit_queue.
> > > This way, the queue can grow very quickly and the whole file
> > > that is being transferred using webdav essentially gets loaded into 
> > > memory.
> > >
> > > * spice channel first flushes all messages in the xmit_queue and
> > > then proceeds to reading. If webdav floods the xmit_queue with
> > > a ton of messages, spice channel does not leave iterate_write until
> > > the queue gets empty. This way, reading from the channel is blocked
> > > till the whole file is transferred.
> > >
> > > * OutputQueue uses g_output_stream_flush_async() on SpiceVmcOutputStream
> > > that does not implement flush
> > >
> > > To solve these issues, don't read from phodav until the last message
> > > for a given client is written out to the socket.
> > > (main channel currently uses the same approach when transferring files)
> > >
> > > OutputQueue used an idle function to schedule the write and then
> > > called mux_pushed_cb which started reading from phodav with priority
> > > G_PRIORITY_DEFAULT.
> > > Since this new approach does not utilize the idle scheduling,
> > > lower the priority in client_start_read() to G_PRIORITY_DEFAULT_IDLE
> > > to make sure webdav does not block other channels.
> > >
> >
> > This sounds a bit worrying. Why with all coroutine/async code we
> > have we should have a blockage? This sounds wrong.
>
> To be honest, I did not spent much time looking at why this blocks.
> Lowering the priority of webdav makes sense to me regardless of this issue.
> Another thing is that with your spice-server series concerning
> spicevmc and DoS, this isn't an issue.

I did some more testing and here's what I've found out:

Channel display uses g_coroutine_signal_emit() to emit the
"display-invalidate" signal.
This function uses an idle function (G_PRIORITY_DEFAULT_IDLE = 200) to
emit the signal in the main context.

From Gtk docs (G_PRIORITY_HIGH_IDLE = 100; larger number means lower priority):
"GTK+ uses G_PRIORITY_HIGH_IDLE + 10 for resizing operations, and
G_PRIORITY_HIGH_IDLE + 20 for redrawing operations."

This means that if the client_start_read() in webdav uses
G_PRIORITY_DEFAULT= 0, it can block these two operations rather easily
causing the widget not to redraw. But as I said, this shouldn't be an
issue if the channel was throttled down by the server.

So is it ok to lower the priority in webdav to G_PRIORITY_DEFAULT_IDLE?

Cheers,
Jakub
> >
> > > Also implement spice_webdav_channel_reset(). This is necessary because
> > > spice_vmc_write_async() references the channel. If the channel is to be
> > > disconnected, the write operations need to be cancelled so that
> > > the references to the channel are released asap. Otherwise,
> > > spice session would be stuck waiting for the channel to finalize.
> > >
> > > Signed-off-by: Jakub Janků 
> > > ---
> > >
> > > Note: I left the OutputQueue code still in place since I'm considering
> > > using it for the drag&drop functionality.
> > >
> > >  src/channel-webdav.c | 49 
> > >  1 file changed, 36 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/src/channel-webdav.c b/src/channel-webdav.c
> > > index f5a38ad..66f8a5b 100644
> > > --- a/src/channel-webdav.c
> > > +++ b/src/channel-webdav.c
> > > @@ -45,13 +45,12 @@
> > >   * Since: 0.24
> > >   */
> > >
> > > -typedef struct _OutputQueue OutputQueue;
> > > +/* typedef struct _OutputQueue OutputQueue; */
> > >
> > >  struct _SpiceWebdavChannelPrivate {
> > >  SpiceVmcStream *stream;
> > >  GCancellable *cancellable;
> > >  GHashTable *clients;
> > > -OutputQueue *queue;
> > >
> > >  gboolean demuxing;
> > >  struct _demux {
> > > @@ -65,6 +64,7 @@ G_DEFINE_TYPE_WITH_PRIVATE(SpiceWebdavChannel,
> > > spice_webdav_channel, SPICE_TYPE_
> > >
> > >  static void spice_webdav_handle_msg(SpiceChannel *channel, SpiceMsgIn 
> > > *msg);
> > >
> > > +#if 0
>

Re: [Spice-devel] [PATCH spice-gtk 1/2] channel-webdav: Write mux message in a single memory block

[Jakub Janku]

On Wed, Jul 3, 2019 at 10:35 AM Frediano Ziglio  wrote:
>
> Reduce number of write to the channel.
> This will also help making the write to socket all asynchronous
> avoiding potential blockages.
>
> Signed-off-by: Frediano Ziglio 
> ---
>  src/channel-webdav.c | 28 +---
>  1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/src/channel-webdav.c b/src/channel-webdav.c
> index f5a38ad3..a4bc1cb2 100644
> --- a/src/channel-webdav.c
> +++ b/src/channel-webdav.c
> @@ -179,6 +179,8 @@ static void output_queue_push(OutputQueue *q, const 
> guint8 *buf, gsize size,
>  q->idle_id = g_idle_add(output_queue_idle, q);
>  }
>
> +#define MAX_MUX_SIZE G_MAXUINT16
> +
>  typedef struct Client
>  {
>  guint refs;
> @@ -187,11 +189,11 @@ typedef struct Client
>  gint64 id;
>  GCancellable *cancellable;
>
> -struct _mux {
> +struct {
>  gint64 id;
>  guint16 size;
> -guint8 *buf;
> -} mux;
> +guint8 buf[MAX_MUX_SIZE];
> +} *mux;
>  } Client;
>
>  static void
> @@ -200,7 +202,7 @@ client_unref(Client *client)
>  if (--client->refs > 0)
>  return;
>
> -g_free(client->mux.buf);
> +g_free(client->mux);
>
>  g_object_unref(client->pipe);
>  g_object_unref(client->cancellable);
> @@ -231,7 +233,7 @@ static void mux_pushed_cb(OutputQueue *q, gpointer 
> user_data)
>  {
>  Client *client = user_data;
>
> -if (client->mux.size == 0 ||
> +if (client->mux->size == 0 ||
>  !client_start_read(client)) {
>  remove_client(client);
>  }
> @@ -239,8 +241,6 @@ static void mux_pushed_cb(OutputQueue *q, gpointer 
> user_data)
>  client_unref(client);
>  }
>
> -#define MAX_MUX_SIZE G_MAXUINT16
> -
>  static void server_reply_cb(GObject *source_object,
>  GAsyncResult *res,
>  gpointer user_data)
> @@ -256,12 +256,10 @@ static void server_reply_cb(GObject *source_object,
>
>  g_return_if_fail(size <= MAX_MUX_SIZE);
>  g_return_if_fail(size >= 0);
> -client->mux.size = size;
> +client->mux->size = GUINT16_TO_LE(size);
>
> -output_queue_push(c->queue, (guint8 *)&client->mux.id, sizeof(gint64), 
> NULL, NULL);
> -client->mux.size = GUINT16_TO_LE(client->mux.size);
> -output_queue_push(c->queue, (guint8 *)&client->mux.size, 
> sizeof(guint16), NULL, NULL);
> -output_queue_push(c->queue, (guint8 *)client->mux.buf, size, 
> (GFunc)mux_pushed_cb, client);
> +output_queue_push(c->queue, (guint8 *)client->mux, sizeof(gint64) + 
> sizeof(guint16) + size,
> +  (GFunc)mux_pushed_cb, client);
>
>  return;
>
> @@ -284,7 +282,7 @@ static bool client_start_read(Client *client)
>  if (g_input_stream_is_closed(input)) {
>  return false;
>  }
> -g_input_stream_read_async(input, client->mux.buf, MAX_MUX_SIZE,
> +g_input_stream_read_async(input, client->mux->buf, MAX_MUX_SIZE,
>G_PRIORITY_DEFAULT, client->cancellable, 
> server_reply_cb,
>client_ref(client));
>  return true;
> @@ -368,8 +366,8 @@ static void start_client(SpiceWebdavChannel *self)
>  client->refs = 1;
>  client->id = c->demux.client;
>  client->self = self;
> -client->mux.id = GINT64_TO_LE(client->id);
> -client->mux.buf = g_malloc0(MAX_MUX_SIZE);
> +client->mux = g_malloc0(sizeof(*client->mux));

Why are you allocating mux separately from the client?
It does not change during the lifetime of Client,
so I think we can simply make it a part of the Client struct.

> +client->mux->id = GINT64_TO_LE(client->id);
>  client->cancellable = g_cancellable_new();
>  spice_make_pipe(&client->pipe, &peer);
>
> --
> 2.20.1
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel

Jakub
___
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 v2] channel-webdav: Write mux message in a single memory block

[Jakub Janku]

Acked-by: Jakub Janků 

On Wed, Jul 3, 2019 at 11:42 AM Frediano Ziglio  wrote:
>
> Reduce number of write to the channel.
> This will also help making the write to socket all asynchronous
> avoiding potential blockages.
>
> Signed-off-by: Frediano Ziglio 
> ---
> Changes sinve v1:
> - make "mux" a simple structure, not a pointer to a structure
> ---
>  src/channel-webdav.c | 19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/src/channel-webdav.c b/src/channel-webdav.c
> index f5a38ad3..0fa0d69b 100644
> --- a/src/channel-webdav.c
> +++ b/src/channel-webdav.c
> @@ -179,6 +179,8 @@ static void output_queue_push(OutputQueue *q, const 
> guint8 *buf, gsize size,
>  q->idle_id = g_idle_add(output_queue_idle, q);
>  }
>
> +#define MAX_MUX_SIZE G_MAXUINT16
> +
>  typedef struct Client
>  {
>  guint refs;
> @@ -187,10 +189,10 @@ typedef struct Client
>  gint64 id;
>  GCancellable *cancellable;
>
> -struct _mux {
> +struct {
>  gint64 id;
>  guint16 size;
> -guint8 *buf;
> +guint8 buf[MAX_MUX_SIZE];
>  } mux;
>  } Client;
>
> @@ -200,8 +202,6 @@ client_unref(Client *client)
>  if (--client->refs > 0)
>  return;
>
> -g_free(client->mux.buf);
> -
>  g_object_unref(client->pipe);
>  g_object_unref(client->cancellable);
>
> @@ -239,8 +239,6 @@ static void mux_pushed_cb(OutputQueue *q, gpointer 
> user_data)
>  client_unref(client);
>  }
>
> -#define MAX_MUX_SIZE G_MAXUINT16
> -
>  static void server_reply_cb(GObject *source_object,
>  GAsyncResult *res,
>  gpointer user_data)
> @@ -256,12 +254,10 @@ static void server_reply_cb(GObject *source_object,
>
>  g_return_if_fail(size <= MAX_MUX_SIZE);
>  g_return_if_fail(size >= 0);
> -client->mux.size = size;
> +client->mux.size = GUINT16_TO_LE(size);
>
> -output_queue_push(c->queue, (guint8 *)&client->mux.id, sizeof(gint64), 
> NULL, NULL);
> -client->mux.size = GUINT16_TO_LE(client->mux.size);
> -output_queue_push(c->queue, (guint8 *)&client->mux.size, 
> sizeof(guint16), NULL, NULL);
> -output_queue_push(c->queue, (guint8 *)client->mux.buf, size, 
> (GFunc)mux_pushed_cb, client);
> +output_queue_push(c->queue, (guint8 *)&client->mux, sizeof(gint64) + 
> sizeof(guint16) + size,
> +  (GFunc)mux_pushed_cb, client);
>
>  return;
>
> @@ -369,7 +365,6 @@ static void start_client(SpiceWebdavChannel *self)
>  client->id = c->demux.client;
>  client->self = self;
>  client->mux.id = GINT64_TO_LE(client->id);
> -client->mux.buf = g_malloc0(MAX_MUX_SIZE);
>  client->cancellable = g_cancellable_new();
>  spice_make_pipe(&client->pipe, &peer);
>
> --
> 2.20.1
>
> ___
> 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] webdav: fix usecase with multiple concurrent connections

[Jakub Janku]

ping

Also forgot to mention that this fixes a regression introduced by me
in 9f5aee05.

On Thu, Aug 8, 2019 at 11:03 AM Jakub Janků  wrote:
>
> GOutputStream does not allow simultaneous tasks on a single
> stream. An attempt to transfer two files therefore
> results into one of the clients being removed in
> mux_msg_flushed_cb() with the error
> "Stream has outstanding operation".
>
> To fix this, use spice_vmc_write_async() directly.
>
> Signed-off-by: Jakub Janků 
> ---
>  src/channel-webdav.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/src/channel-webdav.c b/src/channel-webdav.c
> index 14d4e05..09ef9f7 100644
> --- a/src/channel-webdav.c
> +++ b/src/channel-webdav.c
> @@ -235,7 +235,7 @@ mux_msg_flushed_cb(GObject *source_object,
>  {
>  Client *client = user_data;
>
> -if (!g_output_stream_write_all_finish(G_OUTPUT_STREAM(source_object), 
> result, NULL, NULL) ||
> +if (spice_vmc_write_finish(SPICE_CHANNEL(source_object), result, NULL) 
> == -1 ||
>  client->mux.size == 0 ||
>  !client_start_read(client)) {
>  remove_client(client);
> @@ -249,8 +249,6 @@ static void server_reply_cb(GObject *source_object,
>  gpointer user_data)
>  {
>  Client *client = user_data;
> -SpiceWebdavChannelPrivate *c = client->self->priv;
> -GOutputStream *mux_out;
>  GError *err = NULL;
>  gssize size;
>
> @@ -262,13 +260,12 @@ static void server_reply_cb(GObject *source_object,
>  g_return_if_fail(size >= 0);
>  client->mux.size = GUINT16_TO_LE(size);
>
> -mux_out = g_io_stream_get_output_stream(G_IO_STREAM(c->stream));
> -
> -/* this internally uses spice_vmc_write_async(), priority is ignored;
> - * the callback is invoked once the msg is written out to the socket */
> -g_output_stream_write_all_async(mux_out, (guint8 *)&client->mux, 
> sizeof(gint64) + sizeof(guint16) + size,
> -G_PRIORITY_DEFAULT, client->cancellable, mux_msg_flushed_cb, client);
> -
> +spice_vmc_write_async(SPICE_CHANNEL(client->self),
> +  &client->mux,
> +  sizeof(gint64) + sizeof(guint16) + size,
> +  client->cancellable,
> +  mux_msg_flushed_cb,
> +  client);
>  return;
>
>  end:
> --
> 2.21.0
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] webdav: fix usecase with multiple concurrent connections

[Jakub Janku]

Hi,

On Fri, Aug 23, 2019 at 3:36 PM Victor Toso  wrote:
>
> Hi,
>
> On Fri, Aug 23, 2019 at 11:57:55AM +0200, Jakub Janku wrote:
> > ping
>
> Yep, sorry
>
> >
> > Also forgot to mention that this fixes a regression introduced by me
> > in 9f5aee05.
>
> Ok. I just went over it before coming back here.
>
> > On Thu, Aug 8, 2019 at 11:03 AM Jakub Janků  wrote:
> > >
> > > GOutputStream does not allow simultaneous tasks on a single
> > > stream. An attempt to transfer two files therefore
> > > results into one of the clients being removed in
> > > mux_msg_flushed_cb() with the error
> > > "Stream has outstanding operation".
> > >
> > > To fix this, use spice_vmc_write_async() directly.
>
> The major difference in implementation that this patch proposes
> is to avoid a GTask creation and being handled by vmcstream.c on
> spice_vmc_output_stream_write_async(), correct?

That's correct.
Before this patch: g_output_stream_write_all_async() ->
spice_vmc_output_stream_write_async() -> spice_vmc_write_async()
With this patch, spice_vmc_write_async() is called directly, without
the first 2 steps.
>
> I'm a bit confused about that, maybe because it was working
> before? I mean, the fact that we changed the way to deal with
> the buffers made our implementation on GOutputStream not
> support simultaneous tasks or that should never actually work in
> the first place?

Previously, webdav channel had its own OutputQueue that was scheduling
the messages and calling g_output_stream_write_all() for each message.
With 9f5aee05, the OutputQueue was dropped and webdav now relies on
the internal queue in SpiceChannel.
Maybe it's the naming that might confuse you. "spice_vmc_write_async"
might suggest that the message is simply written to the stream, but
the message is in reality queued for write and the async operation
finishes once the msg is flushed. Therefore you can call
spice_vmc_write_async() multiple times in a row, unlike
g_output_stream_write_async() that permits only a single operation at
a time.
>
> I have to refresh my memory on the implementation details on this
> but the concept of pipe per 'client' could work with multiple
> files because of the inner protocol that mux/demux things on
> client/server, but perhaps I'm misremembering.
>
> So, again, my question would be: Did the overall behavior
> changed? e.g: This client still works with old spice-webdavd for
> instance.

Yes, it works with old spice-webdavd versions.

Cheers,
Jakub
>
> Thanks,
>
> > > Signed-off-by: Jakub Janků 
> > > ---
> > >  src/channel-webdav.c | 17 +++--
> > >  1 file changed, 7 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/src/channel-webdav.c b/src/channel-webdav.c
> > > index 14d4e05..09ef9f7 100644
> > > --- a/src/channel-webdav.c
> > > +++ b/src/channel-webdav.c
> > > @@ -235,7 +235,7 @@ mux_msg_flushed_cb(GObject *source_object,
> > >  {
> > >  Client *client = user_data;
> > >
> > > -if 
> > > (!g_output_stream_write_all_finish(G_OUTPUT_STREAM(source_object), 
> > > result, NULL, NULL) ||
> > > +if (spice_vmc_write_finish(SPICE_CHANNEL(source_object), result, 
> > > NULL) == -1 ||
> > >  client->mux.size == 0 ||
> > >  !client_start_read(client)) {
> > >  remove_client(client);
> > > @@ -249,8 +249,6 @@ static void server_reply_cb(GObject *source_object,
> > >  gpointer user_data)
> > >  {
> > >  Client *client = user_data;
> > > -SpiceWebdavChannelPrivate *c = client->self->priv;
> > > -GOutputStream *mux_out;
> > >  GError *err = NULL;
> > >  gssize size;
> > >
> > > @@ -262,13 +260,12 @@ static void server_reply_cb(GObject *source_object,
> > >  g_return_if_fail(size >= 0);
> > >  client->mux.size = GUINT16_TO_LE(size);
> > >
> > > -mux_out = g_io_stream_get_output_stream(G_IO_STREAM(c->stream));
> > > -
> > > -/* this internally uses spice_vmc_write_async(), priority is ignored;
> > > - * the callback is invoked once the msg is written out to the socket 
> > > */
> > > -g_output_stream_write_all_async(mux_out, (guint8 *)&client->mux, 
> > > sizeof(gint64) + sizeof(guint16) + size,
> > > -G_PRIORITY_DEFAULT, client->cancellable, mux_msg_flushed_cb, 
> > > client);
> > > -
> > > +spice_vmc_write_async(SPICE_CHANNE

[Spice-devel] phodav: OutputQueue refactor & misc

[Jakub Janku]

https://gitlab.gnome.org/GNOME/phodav/merge_requests/5/

ping

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

Re: [Spice-devel] Is it possible to put spice channels into different threads?

[Jakub Janku]

Hi,

yes, I think this is a real issue. I feel like I've stumbled across
something similar in the past when working on webdav.

So yeah, it seems like the channel might get blocked in one direction
-- meaning data isn't sent until you read all available data.

However, that doesn't mean that other channels won't work imho. In a
more realistic scenario, you wold read the data from vdagent in chunks
and actually do something with it. Webdav uses the code in vmcstream.c
to read the data in coroutine and the buffer is delivered to the
WebdavChannel using an idle callback. This gives other events the
opportunity to fire and be processed and the code can yield to another
coroutine. So important channels, like Display, should continue
working just fine.

PS, it's been quite some time, so I might not remember it correctly.
But anyway, if you look at channel-webdav.c and vmcstream.c, you
should hopefully get a better idea.

Cheers,
Jakub

On Mon, Jun 15, 2020 at 12:52 PM 陈炤  wrote:
>
> Hi,
>
> After debugging, I  think my problem is probably not accociated with 
> cooperative multitasking.
> Here is where spice-gtk read data:
>
> /* treat all incoming data (block on message completion) */
> while (!c->has_error &&
>c->state != SPICE_CHANNEL_STATE_MIGRATING &&
>g_pollable_input_stream_is_readable(G_POLLABLE_INPUT_STREAM(c->in))
> ) { do
> spice_channel_recv_msg(channel,
>
> (handler_msg_in)SPICE_CHANNEL_GET_CLASS(channel)->handle_msg, NULL);
> #ifdef HAVE_SASL
> /* flush the sasl buffer too */
> while (c->sasl_decoded != NULL);
> #else
> while (FALSE);
> #endif
> }
>
>
> If vdagent sends lots of data, spice_channel_recv_msg will be called the 
> whole time, so iterate_write will not be called, and data will not be sent 
> out unless vdagent stops sending data.
>
> BR
> Don
>
>
>
>
> At 2020-06-13 14:40:02, "Frediano Ziglio"  wrote:
>
> Hi,
>   the pattern used in spice-gtk is called cooperative multitasking (see 
> https://en.wikipedia.org/wiki/Cooperative_multitasking), if you add code that 
> is not cooperative you get what you described. Use coroutine functions to 
> read remote data so the read won't stop other code. If you need to run 
> expensive or blocking code it's a good idea to run it in another thread 
> removing the blockage.
>
> Frediano
>
> 
>
>
>
> Hi
>
> Here is my experiment:
> I created a new port-channel to transfer data between vdagent and spice-gtk. 
> I used a while loop to send 2kb data to gtk, gtk received and drop the data. 
> In the mean time I used a timer(1ms) to send 2kb data to vdagent.
> Strange thing is that gtk will continually receive data for a while(10secs - 
> 70secs) then send a whole bunch of data to vdagent. When receiving data, send 
> data will be added to tcp buffer but will not be sent out.
>
> So I think send event will be affected by receive event, then I guess using 
> different thread would help.
> Could you please correct me if I’m wrong?
>
> BR
> Don
>
>
>
>
>
>
>
>
> 在 2020-06-12 20:03:30，"Marc-André Lureau"  写道：
>
> Hi
>
> On Fri, Jun 12, 2020 at 12:57 PM 陈炤  wrote:
>>
>> Hi,
>>
>> Spice-gtk is now using co-routine to handle different channel connections. 
>> When a channel is handling data, other channels would have to wait, rather 
>> than handling synchronously.  That would bring us following issues:
>>  1. If some less important channels (like usb channels) are transfering big 
>> data, important channels (main-channel, display-channel,input-channel) will 
>> be affected.
>>  2. When receiving big data like file transfering(G_IO_IN), send event 
>> (G_IO_OUT) will not be triggered.
>>  3. Flow control between different channels will be hard to do.
>>
>> Is is possible(and make sense) to put channels into different threads so 
>> they can synchronously receive & send msg, without affect each other?
>>
>
> Switching to threads would be possible, but that wouldn't help in the 
> situation you describe, as you are very likely bound on IO. Using several 
> threads would actually create more problems to synchronize and schedule the 
> different channels.
>
> Io operations in coroutines are non-blocking, so they shouldn't affect other 
> spice-gtk task. If you however observe a blocking CPU-task in some channel, 
> this may affect the performance of other channels. But in general, except for 
> video/image decoding which may be done in a separate thread, the client side 
> doesn't do much work.
>
> USB, clipboard and file sharing may use large amounts of data, and we rely on 
> the glib source and kernel to prioritize channels: this isn't great in some 
> cases and may receive improvements.
>
>
> --
> Marc-André Lureau
>
>
>
>
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
> __

Re: [Spice-devel] Can't write from guest to host with webdav

[Jakub Janku]

Hi!

On Sun, Jul 19, 2020 at 9:34 AM Koopa Koopa  wrote:
>
> Hi all,
>
> I'm looking to share a folder between my Arch Linux host and a Windows 10 
> guest, and SPICE's folder sharing with webdav seems to be the best option for 
> me. I've set up the QEMU devices that webdav needs, and installed the Windows 
> service. I have the drive mapped, and am able to navigate the host folder 
> (apart from the occasional "Windows cannot access 
> \\localhost@9843\DavWWWRoot\" that doesn't occur again), and copy files from 
> the host to the guest. When trying to copy a new file (with data) or write to 
> an existing file from the guest, though, the application (e.g. File Explorer, 
> or other programs which save files) hangs for a little bit, before the 
> transaction fails. For File Explorer, it displays "Error 0x80070021: The 
> process cannot access the file because another process has locked a portion 
> of the file."
>
> This is the output of remote-viewer:
>   (remote-viewer:16120): GSpice-WARNING **: 12:58:46.205: Warning no 
> automount-inhibiting implementation available

As you say, this happens in non-GNOME environments. But it's related
to usb redirection, not webdav.
>
>   (remote-viewer:16120): phodav-WARNING **: 12:58:57.910: 
> (../phodav-2.4/libphodav/phodav-method-propfind.c:70):prop_resourcetype: code 
> should not be reached
>
>   (remote-viewer:16120): phodav-WARNING **: 12:59:04.714: 
> (../phodav-2.4/libphodav/phodav-method-propfind.c:70):prop_resourcetype: code 
> should not be reached

I know that these warnings can happen for example if the shared folder
contains a broken symlink. Is that your case? Basically anything in
the shared folder that isn't a regular file or a directory can emit
this warning, but it shouldn't cause the described issues afaik.
>
>   (remote-viewer:16120): GSpice-WARNING **: 12:59:04.793: 
> (../spice-gtk-0.38/src/channel-webdav.c:330):demux_to_client_cb: runtime 
> check failed: (size == c->demux.size)
>   phodav-Message: 13:00:06.047: missing lock: /testfile 
> urn:uuid:ceb212f1-f8af-4dd3-b36c-a7e627b6c08a
>   phodav-Message: 13:00:06.062: missing lock: /testfile 
> urn:uuid:ceb212f1-f8af-4dd3-b36c-a7e627b6c08a
>   phodav-Message: 13:00:06.076: missing lock: /testfile 
> urn:uuid:ceb212f1-f8af-4dd3-b36c-a7e627b6c08a

I'm not able to reproduce it, so more logs would be helpful.
Could you please run remote-viewer or spicy with the following options
and attach the output?
G_MESSAGES_DEBUG=phodav remote-viewer --spice-debug

>
> I read that the first GSpice error always occurs on non-GNOME host 
> environments. The phodav error occurs whenever I view the root directory of 
> the share, or try copying/writing to a file anywhere in the share. The second 
> GSpice and other phodav messages occur when copying/writing a file in the 
> share.
>
> This occurs both with remote-viewer, and spicy. The same result occurs 
> whether or not I have the "Read only" checkbox in remote-viewer checked.
>
> Thanks!
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel

Thanks,
Jakub

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

Re: [Spice-devel] Can't write from guest to host with webdav

[Jakub Janku]

On Sun, Jul 19, 2020 at 6:12 PM Koopa Koopa  wrote:
>
> On 7/19/20, Jakub Janku  wrote:
> > Hi!
> >
> > On Sun, Jul 19, 2020 at 9:34 AM Koopa Koopa  wrote:
> >>
> >> Hi all,
> >>
> >> I'm looking to share a folder between my Arch Linux host and a Windows 10
> >> guest, and SPICE's folder sharing with webdav seems to be the best option
> >> for me. I've set up the QEMU devices that webdav needs, and installed the
> >> Windows service. I have the drive mapped, and am able to navigate the host
> >> folder (apart from the occasional "Windows cannot access
> >> \\localhost@9843\DavWWWRoot\" that doesn't occur again), and copy files
> >> from the host to the guest. When trying to copy a new file (with data) or
> >> write to an existing file from the guest, though, the application (e.g.
> >> File Explorer, or other programs which save files) hangs for a little bit,
> >> before the transaction fails. For File Explorer, it displays "Error
> >> 0x80070021: The process cannot access the file because another process has
> >> locked a portion of the file."
> >>
> >> This is the output of remote-viewer:
> >>   (remote-viewer:16120): GSpice-WARNING **: 12:58:46.205: Warning no
> >> automount-inhibiting implementation available
> >
> > As you say, this happens in non-GNOME environments. But it's related
> > to usb redirection, not webdav.
> >>
> >>   (remote-viewer:16120): phodav-WARNING **: 12:58:57.910:
> >> (../phodav-2.4/libphodav/phodav-method-propfind.c:70):prop_resourcetype:
> >> code should not be reached
> >>
> >>   (remote-viewer:16120): phodav-WARNING **: 12:59:04.714:
> >> (../phodav-2.4/libphodav/phodav-method-propfind.c:70):prop_resourcetype:
> >> code should not be reached
> >
> > I know that these warnings can happen for example if the shared folder
> > contains a broken symlink. Is that your case? Basically anything in
> > the shared folder that isn't a regular file or a directory can emit
> > this warning, but it shouldn't cause the described issues afaik.
>
> Yep, that is the case. I had a broken symlink in the root directory of
> my share, which explains why that error only occurred in that
> directory. I've removed that file, and that error no longer occurs.

Great, so that makes this one clear.
>
> As for the main issue, upon some more testing, I've determined that:
> - I can copy files to the root of a $HOME share.
> - I cannot copy files to a mounted device within the $HOME share.
> - I cannot copy files to a share created at or within the mountpoint.
>
> The drive that my $HOME is on is ext4, and the mounted device (in
> fact, there are two of these in my home directory) is NTFS.

How frequent is this issue? Can you copy larger files?
>
> >>
> >>   (remote-viewer:16120): GSpice-WARNING **: 12:59:04.793:
> >> (../spice-gtk-0.38/src/channel-webdav.c:330):demux_to_client_cb: runtime
> >> check failed: (size == c->demux.size)
> >>   phodav-Message: 13:00:06.047: missing lock: /testfile
> >> urn:uuid:ceb212f1-f8af-4dd3-b36c-a7e627b6c08a
> >>   phodav-Message: 13:00:06.062: missing lock: /testfile
> >> urn:uuid:ceb212f1-f8af-4dd3-b36c-a7e627b6c08a
> >>   phodav-Message: 13:00:06.076: missing lock: /testfile
> >> urn:uuid:ceb212f1-f8af-4dd3-b36c-a7e627b6c08a
> >
> > I'm not able to reproduce it, so more logs would be helpful.
> > Could you please run remote-viewer or spicy with the following options
> > and attach the output?
> > G_MESSAGES_DEBUG=phodav remote-viewer --spice-debug
> >
>
> Sure. I've attached a remote-viewer log ran with those parameters,
> from right before I copied the file, until the File Explorer error was
> displayed. I had a share set up to where the mountpoint is the shared
> directory, and copied a file named "export1.csv" to the root of the
> share.

Thanks a lot!

Would you be able to recompile spice-gtk with the attached patch (it
adds some more logs and could perhaps fix the issue)? If so, please
send the output in the same fashion as you did now, spicy is just fine
for this purpose.

Cheers,
Jakub
>
> >>
> >> I read that the first GSpice error always occurs on non-GNOME host
> >> environments. The phodav error occurs whenever I view the root directory
> >> of the share, or try copying/writing to a file anywhere in the share. The
> >> second GSpice and other phodav messages occur when copying/writing a file
> >> in the share.
> >>

Re: [Spice-devel] Can't write from guest to host with webdav

[Jakub Janku]

On Sun, Jul 19, 2020 at 10:04 PM Koopa Koopa  wrote:
>
> On 7/19/20, Jakub Janku  wrote:
> > On Sun, Jul 19, 2020 at 6:12 PM Koopa Koopa  wrote:
> >>
> >> On 7/19/20, Jakub Janku  wrote:
> >> > Hi!
> >> >
> >> > On Sun, Jul 19, 2020 at 9:34 AM Koopa Koopa 
> >> > wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I'm looking to share a folder between my Arch Linux host and a Windows
> >> >> 10
> >> >> guest, and SPICE's folder sharing with webdav seems to be the best
> >> >> option
> >> >> for me. I've set up the QEMU devices that webdav needs, and installed
> >> >> the
> >> >> Windows service. I have the drive mapped, and am able to navigate the
> >> >> host
> >> >> folder (apart from the occasional "Windows cannot access
> >> >> \\localhost@9843\DavWWWRoot\" that doesn't occur again), and copy
> >> >> files
> >> >> from the host to the guest. When trying to copy a new file (with data)
> >> >> or
> >> >> write to an existing file from the guest, though, the application
> >> >> (e.g.
> >> >> File Explorer, or other programs which save files) hangs for a little
> >> >> bit,
> >> >> before the transaction fails. For File Explorer, it displays "Error
> >> >> 0x80070021: The process cannot access the file because another process
> >> >> has
> >> >> locked a portion of the file."
> >> >>
> >> >> This is the output of remote-viewer:
> >> >>   (remote-viewer:16120): GSpice-WARNING **: 12:58:46.205: Warning no
> >> >> automount-inhibiting implementation available
> >> >
> >> > As you say, this happens in non-GNOME environments. But it's related
> >> > to usb redirection, not webdav.
> >> >>
> >> >>   (remote-viewer:16120): phodav-WARNING **: 12:58:57.910:
> >> >> (../phodav-2.4/libphodav/phodav-method-propfind.c:70):prop_resourcetype:
> >> >> code should not be reached
> >> >>
> >> >>   (remote-viewer:16120): phodav-WARNING **: 12:59:04.714:
> >> >> (../phodav-2.4/libphodav/phodav-method-propfind.c:70):prop_resourcetype:
> >> >> code should not be reached
> >> >
> >> > I know that these warnings can happen for example if the shared folder
> >> > contains a broken symlink. Is that your case? Basically anything in
> >> > the shared folder that isn't a regular file or a directory can emit
> >> > this warning, but it shouldn't cause the described issues afaik.
> >>
> >> Yep, that is the case. I had a broken symlink in the root directory of
> >> my share, which explains why that error only occurred in that
> >> directory. I've removed that file, and that error no longer occurs.
> >
> > Great, so that makes this one clear.
> >>
> >> As for the main issue, upon some more testing, I've determined that:
> >> - I can copy files to the root of a $HOME share.
> >> - I cannot copy files to a mounted device within the $HOME share.
> >> - I cannot copy files to a share created at or within the mountpoint.
> >>
> >> The drive that my $HOME is on is ext4, and the mounted device (in
> >> fact, there are two of these in my home directory) is NTFS.
> >
> > How frequent is this issue? Can you copy larger files?
>
> It can be quite inconsistent. Currently, with the $HOME share -
> without directly interacting with the mountpoint, I'm experiencing
> either not being to copy to or from the host. Sometimes one works,
> sometimes neither works. This seems to function the same between
> remote-viewer and spicy.

Ok, I suspected that it might be an issue with timing, so it makes
sense that it's inconsistent.
>
> With regards to file size, I have been using a 1.85KB CSV file and
> 11.7KB PNG file. Trying a 256MB MKV file, it is able to transfer form
> the guest to the host (that is, when that direction is working with
> other files too), but never from the host to the guest. Copying the
> exact file that I had copied from the guest, back to the guest, I get
> an error in File Explorer: "Error 0x800700DF: The file size exceeds
> the limit allowed and cannot be saved."

Yes, that's a known issue, the limit is set by Windows, but can be adjusted.
See this Gitlab report, the

Re: [Spice-devel] [Spice-commits] 6 commits - meson.build src/map-file src/spice-glib-sym-file src/spice-gtk-session.c src/spice-session.c src/spice-session.h src/spice-session-priv.h

[Jakub Janku]

On Wed, Sep 9, 2020 at 4:16 PM Frediano Ziglio  wrote:
>
> > > commit 4b9092b96b8da946ff3d17922b0fcf225c5dc81f
> >
> > > Author: Jakub Janků < jja...@redhat.com >
> >
> > > Date: Sat May 23 16:28:52 2020 +0200
> >
>
> > > session: make spice_session_get_webdav_server() public
> >
>
> > > It will be necessary to access the webdav server from spice-gtk-session.c
> >
> > > which isn't compiled with spice-session-priv.h, so make
> >
> > > spice_session_get_webdav_server() public.
> >
>
> > I haven't looked at the whole series. Wouldn't it make sense to make it a
> > read-only property instead?
>
> It sounds reasonable for me.
> Jakub ?
>

I agree.

Revert the commits please. I'll reopen the merge request once I have it ready.

Cheers,
Jakub

> Frediano
>

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

Re: [Spice-devel] [Spice-commits] 6 commits - meson.build src/map-file src/spice-glib-sym-file src/spice-gtk-session.c src/spice-session.c src/spice-session.h src/spice-session-priv.h

[Jakub Janku]

On Wed, Sep 9, 2020 at 4:36 PM Frediano Ziglio  wrote:
>
> > On Wed, Sep 9, 2020 at 4:16 PM Frediano Ziglio  wrote:
> > >
> > > > > commit 4b9092b96b8da946ff3d17922b0fcf225c5dc81f
> > > >
> > > > > Author: Jakub Janků < jja...@redhat.com >
> > > >
> > > > > Date: Sat May 23 16:28:52 2020 +0200
> > > >
> > >
> > > > > session: make spice_session_get_webdav_server() public
> > > >
> > >
> > > > > It will be necessary to access the webdav server from
> > > > > spice-gtk-session.c
> > > >
> > > > > which isn't compiled with spice-session-priv.h, so make
> > > >
> > > > > spice_session_get_webdav_server() public.
> > > >
> > >
> > > > I haven't looked at the whole series. Wouldn't it make sense to make it 
> > > > a
> > > > read-only property instead?
> > >
> > > It sounds reasonable for me.
> > > Jakub ?
> > >
> >
> > I agree.
> >
> > Revert the commits please. I'll reopen the merge request once I have it
> > ready.
> >
> > Cheers,
> > Jakub
> >
>
> To be honest I don't see the need to revert commits, it's just a change
> from public to private.

Ok, so should I open a separate MR?

To make sure that I didn't misunderstand it: the suggestion is to keep
spice_session_get_webdav_server() private and install a new
SpiceSession read-only property "webdav", correct?
>
> Frediano
>

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

Re: [Spice-devel] [Spice-commits] 6 commits - meson.build src/map-file src/spice-glib-sym-file src/spice-gtk-session.c src/spice-session.c src/spice-session.h src/spice-session-priv.h

[Jakub Janku]

On Wed, Sep 9, 2020 at 5:27 PM Frediano Ziglio  wrote:
>
> > Hi
>
> > On Wed, Sep 9, 2020 at 6:45 PM Jakub Janku < jja...@redhat.com > wrote:
>
> > > On Wed, Sep 9, 2020 at 4:36 PM Frediano Ziglio < fzig...@redhat.com >
> > > wrote:
> >
> > > >
> >
> > > > > On Wed, Sep 9, 2020 at 4:16 PM Frediano Ziglio < fzig...@redhat.com >
> > > > > wrote:
> >
> > > > > >
> >
> > > > > > > > commit 4b9092b96b8da946ff3d17922b0fcf225c5dc81f
> >
> > > > > > >
> >
> > > > > > > > Author: Jakub Janků < jja...@redhat.com >
> >
> > > > > > >
> >
> > > > > > > > Date: Sat May 23 16:28:52 2020 +0200
> >
> > > > > > >
> >
> > > > > >
> >
> > > > > > > > session: make spice_session_get_webdav_server() public
> >
> > > > > > >
> >
> > > > > >
> >
> > > > > > > > It will be necessary to access the webdav server from
> >
> > > > > > > > spice-gtk-session.c
> >
> > > > > > >
> >
> > > > > > > > which isn't compiled with spice-session-priv.h, so make
> >
> > > > > > >
> >
> > > > > > > > spice_session_get_webdav_server() public.
> >
> > > > > > >
> >
> > > > > >
> >
> > > > > > > I haven't looked at the whole series. Wouldn't it make sense to
> > > > > > > make
> > > > > > > it a
> >
> > > > > > > read-only property instead?
> >
> > > > > >
> >
> > > > > > It sounds reasonable for me.
> >
> > > > > > Jakub ?
> >
> > > > > >
> >
> > > > >
> >
> > > > > I agree.
> >
> > > > >
> >
> > > > > Revert the commits please. I'll reopen the merge request once I have 
> > > > > it
> >
> > > > > ready.
> >
> > > > >
> >
> > > > > Cheers,
> >
> > > > > Jakub
> >
> > > > >
> >
> > > >
> >
> > > > To be honest I don't see the need to revert commits, it's just a change
> >
> > > > from public to private.
> >
>
> > > Ok, so should I open a separate MR?
> >
>
> > > To make sure that I didn't misunderstand it: the suggestion is to keep
> >
> > > spice_session_get_webdav_server() private and install a new
> >
> > > SpiceSession read-only property "webdav", correct?
> >
>
> > yes (the main motivation is to avoid adding new library symbols, and
> > properties can be looked up at runtime, which may avoid bumping dependencies
> > in some cases)
>
> Oh, I though the idea was making the new property private to in the future it 
> could be removed if not needed anymore.
> You can achieve the dynamic resolution using dlsym if needed using library 
> symbols.
> It's not that easy to look the property dynamically, to avoid warnings you 
> have to use g_object_class_find_property first.
> For a "get" between spice-gtk and spice-glib the current solution is easier 
> and consistent, there are already multiple spice_session_get_* functions.

Most of the getters are in spice-session-priv.h though. In
spice-session.h, there's only three of them.
So perhaps it would be more consistent to access the phodav server
using properties, as Marc-André suggested.

Anyway, here's the possible patch
https://gitlab.freedesktop.org/jjanku/spice-gtk/-/commit/048a150f8088d9fd643ba9987c8fba9e83494d94

Jakub
>
> Frediano
>

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

Re: [Spice-devel] How to build Windows vdagent?

[Jakub Janku]

Hi,

are you using mingw64-configure?
Sometimes, when you don't know how to build something, you can get
some hints from the pipeline configuration file, in this case
.gitlab-ci.yml.

Regards,
Jakub

On Thu, Oct 29, 2020 at 4:10 PM Ian Pilcher  wrote:
>
> On 10/29/20 3:10 AM, Frediano Ziglio wrote:
> > It depends on the environment you want to use.
> > Either you can use MingW + classic Autoconf (configure) and compile as many 
> > Unix
> > projects (better to have a Linux machine) or you can use CMake, better 
> > suited
> > for use with Visual Studio (for instance).
>
> The MingW/Linux (Fedora) option would be easiest for me, but I can't get
> it to work; I can't figure how to get around this error:
>
>configure: error: static libpng not found
>
> I have installed every single *libpng* package in Fedora:
>
> $ sudo dnf list '*libpng*'
> Last metadata expiration check: 2:32:12 ago on Thu 29 Oct 2020 07:37:22
> AM CDT.
> Installed Packages
> libpng.i6862:1.6.37-3.fc32   @fedora
> libpng.x86_64  2:1.6.37-3.fc32   @fedora
> libpng-devel.i686  2:1.6.37-3.fc32   @fedora
> libpng-devel.x86_642:1.6.37-3.fc32   @fedora
> libpng-static.i686 2:1.6.37-3.fc32   @fedora
> libpng-static.x86_64   2:1.6.37-3.fc32   @fedora
> libpng-tools.x86_642:1.6.37-3.fc32   @fedora
> libpng12.i686  1.2.57-11.fc32@fedora
> libpng12.x86_641.2.57-11.fc32@fedora
> libpng12-devel.i6861.2.57-11.fc32@fedora
> libpng12-devel.x86_64  1.2.57-11.fc32@fedora
> libpng15.i686  1.5.30-9.fc32 @fedora
> libpng15.x86_641.5.30-9.fc32 @fedora
> mingw32-libpng.noarch  1.6.37-3.fc32 @fedora
> mingw32-libpng-static.noarch   1.6.37-3.fc32 @fedora
> mingw64-libpng.noarch  1.6.37-3.fc32 @fedora
> mingw64-libpng-static.noarch   1.6.37-3.fc32 @fedora
>
> --
> 
>   In Soviet Russia, Google searches you!
> 
> ___
> 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] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest

[Jakub Janku]

On Thu, Jan 11, 2018 at 3:29 PM, Marc-André Lureau
 wrote:
>
> Hi
>
> - Original Message -
> > On Wed, Jan 10, 2018 at 06:48:14PM -0500, Marc-André Lureau wrote:
> > > Hi
> > >
> > > - Original Message -
> > > > On Tue, Jan 09, 2018 at 12:16:33PM -0500, Marc-André Lureau wrote:
> > > > > I think it's problematic for traditional applications as well.
> > > > > clipboard access is probably going to be limited by default and only
> > > > > accessed through so-called "portals", just like file access etc. This
> > > > > topic should be brought on desktop / flatpak mailing list.
> > > >
> > > > Maybe in some distant future, all applications everyone is running will
> > > > be flatpak, and will be using portals to improve security. The same
> > > > thing can be said regarding wayland, which does not have this issue.
> > > > Some time in the future, this will become a non-issue. However, solving
> > > > this now on x11 is definitely not something which should be related to
> > > > portals/flatpak in my opinion.
> > >
> > > I propose a --spice-disable-clipboard, and client UI to switch on/off
> > > clipboard sharing functionality.
> > >
> > > Something different will likely break some clipboard users or lower
> > > experience.
> >
> > One additional note on that, I was initially worried about which use
> > cases were going to be broken by these changes. Then I realized that the
> > very same use cases would be broken when using wayland (after taking into
> > account Jakub's comments). Since this potential breakage will happen
> > anyway whether we want it or not, it's not going to make a big
> > difference if we do the same when running on  X11.
>
> So this change isn't needed for Wayland, and your patch changes the clipboard 
> behaviour to be similar as Wayland.
>
> Why couldn't this be done at Gtk level? This would give a similar clipboard 
> behaviour for all Gtk app wether they run on Wayland or X, or windows etc. 
> They would also benefit the same "added security".

Do you think this change would make it to GTK3? I think it could
potentially break some apps. Note that e.g. spice-vdagent takes
advantage of this "security issue" in X11 - it has no window and
listens for the clipboard changes all the time.
(it seems that clipboard system for GTK 4 has been reworked quite a
bit - see https://git.gnome.org/browse/gtk+/log/?h=wip/otte/clipboard
- this is already merged into master)

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

Re: [Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest

[Jakub Janku]

On Thu, Jan 11, 2018 at 5:42 PM, Marc-André Lureau
 wrote:
> Hi
>
> - Original Message -
>> On Thu, Jan 11, 2018 at 3:29 PM, Marc-André Lureau
>>  wrote:
>> >
>> > Hi
>> >
>> > - Original Message -
>> > > On Wed, Jan 10, 2018 at 06:48:14PM -0500, Marc-André Lureau wrote:
>> > > > Hi
>> > > >
>> > > > - Original Message -
>> > > > > On Tue, Jan 09, 2018 at 12:16:33PM -0500, Marc-André Lureau wrote:
>> > > > > > I think it's problematic for traditional applications as well.
>> > > > > > clipboard access is probably going to be limited by default and
>> > > > > > only
>> > > > > > accessed through so-called "portals", just like file access etc.
>> > > > > > This
>> > > > > > topic should be brought on desktop / flatpak mailing list.
>> > > > >
>> > > > > Maybe in some distant future, all applications everyone is running
>> > > > > will
>> > > > > be flatpak, and will be using portals to improve security. The same
>> > > > > thing can be said regarding wayland, which does not have this issue.
>> > > > > Some time in the future, this will become a non-issue. However,
>> > > > > solving
>> > > > > this now on x11 is definitely not something which should be related
>> > > > > to
>> > > > > portals/flatpak in my opinion.
>> > > >
>> > > > I propose a --spice-disable-clipboard, and client UI to switch on/off
>> > > > clipboard sharing functionality.
>> > > >
>> > > > Something different will likely break some clipboard users or lower
>> > > > experience.
>> > >
>> > > One additional note on that, I was initially worried about which use
>> > > cases were going to be broken by these changes. Then I realized that the
>> > > very same use cases would be broken when using wayland (after taking into
>> > > account Jakub's comments). Since this potential breakage will happen
>> > > anyway whether we want it or not, it's not going to make a big
>> > > difference if we do the same when running on  X11.
>> >
>> > So this change isn't needed for Wayland, and your patch changes the
>> > clipboard behaviour to be similar as Wayland.
>> >
>> > Why couldn't this be done at Gtk level? This would give a similar clipboard
>> > behaviour for all Gtk app wether they run on Wayland or X, or windows etc.
>> > They would also benefit the same "added security".
>>
>> Do you think this change would make it to GTK3? I think it could
>> potentially break some apps. Note that e.g. spice-vdagent takes
>> advantage of this "security issue" in X11 - it has no window and
>> listens for the clipboard changes all the time.
>
> Those gtk applications would break on wayland today anyway, right?

Probably, unless you force GTK to use XWayland with
gdk_set_allowed_backends("x11").
But pushing this kind of change to GTK 3.22, which is supposed to be
stable, doesn't seem right to me.

>
>> (it seems that clipboard system for GTK 4 has been reworked quite a
>> bit - see https://git.gnome.org/browse/gtk+/log/?h=wip/otte/clipboard
>> - this is already merged into master)
>
> I have not much time to look at the details, but I don't think we should rush 
> into changing the behavior of the clipboard in spice only. This is more 
> windowing/toolkit level issue.

That's right, I just wanted to say it might take considerable amount
of time to fix this issue in spice if we were patching GTK.

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

Re: [Spice-devel] [PATCH vdagent 2/2] vdagent: handle clipboard using GTK+

[Jakub Janku]

Hi Victor,

sorry for the delayed reply.

On Mon, Feb 12, 2018 at 2:11 PM, Victor Toso  wrote:
> Hi,
>
> On Sun, Jan 21, 2018 at 09:03:14PM +0100, Jakub Janků wrote:
>> From: Jakub Janků 
>>
>> Place the code that handles clipboard
>> into a separate file - clipboard.c
>> ---
>>  Makefile.am |   2 +
>>  src/vdagent/clipboard.c | 401 
>> 
>>  src/vdagent/clipboard.h |  42 +
>>  src/vdagent/vdagent.c   |  31 +++-
>>  4 files changed, 471 insertions(+), 5 deletions(-)
>>  create mode 100644 src/vdagent/clipboard.c
>>  create mode 100644 src/vdagent/clipboard.h
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index c4bd3dd..88550c6 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -33,6 +33,8 @@ src_spice_vdagent_SOURCES = \
>>   $(common_sources)   \
>>   src/vdagent/audio.c \
>>   src/vdagent/audio.h \
>> + src/vdagent/clipboard.c \
>> + src/vdagent/clipboard.h \
>>   src/vdagent/file-xfers.c\
>>   src/vdagent/file-xfers.h\
>>   src/vdagent/x11-priv.h  \
>> diff --git a/src/vdagent/clipboard.c b/src/vdagent/clipboard.c
>> new file mode 100644
>> index 000..657a6b4
>> --- /dev/null
>> +++ b/src/vdagent/clipboard.c
>> @@ -0,0 +1,401 @@
>> +/*  clipboard.c - vdagent clipboard handling code
>> +
>> +Copyright 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 3 of the License, or
>> +(at your option) any later version.
>> +
>> +This program is distributed in the hope that it will be useful,
>> +but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +GNU General Public License for more details.
>> +
>> +You should have received a copy of the GNU General Public License
>> +along with this program.  If not, see .
>> +*/
>> +
>> +#ifdef HAVE_CONFIG_H
>> +# include 
>> +#endif
>> +
>> +#include 
>> +#include 
>> +
>> +#include "vdagentd-proto.h"
>> +#include "spice/vd_agent.h"
>> +#include "udscs.h"
>> +#include "clipboard.h"
>> +
>> +/* 2 selections supported - _SELECTION_CLIPBOARD = 0, _SELECTION_PRIMARY = 
>> 1 */
>> +#define SELECTION_COUNT (VD_AGENT_CLIPBOARD_SELECTION_PRIMARY + 1)
>> +#define TYPE_COUNT  (VD_AGENT_CLIPBOARD_IMAGE_JPG + 1)
>> +
>> +#define sel_from_clip(clipboard) \
>> +GPOINTER_TO_UINT(g_object_get_data(G_OBJECT(clipboard), 
>> "vdagent-selection"))
>> +
>> +enum {
>> +OWNER_NONE,
>> +OWNER_GUEST,
>> +OWNER_CLIENT
>> +};
>> +
>> +typedef struct {
>> +GMainLoop*loop;
>> +GtkSelectionData *sel_data;
>> +} DataRetrieval;
>> +
>> +struct VDAgentClipboards {
>> +struct udscs_connection*conn;
>> +
>> +GtkClipboard   *clipboard[SELECTION_COUNT];
>> +guint   owner[SELECTION_COUNT];
>> +
>> +GList  *data_retrievals[SELECTION_COUNT];
>> +GList  *data_requests[SELECTION_COUNT];
>
> I think we could use something more clear instead of
> 'data_retrievals' and 'data_requests' but I'm terrible with
> names myself so I suggest 'pending_set_request' and
> 'pending_get_requests' or just 'set_requests' and 'get_requests'.

I agree, the names are far from ideal and rather confusing, but
'set_requests' and 'get_requests' aren't making it more clear either
imho - "get request" could stand for a request from the client as well
as a request from an app on the vdagent side. What about
'request_from_client' and 'request_from_app'?
>
> A comment would help too, like /* Client -> Guest */ and vice
> versa.

Definitely, I should have added some comments.
>
>> +gpointer   *last_targets_req[SELECTION_COUNT];
>> +
>> +GdkAtom targets[SELECTION_COUNT][TYPE_COUNT];
>
> Maybe wrap them in inner struct { ... } selection[SELECTION_TYPE] ?
>
> e.g.
> - c->data_requests[sel] = ...
> + c->selection[id].data_request = ...
>
Makes sense probably. It might also be handy to typedef something like
DataSelection and use
  DataSelection *sel = &c->selection[sel_id];
  sel->data_requests = ...
where the struct members are accessed frequently.

>> +};
>> +
>> +static const struct {
>> +guint type;
>> +const gchar  *atom_name;
>> +} atom2agent[] = {
>> +{VD_AGENT_CLIPBOARD_UTF8_TEXT, "UTF8_STRING"},
>> +{VD_AGENT_CLIPBOARD_UTF8_TEXT, "text/plain;charset=utf-8"},
>> +{VD_AGENT_CLIPBOARD_UTF8_TEXT, "STRING"},
>> +{VD_AGENT_CLIPBOARD_UTF8_TEXT, "TEXT"},
>> +{VD_AGENT_CLIPBOARD_UTF8_TEXT, "text/plain"},
>> +{VD_AGENT_CLIPBOARD_IMAGE_PNG, "image/png"},
>> +

Re: [Spice-devel] [PATCH vdagent 1/2] vdagent-x11: remove clipboard handling

[Jakub Janku]

Hi,

On Mon, Feb 12, 2018 at 10:40 AM, Victor Toso  wrote:
> Hi,
>
> Follow up after the comment in the cover letter.
>
> On Sun, Jan 21, 2018 at 09:03:13PM +0100, Jakub Janků wrote:
>> From: Jakub Janků 
>>
>> The code will be replaced by GTK+ in the following patch.
>> ---
>>  src/vdagent/vdagent.c  |7 -
>>  src/vdagent/x11-priv.h |   91 
>>  src/vdagent/x11.c  | 1074 
>> +---
>>  src/vdagent/x11.h  |   10 -
>>  4 files changed, 1 insertion(+), 1181 deletions(-)
>>
>> diff --git a/src/vdagent/vdagent.c b/src/vdagent/vdagent.c
>> index d86ee25..92ffcf3 100644
>> --- a/src/vdagent/vdagent.c
>> +++ b/src/vdagent/vdagent.c
>> @@ -164,18 +164,12 @@ static void daemon_read_complete(struct 
>> udscs_connection **connp,
>>  vdagent_x11_set_monitor_config(agent->x11, (VDAgentMonitorsConfig 
>> *)data, 0);
>>  break;
>>  case VDAGENTD_CLIPBOARD_REQUEST:
>> -vdagent_x11_clipboard_request(agent->x11, header->arg1, 
>> header->arg2);
>>  break;
>>  case VDAGENTD_CLIPBOARD_GRAB:
>> -vdagent_x11_clipboard_grab(agent->x11, header->arg1, (uint32_t 
>> *)data,
>> -   header->size / sizeof(uint32_t));
>>  break;
>>  case VDAGENTD_CLIPBOARD_DATA:
>> -vdagent_x11_clipboard_data(agent->x11, header->arg1, header->arg2,
>> -   data, header->size);
>>  break;
>>  case VDAGENTD_CLIPBOARD_RELEASE:
>> -vdagent_x11_clipboard_release(agent->x11, header->arg1);
>>  break;
>>  case VDAGENTD_VERSION:
>>  if (strcmp((char *)data, VERSION) != 0) {
>> @@ -228,7 +222,6 @@ static void daemon_read_complete(struct udscs_connection 
>> **connp,
>>  }
>>  break;
>>  case VDAGENTD_CLIENT_DISCONNECTED:
>> -vdagent_x11_client_disconnected(agent->x11);
>
> So, instead of removing the vdagent_x11 calls, you could
> introduce the clipboard.[ch] and use the renamed calls here that
> will call the x11 code for now.

Seems reasonable (including the proposal in cover letter comment),
I'll change it with v2.

  Jakub
>
> Reviewed-by: Victor Toso 
>
> toso
>
>>  if (vdagent_finalize_file_xfer(agent)) {
>>  vdagent_init_file_xfer(agent);
>>  }
>> diff --git a/src/vdagent/x11-priv.h b/src/vdagent/x11-priv.h
>> index 3776098..627e0ed 100644
>> --- a/src/vdagent/x11-priv.h
>> +++ b/src/vdagent/x11-priv.h
>> @@ -1,118 +1,27 @@
>>  #ifndef VDAGENT_X11_PRIV
>>  #define VDAGENT_X11_PRIV
>>
>> -#include 
>> -#include 
>> -
>> -#include 
>> -
>>  #include 
>>
>> -/* Macros to print a message to the logfile prefixed by the selection */
>> -#define SELPRINTF(format, ...) \
>> -syslog(LOG_ERR, "%s: " format, \
>> -vdagent_x11_sel_to_str(selection), ##__VA_ARGS__)
>> -
>> -#define VSELPRINTF(format, ...) \
>> -do { \
>> -if (x11->debug) { \
>> -syslog(LOG_DEBUG, "%s: " format, \
>> -vdagent_x11_sel_to_str(selection), ##__VA_ARGS__); \
>> -} \
>> -} while (0)
>> -
>>  #define MAX_SCREENS 16
>>  /* Same as qxl_dev.h client_monitors_config.heads count */
>>  #define MONITOR_SIZE_COUNT 64
>>
>> -enum { owner_none, owner_guest, owner_client };
>> -
>> -/* X11 terminology is confusing a selection request is a request from an
>> -   app to get clipboard data from us, so iow from the spice client through
>> -   the vdagent channel. We handle these one at a time and queue any which
>> -   come in while we are still handling the current one. */
>> -struct vdagent_x11_selection_request {
>> -XEvent event;
>> -uint8_t selection;
>> -struct vdagent_x11_selection_request *next;
>> -};
>> -
>> -/* A conversion request is X11 speak for asking another app to give its
>> -   clipboard data to us, we do these on behalf of the spice client to copy
>> -   data from the guest to the client. Like selection requests we process
>> -   these one at a time. */
>> -struct vdagent_x11_conversion_request {
>> -Atom target;
>> -uint8_t selection;
>> -struct vdagent_x11_conversion_request *next;
>> -};
>> -
>> -struct clipboard_format_tmpl {
>> -uint32_t type;
>> -const char *atom_names[16];
>> -};
>> -
>> -struct clipboard_format_info {
>> -uint32_t type;
>> -Atom atoms[16];
>> -int atom_count;
>> -};
>> -
>>  struct monitor_size {
>>  int width;
>>  int height;
>>  };
>>
>> -static const struct clipboard_format_tmpl clipboard_format_templates[] = {
>> -{ VD_AGENT_CLIPBOARD_UTF8_TEXT, { "UTF8_STRING", 
>> "text/plain;charset=UTF-8",
>> -  "text/plain;charset=utf-8", "STRING", NULL }, },
>> -{ VD_AGENT_CLIPBOARD_IMAGE_PNG, { "image/png", NULL }, },
>> -{ VD_AGENT_CLIPBOARD_IMAGE_BMP, { "image/bmp", "image/x-bmp",
>> -  "image/x-MS-bmp", "image/x-win-bitmap", NULL }, },
>> -{ VD_AGENT_CLIPBOARD_IMAGE_TIFF, { "image/tiff", NULL }, },
>> -{ VD_AGENT_CLIPBOARD_IMAGE_

Re: [Spice-devel] [PATCH vdagent v2 1/1] vdagent: add GTK+ clipboard handling

[Jakub Janku]

Hi Victor,

On Tue, Feb 27, 2018 at 9:02 AM, Victor Toso  wrote:
> Hi Jakub,
>
> On Mon, Feb 26, 2018 at 08:01:28PM +0100, Jakub Janků wrote:
>> From: Jakub Janků 
>>
>> Add clipboard handling that uses GTK+ instead of Xlib.
>> Place the code into new files: clipboard.c, clipboard.h
>>
>> Use the old Xlib implementation by default.
>> Add configure option --with-gtk-clipboard.
>> Guard the code by WITH_GTK_CLIPBOARD variable -
>> compile vdagent either with GTK+ impl or with the Xlib one.
>> ---
>>  Makefile.am |   6 +
>>  configure.ac|  11 ++
>>  src/vdagent/clipboard.c | 430 
>> 
>>  src/vdagent/clipboard.h |  42 +
>>  src/vdagent/vdagent.c   |  53 +-
>>  src/vdagent/x11-priv.h  |  20 +++
>>  src/vdagent/x11.c   |  30 +++-
>>  src/vdagent/x11.h   |   6 +
>>  8 files changed, 590 insertions(+), 8 deletions(-)
>>  create mode 100644 src/vdagent/clipboard.c
>>  create mode 100644 src/vdagent/clipboard.h
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index c4bd3dd..1d06928 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -85,6 +85,12 @@ src_spice_vdagentd_SOURCES += 
>> src/vdagentd/dummy-session-info.c
>>  endif
>>  endif
>>
>> +if WITH_GTK_CLIPBOARD
>> +src_spice_vdagent_SOURCES += \
>> + src/vdagent/clipboard.c \
>> + src/vdagent/clipboard.h
>> +endif
>> +
>
> Not exactly what I had in mind. The clipboad.[ch] is only
> handling gtk code and the decision between gtk/x11 is on
> vdagent.c by using #ifdef WITH_GTK_CLIPBOARD.
>
> The only thing that vdagent.c has that clipboard.c doesn't in
> order to handle the x11 clipboard is the x11 handler and "x11.h"
> include for vdagent_x11_clipboard_*()
>
> I think we could have one patch to simply introduce
> clipboard.[ch] with vdagent_clipboards_*() functions that should
> call the vdagent_x11_*() ones; and then a second patch that
> introduces the gtk related code for clipboard, including
> --with-gtk-clipboard. What do you think?

The vdagent_x11_*() calls require struct *vdagent_x11 as argument, so
we would need to store it in the VDAgentClipboards struct.
It seemed more clear to me to have clipboard.* files with gtk code
only and don't bother with x11.h and WITH_GTK_CLIPBOARD here.
But I'm completely fine with your approach too.
>
> More comments in-line.
>
>>  xdgautostartdir = $(sysconfdir)/xdg/autostart
>>  xdgautostart_DATA = $(top_srcdir)/data/spice-vdagent.desktop
>>
>> diff --git a/configure.ac b/configure.ac
>> index 1eb17a9..9a85870 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -75,6 +75,15 @@ if test "x$init_systemd" = "xyes"; then
>>fi
>>  fi
>>
>> +AC_ARG_WITH([gtk-clipboard],
>> +[AS_HELP_STRING([--with-gtk-clipboard], [Handle clipboard using 
>> GTK+ instead of Xlib])],
>> +[],
>> +[with_gtk_clipboard="no"])
>
> Maybe we could have default set to "auto". Packagers are going to
> notice the extra dependency + release notes and could chose
> between enabling/disabling this.
>
OK. But the behavior should stay the same - auto = use Xlib, right?

>> +if test "x$with_gtk_clipboard" = "xyes"; then
>> +  AC_DEFINE([WITH_GTK_CLIPBOARD], [1], [If defined, vdagent will handle 
>> clipboard using GTK+])
>> +fi
>> +AM_CONDITIONAL([WITH_GTK_CLIPBOARD], [test "x$with_gtk_clipboard" = "xyes"])
>> +
>>  AC_ARG_ENABLE([pciaccess],
>>[AS_HELP_STRING([--enable-pciaccess], [Enable libpciaccess 
>> use for auto generation of Xinerama xorg.conf (default: yes)])],
>>[enable_pciaccess="$enableval"],
>> @@ -210,6 +219,8 @@ AC_MSG_NOTICE([
>>  install systemd service:  ${init_systemd}
>>  udevdir:  ${udevdir}
>>
>> +GTK+ clipboard:   ${with_gtk_clipboard}
>> +
>>  Now type 'make' to build $PACKAGE
>>
>>  ])
>> diff --git a/src/vdagent/clipboard.c b/src/vdagent/clipboard.c
>> new file mode 100644
>> index 000..5ca1d57
>> --- /dev/null
>> +++ b/src/vdagent/clipboard.c
>> @@ -0,0 +1,430 @@
>> +/*  clipboard.c - vdagent clipboard handling code
>> +
>> +Copyright 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 3 of the License, or
>> +(at your option) any later version.
>> +
>> +This program is distributed in the hope that it will be useful,
>> +but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +GNU General Public License for more details.
>> +
>> +You should have received a copy of the GNU General Public License
>> +along with this program.  If not, see .
>> +*/
>> +
>> +#ifdef HAVE_CONFIG_H
>> +# include 
>> +#endif
>> +
>> +#include 
>> +#include 
>> +
>> +#include "vdagentd-proto.h"
>> +#include "spice/v

Re: [Spice-devel] 3D and clipboard (was: Windows 10 KVM guest very slow in SPICE console)

[Jakub Janku]

Hi,

On Thu, Jun 28, 2018 at 4:53 PM, Frediano Ziglio  wrote:
>> 2018-06-26 14:06 GMT-05:00 Carlos González < piteccel...@gmail.com > :
>
>> > I guess the spice-server patch will need more testing before release?
>>
>
>> > Finally, and just mere curiosity,
>>
>> > with 3D would you perhaps mean 3D graphic acceleration?
>>
>> > Are there by chance plans for supporting host-to-guest copy-pasting of
>> > directories as well, instead of just files?
>>
As of now, copy-pasting of files isn't supported either.
You probably mean drag&drop of files, correct?

I'd definitely like to implement this feature, but don't expect it to
get upstream anytime soon.

If you want to copy multiple files or directories from host to guest
(or vice versa), your best bet currently is to use a shared folder.
>
>> Excuse me, any idea regarding these?
>> Or maybe try in a different thread?
>
>> Thanks again.
>
> For clipboard feature I'm not really expert here, Victor or Jakub are.
>
> For the 3D there are 2 cases:
> - Virgl, that is using the host card support from guest (more or less),
>   for Windows the state is quite early, missing currently the remote
>   part, not planned although there are some work;
> - vGPU/passthrought remoting. Is what we are investing more time.
> Why 2 solutions? With vGPU/passthrought you have either low scalability
> (like 1 GPU 1 VM, with Intel 1 GPU 3/4 VMs, with Nvidia you can have if
> I remember up to 16 VMs per GPU but is quite expensive) while with Virgl
> the scalability should be better.
>
> Frediano

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

Re: [Spice-devel] [RFC spice-vdagent 01/18] vdagentd: parse argv using GLib

[Jakub Janku]

Hi,

On Tue, Aug 28, 2018 at 7:16 AM Victor Toso  wrote:
>
> Hi,
>
> Just for reference, the output of spice-vdagentd -h before was:
>
>  | $ spice-vdagentd -h
>  | Usage: spice-vdagentd [OPTIONS]
>  |
>  | Spice guest agent daemon, version 0.17.0.
>  |
>  | Options:
>  |   -h print this text
>  |   -d log debug messages (use twice for extra info)
>  |   -s   set virtio serial port 
> [/dev/virtio-ports/com.redhat.spice.0]
>  |   -S   set udcs socket 
> [/var/run/spice-vdagentd/spice-vdagent-sock]
>  |   -uset uinput device   [/dev/uinput]
>  |   -f treat uinput device as fake; no ioctls
>  |   -x don't daemonize
>  |   -o Only handle one virtio serial session.
>  |   -X Disable systemd-logind integration
>
> and not it is:
>
>  | $ /usr/sbin/spice-vdagentd -h
>  | Usage:
>  |   spice-vdagentd [OPTION?]
>  |
>  |   Spice guest agent daemon, version 0.18.0
>  |
>  |   Help Options:
>  | -h, --helpShow help options
>  |
>  | Application Options:
>  |   -d, --debug   Log debug messages (use twice for 
> extra info)
>  |   -s, --virtio-serial-port-path Set virtio-serial path 
> (/dev/virtio-ports/com.redhat.spice.0)
>  |   -S, --vdagentd-socket Set spice-vdagentd socket 
> (/var/run/spice-vdagentd/spice-vdagent-sock)
>  |   -u, --uinput-device   Set uinput device (/dev/uinput)
>  |   -f, --fake-uinput Treat uinput device as fake; no 
> ioctls
>  |   -x, --foreground  Do not daemonize the agent
>  |   -o, --one-session Only handle one virtio serial 
> session
>  |   -X, --disable-session-integration Disable console kit and 
> systemd-logind integration
>
> I think that after "vdagentd: use GMainLoop" patch, we should
> also include glib's command line options.

Not sure what you are referring to here.
GLib uses environment variables instead of command line options,
AFAIK, doesn't it?
There's the gtk_get_option_group() that we use in vdagent.c, but I
don't know of anything similar for GLib.
>
> On Tue, Aug 14, 2018 at 08:53:35PM +0200, Jakub Janků wrote:
> > All command line options now have long names
> > as they are required by GLib.
>
> I think that adding the following to the commit log as a quick
> overview of current options and its long names might be helpful.

Sure.
>
> -d, --debug
> -s, --virtio-serial-port-path
> -S, --vdagentd-socket
> -u, --uinput-device
> -f, --fake-uinput
> -x, --foreground
> -o, --one-session
> -X, --disable-session-integration
>
> > Change types of some global variables that hold the options:
> > - const char * --> gchar *
> > - int  --> gboolean
> >
> > Define DEFAULT_UINPUT_DEVICE as "/dev/uinput",
> > since there's already DEFAULT_VIRTIO_PORT_PATH, VDAGENTD_SOCKET.
>
> Would you mind adding Signed-off-by: Name  ?
>
> (more below)
>
> > ---
> >  src/vdagentd/vdagentd.c | 149 ++--
> >  1 file changed, 82 insertions(+), 67 deletions(-)
> >
> > diff --git a/src/vdagentd/vdagentd.c b/src/vdagentd/vdagentd.c
> > index 682761a..d88bbc7 100644
> > --- a/src/vdagentd/vdagentd.c
> > +++ b/src/vdagentd/vdagentd.c
> > @@ -48,6 +48,8 @@
> >  #include "virtio-port.h"
> >  #include "session-info.h"
> >
> > +#define DEFAULT_UINPUT_DEVICE "/dev/uinput"
> > +
> >  struct agent_data {
> >  char *session;
> >  int width;
> > @@ -58,12 +60,16 @@ struct agent_data {
> >
> >  /* variables */
> >  static const char *pidfilename = 
> > "/var/run/spice-vdagentd/spice-vdagentd.pid";
> > -static const char *portdev = DEFAULT_VIRTIO_PORT_PATH;
> > -static const char *vdagentd_socket = VDAGENTD_SOCKET;
> > -static const char *uinput_device = "/dev/uinput";
> > +
> > +static gchar *portdev = NULL;
> > +static gchar *vdagentd_socket = NULL;
> > +static gchar *uinput_device = NULL;
> >  static int debug = 0;
> > -static int uinput_fake = 0;
> > -static int only_once = 0;
> > +static gboolean uinput_fake = FALSE;
> > +static gboolean only_once = FALSE;
> > +static gboolean do_daemonize = TRUE;
> > +static gboolean want_session_info = TRUE;
> > +
> >  static struct udscs_server *server = NULL;
> >  static struct vdagent_virtio_port *virtio_port = NULL;
> >  static GHashTable *active_xfers = NULL;
> > @@ -960,29 +966,6 @@ static void agent_read_complete(struct 
> > udscs_connection **connp,
> >
> >  /* main */
> >
> > -static void usage(FILE *fp)
> > -{
> > -fprintf(fp,
> > -"Usage: spice-vdagentd [OPTIONS]\n\n"
> > -"Spice guest agent daemon, version %s.\n\n"
> > -"Options:\n"
> > -"  -h print this text\n"
> > -"  -d log debug messages (use twice for extra 
> > info)\n"
> > -"  -s   set virtio serial port  [%s]\n"
> > -"  -S   set vdagent Unix domain socket [%s]\n"
> > - 

Re: [Spice-devel] [RFC spice-vdagent 02/18] vport: add by_user param to vdagent_virtio_port_disconnect_callback

[Jakub Janku]

Hi,

On Tue, Aug 28, 2018 at 7:52 AM Victor Toso  wrote:
>
> Hi,
>
> Took me a while to get the rationale behind this so some more
> info in the commit log might help.

OK, will do, sorry.
>
> On Tue, Aug 14, 2018 at 08:53:36PM +0200, Jakub Janků wrote:
> > If the virtio port is destroyed explicitly by calling
> > vdagent_virtio_port_destroy(), by_user is set to TRUE,
> > otherwise to FALSE.
>
> One issue I had was around the 'by_user' name and its meaning.
> Basically, if we want to virtio_port_destroy() without any
> runtime failure, by_user would be True.

That's true. Without any runtime failure in virtio-port.c.
>
> I think a GError* err would fit better, as if err != NULL we
> could show err->message and retry if possible. It is also true
> that, under a runtime failure, most of the times before
> virtio_port_destroy() is called there is a syslog(LOG_ERR, ...)
> so I think GError or even a const gchar *err_msg; would be better
> fit but I might be missing something.

I agree, this is a better solution.
>
> > This will be used later with GMainLoop.
>
> Another line about how this is related to GMainLoop might help
> out while reading the patch ;)
> > ---
> >  src/vdagentd/virtio-port.c | 24 +++-
> >  src/vdagentd/virtio-port.h | 10 +-
> >  2 files changed, 20 insertions(+), 14 deletions(-)
> >
> > diff --git a/src/vdagentd/virtio-port.c b/src/vdagentd/virtio-port.c
> > index 3dc6f44..642c848 100644
> > --- a/src/vdagentd/virtio-port.c
> > +++ b/src/vdagentd/virtio-port.c
> > @@ -122,7 +122,8 @@ error:
> >  return NULL;
> >  }
> >
> > -void vdagent_virtio_port_destroy(struct vdagent_virtio_port **vportp)
> > +static void virtio_port_destroy(struct vdagent_virtio_port **vportp,
> > +gboolean by_user)
> >  {
> >  struct vdagent_virtio_port_buf *wbuf, *next_wbuf;
> >  struct vdagent_virtio_port *vport = *vportp;
> > @@ -132,7 +133,7 @@ void vdagent_virtio_port_destroy(struct 
> > vdagent_virtio_port **vportp)
> >  return;
> >
> >  if (vport->disconnect_callback)
> > -vport->disconnect_callback(vport);
> > +vport->disconnect_callback(vport, by_user);
> >
> >  wbuf = vport->write_buf;
> >  while (wbuf) {
> > @@ -151,6 +152,11 @@ void vdagent_virtio_port_destroy(struct 
> > vdagent_virtio_port **vportp)
> >  *vportp = NULL;
> >  }
> >
> > +void vdagent_virtio_port_destroy(struct vdagent_virtio_port **vportp)
> > +{
> > +virtio_port_destroy(vportp, TRUE);
> > +}
> > +
> >  int vdagent_virtio_port_fill_fds(struct vdagent_virtio_port *vport,
> >  fd_set *readfds, fd_set *writefds)
> >  {
> > @@ -321,7 +327,7 @@ static void vdagent_virtio_port_do_chunk(struct 
> > vdagent_virtio_port **vportp)
> >  port->message_data = malloc(port->message_header.size);
> >  if (!port->message_data) {
> >  syslog(LOG_ERR, "out of memory, disconnecting virtio");
> > -vdagent_virtio_port_destroy(vportp);
> > +virtio_port_destroy(vportp, FALSE);
> >  return;
> >  }
> >  }
> > @@ -335,7 +341,7 @@ static void vdagent_virtio_port_do_chunk(struct 
> > vdagent_virtio_port **vportp)
> >
> >  if (avail > read) {
> >  syslog(LOG_ERR, "chunk larger than message, lost sync?");
> > -vdagent_virtio_port_destroy(vportp);
> > +virtio_port_destroy(vportp, FALSE);
> >  return;
> >  }
> >
> > @@ -353,7 +359,7 @@ static void vdagent_virtio_port_do_chunk(struct 
> > vdagent_virtio_port **vportp)
> >  int r = vport->read_callback(vport, 
> > vport->chunk_header.port,
> >   &port->message_header, 
> > port->message_data);
> >  if (r == -1) {
> > -vdagent_virtio_port_destroy(vportp);
> > +virtio_port_destroy(vportp, TRUE);
>
> I wonder if this can't be an actual failure too? (i.e by_user =
> FALSE)

I don't think by_user should be set to FALSE in this case.
There's no error in the virtio-port. The *user* of virtio-port
voluntarily decided to destroy the connection.
Apart from that, the current implementation never returns -1 in the
virtio_port_read_complete(), so it doesn't matter that much, I
guess...
>
> Reviewed-by: Victor Toso 
>
> Cheers,
> Victor
> >  return;
> >  }
> >  }
> > @@ -420,7 +426,7 @@ static void vdagent_virtio_port_do_read(struct 
> > vdagent_virtio_port **vportp)
> >  return;
> >  }
> >  if (n <= 0) {
> > -vdagent_virtio_port_destroy(vportp);
> > +virtio_port_destroy(vportp, FALSE);
> >  return;
> >  }
> >  vport->opening = 0;
> > @@ -433,13 +439,13 @@ static void vdagent_virtio_port_do_read(struct 
> > vdagent_virtio_port **vportp)
> >  if (vport->chunk_header.size > VD_AGENT_MAX_DATA_SIZE) {
> >   

Re: [Spice-devel] [RFC spice-vdagent 03/18] vdagentd: use GMainLoop

[Jakub Janku]

Hi Victor,

On Tue, Aug 28, 2018 at 9:38 AM Victor Toso  wrote:
>
> Hi,
>
> On Tue, Aug 14, 2018 at 08:53:37PM +0200, Jakub Janků wrote:
> > This is purely a preparatory patch as it renders
> > the vdagentd non-functional.
>
> I would rather not break it unless it really helps a lot. It was
> possible to do it for vdagent code at 3fcf2e944ae3bf7, not sure
> why we can't here.

We surely can :) but the situation in vdagent.c was simpler, IMHO.
In vdagent.c, we started using GMainLoop and g_io_add_watch() both in
one commit which was relatively small.

If we wanted to do the same here, we'd have to squash these 3 commits:
* "vdagentd: use GMainLoop"
* "udscs: use VDAgentConnection"
* "vport: use VDAgentConnection"
Apart from that, g_io_add_watch() would need to be used with the
session_info_get_fd().

The resulting patch would be huge, so I opted for this variant.
I don't know what's the best way to go, I'll leave it up to you ;)

Cheers,
Jakub

>
> If it is really the case that it is better to have a commit with
> non functional vdagentd, the commit log must state the rationale
> behind it and which commit it is expected to have it working
> again (the immediate follow-up is better, I guess)
>
> Reviewed-by: Victor Toso 
>
> Victor
>
> > Remove main while loop with FD polling.
> >
> > udscs, virtio-port and session-info will be integrated
> > into the GMainLoop in the following commits.
> >
> > Use g_unix_signal_add() to handle SIGINT, SIGHUP, SIGTERM.
> > SIGQUIT handling is not supported by GLib.
> > ---
> >  src/vdagentd/vdagentd.c | 129 ++--
> >  1 file changed, 44 insertions(+), 85 deletions(-)
> >
> > diff --git a/src/vdagentd/vdagentd.c b/src/vdagentd/vdagentd.c
> > index d88bbc7..8abc63c 100644
> > --- a/src/vdagentd/vdagentd.c
> > +++ b/src/vdagentd/vdagentd.c
> > @@ -31,10 +31,9 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >
> >  #ifdef WITH_SYSTEMD_SOCKET_ACTIVATION
> >  #include 
> > @@ -82,11 +81,12 @@ static const char *active_session = NULL;
> >  static unsigned int session_count = 0;
> >  static struct udscs_connection *active_session_conn = NULL;
> >  static int agent_owns_clipboard[256] = { 0, };
> > -static int quit = 0;
> >  static int retval = 0;
> >  static int client_connected = 0;
> >  static int max_clipboard = -1;
> >
> > +static GMainLoop *loop;
> > +
> >  /* utility functions */
> >  static void virtio_msg_uint32_to_le(uint8_t *_msg, uint32_t size, uint32_t 
> > offset)
> >  {
> > @@ -175,7 +175,7 @@ void do_client_mouse(struct vdagentd_uinput **uinputp, 
> > VDAgentMouseState *mouse)
> >  if (!*uinputp) {
> >  syslog(LOG_CRIT, "Fatal uinput error");
> >  retval = 1;
> > -quit = 1;
> > +g_main_loop_quit(loop);
> >  }
> >  }
> >  }
> > @@ -588,6 +588,33 @@ static int virtio_port_read_complete(
> >  return 0;
> >  }
> >
> > +static void virtio_port_disconnect_cb(struct vdagent_virtio_port *vport,
> > +  gboolean by_user)
> > +{
> > +virtio_port = NULL;
> > +
> > +if (!g_main_loop_is_running(loop))
> > +return;
> > +
> > +if (by_user == FALSE) {
> > +/* virtio_port was destroyed because of an internal error */
> > +gboolean old_client_connected = client_connected;
> > +syslog(LOG_CRIT, "AIIEEE lost spice client connection, 
> > reconnecting");
> > +virtio_port = vdagent_virtio_port_create(portdev,
> > + virtio_port_read_complete,
> > + 
> > virtio_port_disconnect_cb);
> > +if (virtio_port == NULL) {
> > +syslog(LOG_CRIT, "Fatal error opening vdagent virtio channel");
> > +retval = 1;
> > +g_main_loop_quit(loop);
> > +return;
> > +}
> > +do_client_disconnect();
> > +client_connected = old_client_connected;
> > +} else if (only_once)
> > +g_main_loop_quit(loop);
> > +}
> > +
> >  static void virtio_write_clipboard(uint8_t selection, uint32_t msg_type,
> >  uint32_t data_type, uint8_t *data, uint32_t data_size)
> >  {
> > @@ -727,7 +754,7 @@ static void check_xorg_resolution(void)
> >  if (!uinput) {
> >  syslog(LOG_CRIT, "Fatal uinput error");
> >  retval = 1;
> > -quit = 1;
> > +g_main_loop_quit(loop);
> >  return;
> >  }
> >
> > @@ -735,11 +762,11 @@ static void check_xorg_resolution(void)
> >  syslog(LOG_INFO, "opening vdagent virtio channel");
> >  virtio_port = vdagent_virtio_port_create(portdev,
> >   
> > virtio_port_read_complete,
> > - NULL);
> > + 
> > virtio_port_

Re: [Spice-devel] [RFC spice-vdagent 05/18] add VDAgentConnection

[Jakub Janku]

Hey,

On Tue, Aug 28, 2018 at 10:04 AM Victor Toso  wrote:
>
> Hi,
>
> On Tue, Aug 14, 2018 at 08:53:39PM +0200, Jakub Janků wrote:
> > Add a set of helper functions built around GIO that can be used to
> > easily write messages to and read from the given FD.
> >
> > Since VDAgentConnection uses GIO,
> > it integrates well with GMainLoop.
> >
> > Read messages must begin with a header of a fixed size.
> > Message body size can vary.
> >
> > User of VDAgentConnection is notified
> > through callbacks about the following events:
> > - message header read
> > - message body read
> > - I/O error
> >
> > A new VDAgentConnection can be constructed using
> > vdagent_connection_new() based on a GIOStream.
> >
> > A new GIOStream can be obtained using
> > vdagent_file_open() or vdagent_socket_connect().
> >
> > vdagent_connection_destroy() destroyes the connection.
> > However, due to the asynchronous nature of used GIO functions,
> > this does NOT close the underlying FD immediately.
>
> Yep, commented about it on 00/18 but I take that making this a
> GObject might help. Not giving a full review here, just small
> note after looking at the patch and the follow up ones.
>
> > ---
> >  Makefile.am  |   2 +
> >  src/vdagent-connection.c | 301 +++
> >  src/vdagent-connection.h | 103 ++
> >  3 files changed, 406 insertions(+)
> >  create mode 100644 src/vdagent-connection.c
> >  create mode 100644 src/vdagent-connection.h
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index fa54bbc..b291b19 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -7,6 +7,8 @@ sbin_PROGRAMS = src/spice-vdagentd
> >  common_sources = \
> >   src/udscs.c \
> >   src/udscs.h \
> > + src/vdagent-connection.c\
> > + src/vdagent-connection.h\
> >   src/vdagentd-proto-strings.h\
> >   src/vdagentd-proto.h\
> >   $(NULL)
> > diff --git a/src/vdagent-connection.c b/src/vdagent-connection.c
> > new file mode 100644
> > index 000..0eb2ec9
> > --- /dev/null
> > +++ b/src/vdagent-connection.c
> > @@ -0,0 +1,301 @@
> > +/*  vdagent-connection.c
> > +
> > +Copyright 2018 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 3 of the License, or
> > +(at your option) any later version.
> > +
> > +This program is distributed in the hope that it will be useful,
> > +but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +GNU General Public License for more details.
> > +
> > +You should have received a copy of the GNU General Public License
> > +along with this program.  If not, see .
> > +*/
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "vdagent-connection.h"
> > +
> > +struct VDAgentConnection {
> > +GIOStream  *io_stream;
> > +gbooleanopening;
> > +GCancellable   *cancellable;
> > +
> > +GQueue *write_queue;
> > +GMainLoop  *flush_loop;
> > +
> > +VDAgentConnReadCb   read_cb;
> > +gpointerread_buff;
> > +gpointerheader_buff;
> > +gsize   header_size;
> > +VDAgentConnHeaderReadCb header_read_cb;
> > +
> > +VDAgentConnErrorCb  error_cb;
> > +
> > +GCredentials   *credentials;
> > +
> > +gpointeruser_data;
> > +};
> > +
> > +static void request_message_write(VDAgentConnection *conn);
> > +static void request_message_read(VDAgentConnection *conn);
> > +
> > +GIOStream *vdagent_file_open(const gchar *path)
> > +{
> > +gint fd;
> > +
> > +fd = g_open(path, O_RDWR);
> > +if (fd == -1) {
> > +syslog(LOG_ERR, "%s: %m", __func__);
> > +return NULL;
> > +}
> > +
> > +return g_simple_io_stream_new(g_unix_input_stream_new(fd, TRUE),
> > +  g_unix_output_stream_new(fd, TRUE));
> > +}
> > +
> > +GIOStream *vdagent_socket_connect(const gchar *address)
> > +{
> > +GSocketConnection *socket_conn;
> > +GSocketClient *client;
> > +GSocketConnectable *connectable;
> > +GError *err = NULL;
> > +
> > +connectable = G_SOCKET_CONNECTABLE(g_unix_socket_address_new(address));
> > +client = g_object_new(G_TYPE_SOCKET_CLIENT,
> > +  "family", G_SOCKET_FAMILY_UNIX,
> > +  "type", G_SOCKET_TYPE_STREAM,
> > +  NULL);
> > +
> > +socket_conn = g_socket_client_connect(client, connectable, NULL, &err);
> > +  

Re: [Spice-devel] [RFC spice-vdagent 00/18] GLib integration

[Jakub Janku]

On Tue, Aug 28, 2018 at 9:33 AM Victor Toso  wrote:
>
> Hi,
>
> First of all, thanks for your work on this :)
>
> I'm still looking into the glib-integration related patches so I
> might still reply once more afterwards. To keep things easy to
> review, I take we could split this series in three different set
> of patches.
>
> - The cleanup code patches, including using glib's memory
>   function, should be easy to review an apply
>
> - Glib integration patches, might take some interactions as some
>   careful review/testing are needed
>
> - GDBus integration - Shouldn't be hard to review/test but it
>   depends on the Glib one.
>
> Would you mind splitting them?

Not a problem.
>
> On Tue, Aug 14, 2018 at 08:53:34PM +0200, Jakub Janků wrote:
> > Hi all,
> >
> > as the subject suggests, this series further deepens the
> > integration of GLib into spice-vdagent(d).
> >
> > Change summary:
> >
> > * udscs.c and virtio-port.c are built upon common base,
> >   VDAgentConnection, that handles the lower-level I/O operations
> > * systemd-login.c and console-kit.c use GDBus instead of libdbus
> > * vdagentd.c uses GMainLoop and GLib's commandline option parser
> >
> > Some patches are rather unrelated and try to clean up the code
> > a bit.
> >
> > Where I'd need your help:
> >
> > vdagent_connection_destroy() is in most cases asynchronous (due
> > to the way GCancellable works) and it can therefore take
> > multiple iterations of GMainLoop until the memory associated
> > with VDAgentConnection is freed and the underlying file
> > descriptor gets closed.
> >
> > This is fine as long as the GMainLoop runs. However, the
> > current code assumes, that the call to
> > udscs_destroy_connection() and vdagent_virtio_port_destroy()
> > are synchronous and invokes these functions even after the
> > GMainLoop quits.
> >
> > As a result, the memory allocated by VDAgentConnection might
> > not be explicitely freed and the FD might not be closed, when
> > the spice-vdagent(d) exits.
>
> I'm wondering if making VDAgentConnection into a GObject would
> solve the problem? The vdagent_connection_destroy() would be made
> into g_object_unref(vdagent_connection); When the object is being
> cleanup, that's split into Dispose and Finalize cleaning methods.
>
> So, in the end of GMainLoop, the VDAgentConnection should always
> be correctly finished.
>
> Note that this suggestion is also around how the code has been
> wrote. If you have only one reference to VDAgentConnection, you
> have to be careful when you can dealloc its resources but if you
> _ref() before an operation and _unref() after, you can consider
> that the memory will be there in the callback, simple example:
>
> You have:
>
> g_input_stream_read_all_async(in,
>   conn->header_buff,
>   conn->header_size,
>   G_PRIORITY_DEFAULT,
>   conn->cancellable,
>   message_read_cb,
>   conn);
>
> and in message_read_cb()
>
> VDAgentConnection *conn = user_data;
> ...
> g_input_stream_read_all_finish(in, res, &bytes_read, &err);
> if (err)
> return handle_io_error(conn, err);
>
> where handle_io_error() is doing:
>
>  if (g_cancellable_is_cancelled(conn->cancellable)) {
>  if (!connection_has_pending(conn))
>  connection_finalize(conn);
>
>
> So you have a check to Cancel and after that a
> connection_finalize(), to handle the situation of 'have to
> cleanup my memory right'
>
> Instead, you could have a VDAgentConnection object and the
> initial code would change to:
>
>
> g_input_stream_read_all_async(in,
>   ...
>   message_read_cb,
>   g_object_ref(conn));
>
> and in message_read_cb()
>
> VDAgentConnection *conn = user_data;
> ...
> g_input_stream_read_all_finish(in, res, &bytes_read, &err);
> if (err) {
> if (!g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED)) {
> /* print/deal with error message/values */
> }
> /* If needed, this will cleanup everything else, etc. */
> g_object_unref(conn);
> return;
> }
> ...
> g_object_unref(conn);
>
> > Is this an acceptable behavior?
>
> Not one that we shouldn't fix ;)
>
> > Possible solutions:
> > 1) use GMainLoop inside vdagent_connection_destroy() in a
> >similar way as in vdagent_connection_flush() or in the
> >clipboard.c code
> > 2) add a callback for VDAgentConnection's destruction and make
> >the clean-up code at the end of main() run while the GMainLoop
> >is still alive, the callback would then quit it (this would
> >also require adding destruction callbacks for udscs_connection,
> >udscs_server and virtio_port)
> >
> > Is there any better solution?
>
> Overall I think we should 

Re: [Spice-devel] [RFC spice-vdagent 00/18] GLib integration

[Jakub Janku]

Hi,

On Tue, Sep 4, 2018 at 7:33 AM Victor Toso  wrote:
>
> Hi,
>
> On Mon, Sep 03, 2018 at 09:03:38PM +0200, Jakub Janku wrote:
> > I do agree that turning VDAgentConnection into a GObject is
> > probably a good idea, however, I do not see how it could help
> > us in this situation. Am I missing something?  I'll try to
> > explain the problem again:
> >
> > Let's consider that vdagentd receives a signal.
> > signal_handler() in vdagentd.c is called which quits the main
> > loop.  The current loop iteration is finished and the program
> > returns to main().  In main(), vdagent_virtio_port_destroy() is
> > called, which internally invokes vdagent_connection_destroy().
>
> That is:
>
>  | static gboolean signal_handler(gpointer user_data)
>  | {
>  | g_main_loop_quit(loop);
>  | return G_SOURCE_REMOVE;
>  | }
>
> But note that g_main_loop_quit() docs says that:
>
>  | Note that sources that have already been dispatched when
>  | g_main_loop_quit() is called will still be executed.
>
> So, isn't this a matter of having cancelled everything correctly
> at the right time?

Well, it kinda is. I think that the call to g_main_loop_quit() should
be made once the connection_finalize() in vdagent-connection.c is
called.
The question is what's the best way to accomplish this.
>
> > If the virtio port was connected at the moment we received the
> > signal, there was also a running GTask which was previously
> > started with g_input_stream_read_all_async() (because we try to
> > read from the port the whole time).
> > This GTask holds a reference to the GIOStream, this means that
> > the stream won't be closed until the GTask finishes.
> > However, the GTask cannot be canceled synchronously (see docs
> > for g_cancellable_cancel()) and the GMainLoop is NOT running at
> > the moment.
>
> It is fine that it isn't sync. What happens is that, it gets
> cancelled (because g_main_loop_quit()) and on GIOStream's
> callback, you would get the GError::G_IO_ERROR_CANCELLED, that
> callback would return and that GSource finished.
>
> When the last GSource is finished is when g_main_loop_run()
> returns and main() is executed again.
>
> > As a result, the reference to GIOStream is not released and the
> > FD is not closed.
> >
> > So the problem aren't the references to VDAgentConnection
> > itself, but rather the GLib's internal references to the
> > GIOStream we use in VDAgentConnection.
>
> If we follow glib's API we either should be fine or find a bug in
> glib

It's not that simple I'm afraid.
Have a look at 
https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html
and the diagram (
https://developer.gnome.org/glib/stable/mainloop-states.gif )
When signal_handler() is called, the main loop is in the "dispatching"
phase. We can call vdagent_virtio_port_destroy() in the signal
handler, but the problem is that if we call g_main_loop_quit(), the
main loop won't iterate again. And we need that extra iterations
because GCancellable uses file descriptor and hence the main loop
needs to go through that "polling" phase so that we get the
GError::G_IO_ERROR_CANCELLED error.

So in other words, if the loop is quit too early, the GIOStream's
callback won't be called and connection won't be finalized.

Cheers,
Jakub

>
> > I hope this makes it a bit more clear.
>
> Let me know if I get it wrong again ;)
>
> Cheers,
> Victor
>
> > Thanks for the reviews :)
> > Jakub
> >
> > > >
> > > > Jakub Janků (18):
> > > >   vdagentd: parse argv using GLib
> > > >   vport: add by_user param to vdagent_virtio_port_disconnect_callback
> > > >   vdagentd: use GMainLoop
> > > >   build: add GIO dependency
> > > >   add VDAgentConnection
> > > >   udscs: add udscs_get_peer_pid()
> > > >   udscs: use VDAgentConnection
> > > >   udscs-server: split initialization
> > > >   udscs: simplify logging
> > > >   vport: use VDAgentConnection
> > > >   session-info: add ActiveSessionChangeCb
> > > >   console-kit: use GDBus
> > > >   systemd-login: use GDBus
> > > >   session-info: remove session_info_get_fd()
> > > >   build: drop DBus dependency
> > > >   move to GLib memory functions
> > > >   vdagentd: move code to do_guest_xorg_resolution()
> > > >   vdagentd: move code to do_agent_file_xfer_status()
> > > >
> > > >  Makefile.am   |   6 +-
> > > >  confi

Re: [Spice-devel] [RFC spice-vdagent 01/18] vdagentd: parse argv using GLib

[Jakub Janku]

On Tue, Sep 4, 2018 at 7:02 AM Victor Toso  wrote:
>
> Hi,
>
> On Mon, Sep 03, 2018 at 06:06:01PM +0200, Jakub Janku wrote:
> > Hi,
> >
> > > I think that after "vdagentd: use GMainLoop" patch, we should
> > > also include glib's command line options.
> >
> > Not sure what you are referring to here.
> > GLib uses environment variables instead of command line
> > options, AFAIK, doesn't it?
> > There's the gtk_get_option_group() that we use in vdagent.c,
> > but I don't know of anything similar for GLib.
>
> Yep, there isn't :)
> I probably got confused with gtk/glib at the time.
>
> > > On Tue, Aug 14, 2018 at 08:53:35PM +0200, Jakub Janků wrote:
> > > > All command line options now have long names
> > > > as they are required by GLib.
> > >
> > > I think that adding the following to the commit log as a quick
> > > overview of current options and its long names might be helpful.
> >
> > Sure.
> > >
> > > -d, --debug
> > > -s, --virtio-serial-port-path
> > > -S, --vdagentd-socket
> > > -u, --uinput-device
> > > -f, --fake-uinput
> > > -x, --foreground
> > > -o, --one-session
> > > -X, --disable-session-integration
> > >
> > > > Change types of some global variables that hold the options:
> > > > - const char * --> gchar *
> > > > - int  --> gboolean
> > > >
> > > > Define DEFAULT_UINPUT_DEVICE as "/dev/uinput",
> > > > since there's already DEFAULT_VIRTIO_PORT_PATH, VDAGENTD_SOCKET.
> > >
> > > Would you mind adding Signed-off-by: Name  ?
> > >
> > > (more below)
> > >
> > > > ---
> > > >  src/vdagentd/vdagentd.c | 149 ++--
> > > >  1 file changed, 82 insertions(+), 67 deletions(-)
> > > >
> > > > diff --git a/src/vdagentd/vdagentd.c b/src/vdagentd/vdagentd.c
> > > > index 682761a..d88bbc7 100644
> > > > --- a/src/vdagentd/vdagentd.c
> > > > +++ b/src/vdagentd/vdagentd.c
> > > > @@ -48,6 +48,8 @@
> > > >  #include "virtio-port.h"
> > > >  #include "session-info.h"
> > > >
> > > > +#define DEFAULT_UINPUT_DEVICE "/dev/uinput"
> > > > +
> > > >  struct agent_data {
> > > >  char *session;
> > > >  int width;
> > > > @@ -58,12 +60,16 @@ struct agent_data {
> > > >
> > > >  /* variables */
> > > >  static const char *pidfilename = 
> > > > "/var/run/spice-vdagentd/spice-vdagentd.pid";
> > > > -static const char *portdev = DEFAULT_VIRTIO_PORT_PATH;
> > > > -static const char *vdagentd_socket = VDAGENTD_SOCKET;
> > > > -static const char *uinput_device = "/dev/uinput";
> > > > +
> > > > +static gchar *portdev = NULL;
> > > > +static gchar *vdagentd_socket = NULL;
> > > > +static gchar *uinput_device = NULL;
> > > >  static int debug = 0;
> > > > -static int uinput_fake = 0;
> > > > -static int only_once = 0;
> > > > +static gboolean uinput_fake = FALSE;
> > > > +static gboolean only_once = FALSE;
> > > > +static gboolean do_daemonize = TRUE;
> > > > +static gboolean want_session_info = TRUE;
> > > > +
> > > >  static struct udscs_server *server = NULL;
> > > >  static struct vdagent_virtio_port *virtio_port = NULL;
> > > >  static GHashTable *active_xfers = NULL;
> > > > @@ -960,29 +966,6 @@ static void agent_read_complete(struct 
> > > > udscs_connection **connp,
> > > >
> > > >  /* main */
> > > >
> > > > -static void usage(FILE *fp)
> > > > -{
> > > > -fprintf(fp,
> > > > -"Usage: spice-vdagentd [OPTIONS]\n\n"
> > > > -"Spice guest agent daemon, version %s.\n\n"
> > > > -"Options:\n"
> > > > -"  -h print this text\n"
> > > > -"  -d log debug messages (use twice for extra 
> > > > info)\n"
> > > > -"  -s   set virtio serial port  [%s]\n"
> > > > -"  -S   set vdagent Unix domain socket [%s]\n"
> > > > -  

Re: [Spice-devel] spice can't transfer files from gust OS to client

[Jakub Janku]

Hi,

You can use a shared folder for this purpose,
consult the Spice User Manual for more details:

https://www.spice-space.org/spice-user-manual.html

Drag& dropping files from guest to client is currently not supported.

Regards,
Jakub


On Nov 21, 2018 7:53 AM, "wangjiedong"  wrote:

I installed spice-vdagent in guest OS Ubuntu 1804 , then i connect guest
with virt-viewer .
I can drag files to guest Ubuntu from client , but i can't drag files out
from guest Ubuntu.
Then i try it with guest OS windows installed windows-spice-tools , it
can't transfer files from guest to client too !
Do we only transfer file from client to guest or any configuration i ignore?
Thanks for help !

___
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 vdagent-linux 3/4] introduce VDAgentConnection

[Jakub Janku]

Hi, Victor!

Many thanks for reviewing this series.

On Thu, Dec 6, 2018 at 4:20 PM Victor Toso  wrote:
>
> Hi,
>
> First of all, tested. Seems to work fine!

Great!
>
> This one I think it can be improved to have a clear design around
> VDAgentConnection. The other three patches could be merged faster
> I think, if you want.

They can be merged all at the same time, I don't mind.
>
> On Sun, Sep 30, 2018 at 08:05:22PM +0200, Jakub Janků wrote:
> > 1) VDAgentConnection
> >
> > Add vdagent-connection.{c,h} files.
> >
> > Define a new GObject: VDAgentConnection which can be used to
> > easily write messages to and read from the given FD.
>
> What is the plan to virtio-port and udscs files/functions? They
> all seen similar. I really like the idea that we use one
> interface for both vdagent <-> vdagentd and vdagentd <-> client
> and it would be nice to move towards that direction.

That would be very nice indeed.
However, there are some specifics for each type of communication, mainly:
* incoming virtio-port messages can be split into multiuple chunks
* write functions (udscs_write, vdagent_virtio_port_write) differ
* udscs.c also contains udscs_server code

The virtio-port is used solely by vdagentd.c, so some code could be moved there.
The udscs_server code could be moved to vdagentd.c as well, or
possibly to vdagent-connection.c
The udscs_write() function might be harder to replace, any idea?

There's definitely quite a lot of overhead in the current solution
(where udscs and virtio-port are esentially wrappers for
vdagent-connection), but I'm afraid that the solution I tried to
propose above might make especially the vdagentd.c file unnecessarily
cluttered.
>
> I'm not sure myself exactly which API would be enough. I think
> that is not difficult to remove more code with the current
> version so I think is a good thing.
>
> At some point I looked at vdagent-gtk from elmarco and something
> along that could be used as inspiration,
>
> 
> https://github.com/elmarco/vdagent-gtk/commit/ed83e0e12118c1d46cda85c8902a3a4ce0157d76

Elmarco's commits replaced the udscs only in vdagent and did not touch
the virtio-port at all.
Not sure how much this could be helpful, tbh.
>
> > VDAgentConnection uses GIO and therefore integrates well with GMainLoop.
> >
> > Read messages must begin with a header of a fixed size.
> > Message body size can vary.
> >
> > User of VDAgentConnection is notified
> > through callbacks about the following events:
> >  * message header read
> >  * whole message read
> >  * I/O error
>
> I think it is easier to extend using signals and attach a handler
> to them instead of increasing callback to APIs like
> vdagent_connection_new(). My suggestion don't necessary fit with
> previous design.

What do you mean by "don't fit" here?
>
> > A new VDAgentConnection can be constructed using
> > vdagent_connection_new() based on a GIOStream that can be
> > obtained using vdagent_file_open() or vdagent_socket_connect().
> >
> > vdagent_connection_destroy() destroyes the connection.
> > However, due to the asynchronous nature of used GIO functions,
> > this does NOT close the underlying FD immediately.
>
> It should by the time GMainLoop exits, AFAIK.

It does not. That's why there has to be the g_main_context_iteration() call.
>
> > If vdagent_connection_destroy() is called outside of GMainLoop
> > (or the loop quits right after the function ivocation),
> > g_main_context_iteration() should be called to ensure that the
> > VDAgentConnection finalizes properly.
>
> I'm missing why this is necessary. Is it related to the
> discussion from September?
>
> 
> https://lists.freedesktop.org/archives/spice-devel/2018-September/045516.html

Exactly. On IRC, we came up with a solution that used g_idle_add(), at
least if I remember correctly, but later I found out that
g_main_context_iteration() works as well and is simpler.
>
> What kind of issue are you seeing without calling
> g_main_context_iteration() ?

Remove the g_main_context_iteration() from vdagent.c
Run vdagentd and vdagent from terminal.
Kill the vdagent.

Result: vdagent_connection_finalize() is not called,
so the VDAgentConnection object that is used in udscs_connection is
not properly finalized.
>
> > 2) udscs
> >
> > Rewrite udscs.c to use the new VDAgentConnection.
> > Use GSocketService in udscs_server.
> >
> > Drop support for select(), remove:
> >  * udscs_server_fill_fds()
> >  * udscs_server_handle_fds()
> >
> > 3) virtio_port
> >
> > Rewrite virtio-port.c to use the new VDAgentConnection.
> >
> > Drop support for select(), remove:
> >  * vdagent_virtio_port_fill_fds()
> >  * vdagent_virtio_port_handle_fds()
> >
> > 2) vdagentd
>
> 4) :)
>
Ups
> >
> > Replace the main_loop() with a GMainLoop.
>
> o/
>
> > Use g_unix_signal_add() to handle SIGINT, SIGHUP, SIGTERM.
> > SIGQUIT handling is not supported by GLib.
>
> That's fine
>
> > Integrate the session_info into the loop using
> > GIOChannel and g_io_add_watch().
> >
> > Signed-off-b

Re: [Spice-devel] [spice-gtk v2 2/7] channel-main: clipboard request: wakeup only when needed

[Jakub Janku]

Hi,

On Mon, Dec 10, 2018 at 12:03 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> This patch makes agent_clipboard_request() to return true only when
> the message request to the agent is successfully queued to be sent.
>
> By checking the return value, we can avoid wakeup the channel
> unnecessarily at spice_main_channel_clipboard_selection_request()
>
> Signed-off-by: Victor Toso 
> ---
>  src/channel-main.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/src/channel-main.c b/src/channel-main.c
> index 4c6bc70..fb7175e 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -1419,23 +1419,24 @@ static void agent_clipboard_notify(SpiceMainChannel 
> *self, guint selection,
>  }
>
>  /* any context: the message is not flushed immediately,
> -   you can wakeup() the channel coroutine or send_msg_queue() */
> -static void agent_clipboard_request(SpiceMainChannel *channel, guint 
> selection, guint32 type)
> +   you can wakeup() the channel coroutine or send_msg_queue()
> +   Returns true if message was queued */
> +static bool agent_clipboard_request(SpiceMainChannel *channel, guint 
> selection, guint32 type)

Might be better to use gboolean and TRUE/FALSE (instead of bool with
true/false) to match the rest of the file?
Apart from that, it looks good to me.

Cheers,
Jakub

>  {
>  SpiceMainChannelPrivate *c = channel->priv;
>  VDAgentClipboardRequest *request;
>  guint8 *msg;
>  size_t msgsize;
>
> -g_return_if_fail(c->agent_connected);
> -g_return_if_fail(test_agent_cap(channel, 
> VD_AGENT_CAP_CLIPBOARD_BY_DEMAND));
> +g_return_val_if_fail(c->agent_connected, false);
> +g_return_val_if_fail(test_agent_cap(channel, 
> VD_AGENT_CAP_CLIPBOARD_BY_DEMAND), false);
>
>  msgsize = sizeof(VDAgentClipboardRequest);
>  if (test_agent_cap(channel, VD_AGENT_CAP_CLIPBOARD_SELECTION)) {
>  msgsize += 4;
>  } else if (selection != VD_AGENT_CLIPBOARD_SELECTION_CLIPBOARD) {
>  SPICE_DEBUG("Ignoring clipboard request");
> -return;
> +return false;
>  }
>
>  msg = g_alloca(msgsize);
> @@ -1451,6 +1452,7 @@ static void agent_clipboard_request(SpiceMainChannel 
> *channel, guint selection,
>  request->type = type;
>
>  agent_msg_queue(channel, VD_AGENT_CLIPBOARD_REQUEST, msgsize, msg);
> +return true;
>  }
>
>  /* any context: the message is not flushed immediately,
> @@ -2936,8 +2938,9 @@ void 
> spice_main_channel_clipboard_selection_request(SpiceMainChannel *channel, g
>  g_return_if_fail(channel != NULL);
>  g_return_if_fail(SPICE_IS_MAIN_CHANNEL(channel));
>
> -agent_clipboard_request(channel, selection, type);
> -spice_channel_wakeup(SPICE_CHANNEL(channel), FALSE);
> +if (agent_clipboard_request(channel, selection, type)) {
> +spice_channel_wakeup(SPICE_CHANNEL(channel), FALSE);
> +}
>  }
>
>  /**
> --
> 2.19.2
>
> ___
> 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] gtk-session: do not request guest's clipboard data unnecessarily

[Jakub Janku]

Hi,

On Wed, Dec 19, 2018 at 3:30 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> If SpiceGtkSession is holding the keyboard, that's huge indication
> that we should not be requesting clipboard data yet. The proper time
> to request it is when another application in the client machine is
> asking for it, which means the user would switch to another
> application to paste the guest's clipboard data.
>
I'm having a rather hard time understanding this commit message.
I read it the following way:
"spice-gtk should not request clipboard data from vdagent, while
spice-gtk holds the keyboard focus"
However, what the patch actually does is that it makes sure that
spice-gtk doesn't send clipboard grab to vdagent, while spice-gtk
holds the keyboard focus.

These 2 things seem rather unrelated. What am I missing?

> This is default behavior over wayland.

I can confirm that on Wayland, this patch breaks copy&paste from
client to guest.
According to the Wayland docs, the windows should receive the
owner-change event before the focus-in event (
https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-data-sharing
have a look at Data devices.Selection: "This event is also generated
on a client immediately before it receives keyboard focus.").
But as it turns out, gtk+ delays the event so that the focus-in event
comes first ( 
https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/gdk/wayland/gdkdevice-wayland.c
check out the keyboard_handle_enter() ).
So this patch will unfortunately need some changes in order to work on Wayland.
>
> Related: https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
> Related: https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876

Could you please elaborate a bit more on why this patch solves these issues?

Cheers,
Jakub
>
> Signed-off-by: Victor Toso 
> Tested-by: James Harvey @jamespharvey20
> ---
>  src/spice-gtk-session.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 1ccae07..0d3438c 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -645,9 +645,11 @@ static void clipboard_owner_change(GtkClipboard
> *clipboard,
>  if (gtk_clipboard_get_owner(clipboard) == G_OBJECT(self))
>  break;
>
> +
>  s->clipboard_by_guest[selection] = FALSE;
>  s->clip_hasdata[selection] = TRUE;
> -if (s->auto_clipboard_enable && !read_only(self))
> +if (s->auto_clipboard_enable && !read_only(self) &&
> +!spice_gtk_session_get_keyboard_has_focus(self))
>  gtk_clipboard_request_targets(clipboard, clipboard_get_targets,
>get_weak_ref(self));
>  break;
> --
> 2.19.2
>
> ___
> 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] gtk-session: do not request guest's clipboard data unnecessarily

[Jakub Janku]

Hi,


On Wed, Jan 2, 2019, 5:31 PM Victor Toso  Hi,
>
> Thanks for taking a look!
>
> On Sun, Dec 30, 2018 at 10:23:02PM +0100, Jakub Janku wrote:
> > Hi,
> >
> > On Wed, Dec 19, 2018 at 3:30 PM Victor Toso 
> wrote:
> > >
> > > From: Victor Toso 
> > >
> > > If SpiceGtkSession is holding the keyboard, that's huge indication
> > > that we should not be requesting clipboard data yet. The proper time
> > > to request it is when another application in the client machine is
> > > asking for it, which means the user would switch to another
> > > application to paste the guest's clipboard data.
> > >
>
> > I'm having a rather hard time understanding this commit message.
> > I read it the following way:
> > "spice-gtk should not request clipboard data from vdagent, while
> > spice-gtk holds the keyboard focus"
> > However, what the patch actually does is that it makes sure that
> > spice-gtk doesn't send clipboard grab to vdagent, while spice-gtk
> > holds the keyboard focus.
> >
> > These 2 things seem rather unrelated. What am I missing?
>
> Client request for grab will make agent to look into clipboard
> data in the guest which would lead to VD_AGENT_CLIPBOARD_REQUEST
> being sent from agent to client.
>

Exactly! So it's the agent requesting the CLIENT's data. But in the commit
message, you state "do not request GUEST's clipboard data unnecessarily".
Or isn't it?

>
> I tried to avoid the grab first; I can also delay the clipboard
> data request to a later time (like when the keyboard is out of
> focus, as I suggested in the patch and explained below)
>
> > > This is default behavior over wayland.
> >
> > I can confirm that on Wayland, this patch breaks copy&paste
> > from client to guest.
> > According to the Wayland docs, the windows should receive the
> > owner-change event before the focus-in event (
> >
> https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-data-sharing
> > have a look at Data devices.Selection: "This event is also generated
> > on a client immediately before it receives keyboard focus.").
> > But as it turns out, gtk+ delays the event so that the focus-in event
> > comes first (
> https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/gdk/wayland/gdkdevice-wayland.c
> > check out the keyboard_handle_enter() ).
> > So this patch will unfortunately need some changes in order to
> > work on Wayland.
>
> Yep!
>
> > > Related: https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
> > > Related: https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
> > > Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
> >
> > Could you please elaborate a bit more on why this patch solves these
> issues?
>
> I can reproduce the client requesting guest's clipboard data on
> X11/KDE multiple times while the user is just copy-paste between
> applications in the guest. The idea of this patch was to avoid
> those requests till the keyboard focus is lost, which means that
> user is trying to paste guest's clipboard data into another
> application in the client's OS.
>
> Let me know if it isn't clear!
>

Makes sense to me to try to avoid such requests. But why are those requests
causing the issues described?

>
> > Cheers,
> > Jakub
>
> Thanks again,
> Victor
>
>
> > >
> > > Signed-off-by: Victor Toso 
> > > Tested-by: James Harvey @jamespharvey20
> > > ---
> > >  src/spice-gtk-session.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > index 1ccae07..0d3438c 100644
> > > --- a/src/spice-gtk-session.c
> > > +++ b/src/spice-gtk-session.c
> > > @@ -645,9 +645,11 @@ static void clipboard_owner_change(GtkClipboard
>   *clipboard,
> > >  if (gtk_clipboard_get_owner(clipboard) == G_OBJECT(self))
> > >  break;
> > >
> > > +
> > >  s->clipboard_by_guest[selection] = FALSE;
> > >  s->clip_hasdata[selection] = TRUE;
> > > -if (s->auto_clipboard_enable && !read_only(self))
> > > +if (s->auto_clipboard_enable && !read_only(self) &&
> > > +!spice_gtk_session_get_keyboard_has_focus(self))
> > >  gtk_clipboard_request_targets(clipboard,
> clipboard_get_targets,
> > >get_weak_ref(self));
> > >  break;
> > > --
> > > 2.19.2
> > >
> > > ___
> > > 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 v2] gtk-session: do not request guest's clipboard data unnecessarily

[Jakub Janku]

Hi,

On Mon, Jan 7, 2019 at 1:41 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> If SpiceGtkSession is holding the keyboard, that's huge indication
> that the client should not be requesting guest's clipboard data yet.
>
> This patch adds a check in clipboard_get() callback, to avoid such
> requests. In Linux, this only happens with X11 backend.
>
> This patch helps to handle a possible state race between who owns the
> grab between client and agent which could lead to agent clipboard
> failing or getting stuck, see:
>
> Linux guest:
> https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
>
> Windows guest:
> https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
>
> The way to reproduce the race might depend on guest system and
> applications but it is connected to amount of VDAGENTD_CLIPBOARD_GRAB
> sent by the agent which depends on the amount of clipboard changes in
> the guest. Simple example is on RHEL 6.10, with Gedit, select a text
> char by char; Client receives VDAGENTD_CLIPBOARD_GRAB every time a new
> char is selected instead of once when the full message is selected.
>
> v1 -> v2:
> * Moved the check to the right place, otherwise the patch would not
>   work on Wayland (Christophe, Jakub)
> * Improve commit log (Jakub)

Now I get it, thanks :)
>
> Related: https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
> Related: https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-gtk-session.c | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 1ccae07..a78f619 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -59,6 +59,7 @@ struct _SpiceGtkSessionPrivate {
>  gbooleanclip_hasdata[CLIPBOARD_LAST];
>  gbooleanclip_grabbed[CLIPBOARD_LAST];
>  gbooleanclipboard_by_guest[CLIPBOARD_LAST];
> +gbooleanclipboard_by_guest_released[CLIPBOARD_LAST];
>  /* auto-usbredir related */
>  gbooleanauto_usbredir_enable;
>  int auto_usbredir_reqs;
> @@ -634,6 +635,12 @@ static void clipboard_owner_change(GtkClipboard
> *clipboard,
>  if (s->main == NULL)
>  return;
>
> +if (s->clipboard_by_guest_released[selection]) {
> +/* Ignore owner-change event if this is just about agent releasing 
> grab */
> +s->clipboard_by_guest_released[selection] = FALSE;
> +return;
> +}
> +
>  if (s->clip_grabbed[selection]) {
>  s->clip_grabbed[selection] = FALSE;
>  if (spice_main_channel_agent_test_capability(s->main, 
> VD_AGENT_CAP_CLIPBOARD_BY_DEMAND))
> @@ -728,6 +735,14 @@ static void clipboard_get(GtkClipboard *clipboard,
>  g_return_if_fail(info < SPICE_N_ELEMENTS(atom2agent));
>  g_return_if_fail(s->main != NULL);
>
> +/* No real need to set clipboard data while no client application will
> + * be requested. This is useful for clients on X11 as in Wayland, this
> + * callback is only called when SpiceGtkSession:keyboard-focus is false 
> */
> +if (spice_gtk_session_get_keyboard_has_focus(self)) {
> +SPICE_DEBUG("Do not request clipboard data while holding the 
> keyboard focus");
> +return;
> +}

Have you tested this with some clipboard managers? I would expect them
to request the clipboard data as soon as they receive a new
owner-change event. So this patch may potentially cripple them, but I
might be wrong. Not sure whether this is a use-case we need to support
but it might be good to know the consequences of this patch.
> +
>  ri.selection_data = selection_data;
>  ri.info = info;
>  ri.loop = g_main_loop_new(NULL, FALSE);
> @@ -769,6 +784,15 @@ cleanup:
>
>  static void clipboard_clear(GtkClipboard *clipboard, gpointer user_data)
>  {
> +SpiceGtkSession *self = user_data;
> +SpiceGtkSessionPrivate *s = self->priv;
> +gint selection = get_selection_from_clipboard(s, clipboard);
> +
> +g_return_if_fail(selection != -1);
> +
> +if (s->clipboard_by_guest_released[selection])
> +return;
> +
This gave me a pause for a while. It seems rather weird to me that
only part of the clipboard code logs debug messages (e.g.
clipboard_get_targets() prints all the atoms but there's no logging in
clipboard_grab()). By bypassing the SPICE_DEBUG below, we would lose
track of the guest's clipboard release event as there's no log in
clipboard_release() either.

Maybe it would be useful to add some logging to the other functions as
well? (clipboard_{grab, request, release})

>  SPICE_DEBUG("clipboard_clear");
>  /* We watch for clipboard ownership changes and act on those, so we
> don't need to do anything here */
> @@ -1035,6 +1059,8 @@ static void clipboard_release(SpiceMainChannel *main, 

Re: [Spice-devel] [spice-gtk v2] gtk-session: do not request guest's clipboard data unnecessarily

[Jakub Janku]

On Tue, Jan 8, 2019 at 10:06 AM Victor Toso  wrote:
>
> Hi,
>
> Thanks for review!
>
> On Mon, Jan 07, 2019 at 09:28:04PM +0100, Jakub Janku wrote:
> > Hi,
> >
> > On Mon, Jan 7, 2019 at 1:41 PM Victor Toso  wrote:
> > >
> > > From: Victor Toso 
> > >
> > > If SpiceGtkSession is holding the keyboard, that's huge indication
> > > that the client should not be requesting guest's clipboard data yet.
> > >
> > > This patch adds a check in clipboard_get() callback, to avoid such
> > > requests. In Linux, this only happens with X11 backend.
> > >
> > > This patch helps to handle a possible state race between who owns the
> > > grab between client and agent which could lead to agent clipboard
> > > failing or getting stuck, see:
> > >
> > > Linux guest:
> > > https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
> > >
> > > Windows guest:
> > > https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
> > >
> > > The way to reproduce the race might depend on guest system and
> > > applications but it is connected to amount of VDAGENTD_CLIPBOARD_GRAB
> > > sent by the agent which depends on the amount of clipboard changes in
> > > the guest. Simple example is on RHEL 6.10, with Gedit, select a text
> > > char by char; Client receives VDAGENTD_CLIPBOARD_GRAB every time a new
> > > char is selected instead of once when the full message is selected.
> > >
> > > v1 -> v2:
> > > * Moved the check to the right place, otherwise the patch would not
> > >   work on Wayland (Christophe, Jakub)
> > > * Improve commit log (Jakub)
> >
> > Now I get it, thanks :)
> > >
> > > Related: https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
> > > Related: https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
> > > Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
> > >
> > > Signed-off-by: Victor Toso 
> > > ---
> > >  src/spice-gtk-session.c | 26 ++
> > >  1 file changed, 26 insertions(+)
> > >
> > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > index 1ccae07..a78f619 100644
> > > --- a/src/spice-gtk-session.c
> > > +++ b/src/spice-gtk-session.c
> > > @@ -59,6 +59,7 @@ struct _SpiceGtkSessionPrivate {
> > >  gbooleanclip_hasdata[CLIPBOARD_LAST];
> > >  gbooleanclip_grabbed[CLIPBOARD_LAST];
> > >  gbooleanclipboard_by_guest[CLIPBOARD_LAST];
> > > +gbooleanclipboard_by_guest_released[CLIPBOARD_LAST];
> > >  /* auto-usbredir related */
> > >  gbooleanauto_usbredir_enable;
> > >  int auto_usbredir_reqs;
> > > @@ -634,6 +635,12 @@ static void clipboard_owner_change(GtkClipboard  
> > >   *clipboard,
> > >  if (s->main == NULL)
> > >  return;
> > >
> > > +if (s->clipboard_by_guest_released[selection]) {
> > > +/* Ignore owner-change event if this is just about agent 
> > > releasing grab */
> > > +s->clipboard_by_guest_released[selection] = FALSE;
> > > +return;
> > > +}
> > > +
> > >  if (s->clip_grabbed[selection]) {
> > >  s->clip_grabbed[selection] = FALSE;
> > >  if (spice_main_channel_agent_test_capability(s->main, 
> > > VD_AGENT_CAP_CLIPBOARD_BY_DEMAND))
> > > @@ -728,6 +735,14 @@ static void clipboard_get(GtkClipboard *clipboard,
> > >  g_return_if_fail(info < SPICE_N_ELEMENTS(atom2agent));
> > >  g_return_if_fail(s->main != NULL);
> > >
> > > +/* No real need to set clipboard data while no client application 
> > > will
> > > + * be requested. This is useful for clients on X11 as in Wayland, 
> > > this
> > > + * callback is only called when SpiceGtkSession:keyboard-focus is 
> > > false */
> > > +if (spice_gtk_session_get_keyboard_has_focus(self)) {
> > > +SPICE_DEBUG("Do not request clipboard data while holding the 
> > > keyboard focus");
> > > +return;
> > > +}
> >
> > Have you tested this with some clipboard managers? I would
> > expect them to request the clipboard data as soon as they
> > receive a new owner-change event.
>
> I ha

Re: [Spice-devel] [PATCH spice-gtk] gtk: don't request clipboard targets when there is no owner

[Jakub Janku]

Hi,

On Fri, Jan 11, 2019 at 11:40 AM  wrote:
>
> From: Marc-André Lureau 
>
> After a clipboard-clear, the owner-changed signal is triggered, with
> no owner. Let's avoid requesting for targets, that would lead to a
> failure.
>
> Fixes:
> (lt-spicy:23226): GSpice-DEBUG: 13:36:38.741: spice-gtk-session.c:797 
> clipboard_clear
> (lt-spicy:23226): GSpice-DEBUG: 13:36:38.742: spice-gtk-session.c:547 
> clipboard_get_targets:
> (lt-spicy:23226): GSpice-DEBUG: 13:36:38.742: spice-gtk-session.c:555 
> Retrieving the clipboard data has failed
>
> Signed-off-by: Marc-André Lureau 
> ---
>  src/spice-gtk-session.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index adc72a2..9d7702c 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -670,7 +670,8 @@ static void clipboard_owner_change(GtkClipboard
> *clipboard,
>
>  /* This situation happens when clipboard is being cleared by us, when 
> agent
>   * sends a release-grab for instance */
> -if (gtk_clipboard_get_owner(clipboard) == G_OBJECT(self)) {
> +GObject *owner = gtk_clipboard_get_owner(clipboard);
> +if (owner == NULL || owner == G_OBJECT(self)) {
>  return;
>  }

I'm afraid this commit will have to be reverted as it completely
disables copy&paste from client to guest:

According to the GTK+ docs, gtk_clipboard_get_owner() corresponds to
the owner object set by gtk_clipboard_set_with_owner().
So if another application in the client's system grabs the clipboard,
spice-gtk receives "owner-change" event, gtk_clipboard_get_owner()
returns NULL and the callback returns without sending a grab to the
vdagent.

Cheers,
Jakub
>
> --
> 2.20.1.98.gecbdaf0899
>
> ___
> 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 v3 1/3] gtk-session: clipboard: document owner-changed event

[Jakub Janku]

Hi,

I see that I'm being late to the party as this has already been pushed
upstream, but I'd like to comment anyway:

On Thu, Jan 10, 2019 at 1:47 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> This patch improves the code style by adding braces, removing the
> single case switch and add documentation to the handler of
> GtkClipboard::owner-changed.
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-gtk-session.c | 54 +
>  1 file changed, 39 insertions(+), 15 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 1ccae07..adc72a2 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -618,6 +618,23 @@ static void clipboard_get_targets(GtkClipboard 
> *clipboard,
>  s->nclip_targets[selection] = 0;
>  }
>
> +/* Callback for every owner-change event for given @clipboard.
> + * This event is triggered in different ways depending on the environment of
> + * the Client, some examples:
> + *
> + * Situation 1: When another application on the client machine is holding and
> + * changing the clipboard. If client is on Wayland, spice-gtk only receives 
> the
> + * related GtkClipboard::owner-changed event after focus-in event on Spice
> + * widget; On X11, we will receive it at the moment the clipboard data has 
> been
> + * changed in by other application.
> + *
> + * Situation 2: When spice-gtk holds the focus and is changing the clipboard 
> by
> + * either setting new content information with 
> gtk_clipboard_set_with_owner() or
> + * clearing up old content with gtk_clipboard_clear(). The main difference 
> between
> + * Wayland and X11 is that on X11, gtk_clipboard_clear() set the owner to 
> none, which

"set" -> "sets" ?

> + * emits owner-change event; On Wayland that does not happen as spice-gtk 
> still is
> + * the owner of the clipboard.

You must have come across this bug, since you commented on it:
https://gitlab.gnome.org/GNOME/gtk/issues/715

I've created a simple test case which is attached.
It seems like no "owner-change" event is emitted after
gtk_clipboard_clear() is called,
but after gtk_clipboard_set_with_owner() the event is emitted twice.

So the Wayland behavior you described here might just be caused by the bug...
> + */
>  static void clipboard_owner_change(GtkClipboard*clipboard,
> GdkEventOwnerChange *event,
> gpointeruser_data)
> @@ -631,30 +648,37 @@ static void clipboard_owner_change(GtkClipboard
> *clipboard,
>  selection = get_selection_from_clipboard(s, clipboard);
>  g_return_if_fail(selection != -1);
>
> -if (s->main == NULL)
> +if (s->main == NULL) {
>  return;
> +}
>
> +/* In case we sent a grab to the agent, we need to release it now as
> + * previous clipboard data should not be reachable anymore */
>  if (s->clip_grabbed[selection]) {
>  s->clip_grabbed[selection] = FALSE;
> -if (spice_main_channel_agent_test_capability(s->main, 
> VD_AGENT_CAP_CLIPBOARD_BY_DEMAND))
> +if (spice_main_channel_agent_test_capability(s->main, 
> VD_AGENT_CAP_CLIPBOARD_BY_DEMAND)) {
>  spice_main_channel_clipboard_selection_release(s->main, 
> selection);
> +}
>  }
>
> -switch (event->reason) {
> -case GDK_OWNER_CHANGE_NEW_OWNER:
> -if (gtk_clipboard_get_owner(clipboard) == G_OBJECT(self))
> -break;
> -
> -s->clipboard_by_guest[selection] = FALSE;
> -s->clip_hasdata[selection] = TRUE;
> -if (s->auto_clipboard_enable && !read_only(self))
> -gtk_clipboard_request_targets(clipboard, clipboard_get_targets,
> -  get_weak_ref(self));
> -break;
> -default:
> +/* We are mostly interested when owner has changed in which case
> + * we would like to let agent know about new clipboard data. */
> +if (event->reason != GDK_OWNER_CHANGE_NEW_OWNER) {
>  s->clip_hasdata[selection] = FALSE;
> -break;
> +return;
>  }
> +
> +/* This situation happens when clipboard is being cleared by us, when 
> agent
> + * sends a release-grab for instance */

This is not true imho. It should only happen after a grab (after
gtk_clipboard_set_with_owner() is called).
After a release (gtk_clipboard_clear() call),
gtk_clipboard_get_owner(clipboard) should already return NULL.

> +if (gtk_clipboard_get_owner(clipboard) == G_OBJECT(self)) {
> +return;
> +}
> +
> +s->clipboard_by_guest[selection] = FALSE;
> +s->clip_hasdata[selection] = TRUE;
> +if (s->auto_clipboard_enable && !read_only(self))
> +gtk_clipboard_request_targets(clipboard, clipboard_get_targets,
> +  get_weak_ref(self));
>  }
>
>  typedef struct
> --
> 2.20.1
>

Cheers,
Jakub
#include 

GtkClipboard *clipboard;

static void clipboard_owner_change_cb(GtkC

Re: [Spice-devel] [spice-gtk v4 1/2] gtk-session: improve doc on owner-changed

[Jakub Janku]

Hi,

On Mon, Jan 14, 2019 at 1:34 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> * Sets -> Set (Jakub)
> * Clarify when onwer-changed event is called with
>   owner == self (Jakub)
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-gtk-session.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index adc72a2..abce43f 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -631,7 +631,7 @@ static void clipboard_get_targets(GtkClipboard *clipboard,
>   * Situation 2: When spice-gtk holds the focus and is changing the clipboard 
> by
>   * either setting new content information with 
> gtk_clipboard_set_with_owner() or
>   * clearing up old content with gtk_clipboard_clear(). The main difference 
> between
> - * Wayland and X11 is that on X11, gtk_clipboard_clear() set the owner to 
> none, which
> + * Wayland and X11 is that on X11, gtk_clipboard_clear() sets the owner to 
> none, which
>   * emits owner-change event; On Wayland that does not happen as spice-gtk 
> still is
>   * the owner of the clipboard.
>   */
> @@ -668,8 +668,8 @@ static void clipboard_owner_change(GtkClipboard
> *clipboard,
>  return;
>  }
>
> -/* This situation happens when clipboard is being cleared by us, when 
> agent
> - * sends a release-grab for instance */
> +/* This situation happens when clipboard is being set by us (grab 
> message)

this is fine

> + * and on X11 also when cleared by us (release-grab) */

But I don't understand why you added this.
If spice-gtk receives release-grab from vdagent, it calls
gtk_clipboard_clear(), then "owner-change" is emitted. In the
callback, gtk_clipboard_get_owner() returns NULL, so the condition
below evaluates as FALSE -- which is the case you're trying to handle
in 2/2 of this series, if I'm not mistaken.

So I think this line should be removed.

>  if (gtk_clipboard_get_owner(clipboard) == G_OBJECT(self)) {
>  return;
>  }
> --
> 2.20.1
>
Cheers,
Jakub
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v4 2/2] gtk-session: clipboard: x11: owner-change improvement

[Jakub Janku]

Hi,

On Mon, Jan 14, 2019 at 1:41 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Mon, Jan 14, 2019 at 4:34 PM Victor Toso  wrote:
> >
> > From: Victor Toso 
> >
> > On X11, the release-grab message might end up clearing the
> > GtkClipboard which triggers the owner-changed callback having the
> > event owner as NULL.
> >
> > We should not be calling gtk_clipboard_request_targets() in this
> > situation as is prone to errors as the intention here is request
> > clipboard information from changes made by client OS.
> >
> > The fix is to avoid any such request while spice client is holding the
> > keyboard grab.
>
> Two things that bug me about this:
> - it's x11 specific, weird

What's so weird about that?
It's also X11-specific that we can receive these "owner-change" events
while spice-gtk is holding the focus since on Wayland, apps need to
gain focus first to be able to set the clipboard, afaik.
The clipboard protocols on X11 and Wayland have simply been designed
in different ways. So although GTK tries to unify the behavior and
provide the same experience in both environments, some limitations
just cannot be overcome.

> - the condition seems wrong: if an application has the keyboard grab,
> that doesn't mean that another cannot update the clipboard. For
> example, I suppose this can easily happen with multiple
> pointers/inputs or some automation.

Sure, another app can update the clipboard, but imagine the following situation:
1) user copies something in the guest
2) an app in the client's system grabs the clipboard without having
keyboard focus -- this means that the grab likely wasn't directly
initiated by the user
3) spice-gtk receives "owner-change" event and subsequently sends grab
to the agent
4) based on the grab message from spice-gtk in step 3), vdagent grabs
the clipboard in the guest system -- and by that, it overwrites the
clipboard contents copied in step 1)

So the clipboard is suddenly changed, although the user didn't take any action.
I think this is unwanted and this patch solves it, so I'm all for
ack-ing this just for this reason. If this also solves the bug, it's
even better.

Nevertheless, I would be really happy if we could track down what
exactly causes the issues that have been reported and describe it in
more detail.
>
> Other than that, if it fixes or workaround real clipboard issues, I am
> not against it, but I think we should add more comments about the
> "hack".
>
>
> >
> > Related: https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
> > Related: https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
> > Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
> >
> > Changed in v4:
> > - Updated commit log
> >
> > Signed-off-by: Victor Toso 
> > Tested-by: James Harvey @jamespharvey20

Does this mean it fixes the issues for him?
> > ---
> >  src/spice-gtk-session.c | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > index abce43f..20df70d 100644
> > --- a/src/spice-gtk-session.c
> > +++ b/src/spice-gtk-session.c
> > @@ -674,6 +674,19 @@ static void clipboard_owner_change(GtkClipboard
> > *clipboard,
> >  return;
> >  }
> >
> > +#ifdef GDK_WINDOWING_X11
> > +/* In X11, while holding the keyboard-grab we are not interested in 
> > this
> > + * event as it either came by grab or release messages from agent.  */

For completeness, it might be good to mention that the event can be
caused by other applications too (as Marc-André pointed out), even
though spice-gtk is holding the keyboard-grab.

> > +if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
> > +spice_gtk_session_get_keyboard_has_focus(self)) {
> > +SPICE_DEBUG("clipboard: owner-changed event: not requesting 
> > client's target "
> > +"while holding focus");
> > +return;
> > +}
> > +#endif
> > +SPICE_DEBUG("clipboard: owner-changed event: has-focus=%d",
> > +spice_gtk_session_get_keyboard_has_focus(self));
> > +
> >  s->clipboard_by_guest[selection] = FALSE;
> >  s->clip_hasdata[selection] = TRUE;
> >  if (s->auto_clipboard_enable && !read_only(self))
> > --
> > 2.20.1
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
Cheers,
Jakub
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v3 1/3] gtk-session: clipboard: document owner-changed event

[Jakub Janku]

Hi,

On Mon, Jan 14, 2019 at 10:34 AM Victor Toso  wrote:
>
> Hi,
>
> On Sun, Jan 13, 2019 at 09:59:11PM +0100, Jakub Janku wrote:
> > Hi,
> >
> > I see that I'm being late to the party as this has already been
> > pushed upstream, but I'd like to comment anyway:
> >
> > On Thu, Jan 10, 2019 at 1:47 PM Victor Toso  wrote:
> > >
> > > From: Victor Toso 
> > >
> > > This patch improves the code style by adding braces, removing the
> > > single case switch and add documentation to the handler of
> > > GtkClipboard::owner-changed.
> > >
> > > Signed-off-by: Victor Toso 
> > > ---
> > >  src/spice-gtk-session.c | 54 +
> > >  1 file changed, 39 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > index 1ccae07..adc72a2 100644
> > > --- a/src/spice-gtk-session.c
> > > +++ b/src/spice-gtk-session.c
> > > @@ -618,6 +618,23 @@ static void clipboard_get_targets(GtkClipboard 
> > > *clipboard,
> > >  s->nclip_targets[selection] = 0;
> > >  }
> > >
> > > +/* Callback for every owner-change event for given @clipboard.
> > > + * This event is triggered in different ways depending on the 
> > > environment of
> > > + * the Client, some examples:
> > > + *
> > > + * Situation 1: When another application on the client machine is 
> > > holding and
> > > + * changing the clipboard. If client is on Wayland, spice-gtk only 
> > > receives the
> > > + * related GtkClipboard::owner-changed event after focus-in event on 
> > > Spice
> > > + * widget; On X11, we will receive it at the moment the clipboard data 
> > > has been
> > > + * changed in by other application.
> > > + *
> > > + * Situation 2: When spice-gtk holds the focus and is changing the 
> > > clipboard by
> > > + * either setting new content information with 
> > > gtk_clipboard_set_with_owner() or
> > > + * clearing up old content with gtk_clipboard_clear(). The main 
> > > difference between
> > > + * Wayland and X11 is that on X11, gtk_clipboard_clear() set the owner 
> > > to none, which
> >
> > "set" -> "sets" ?
>
> I think you are right :)
>
> > > + * emits owner-change event; On Wayland that does not happen as 
> > > spice-gtk still is
> > > + * the owner of the clipboard.
> >
> > You must have come across this bug, since you commented on it:
> > https://gitlab.gnome.org/GNOME/gtk/issues/715
> >
> > I've created a simple test case which is attached.
> > It seems like no "owner-change" event is emitted after
> > gtk_clipboard_clear() is called,
> > but after gtk_clipboard_set_with_owner() the event is emitted twice.
> >
> > So the Wayland behavior you described here might just be caused by the 
> > bug...
>
> Could be.
>
> But just to be clear, what I tried to document was _when_ the
> callback is called. I just tried the test case under X11 and
> Wayland and the same thing happens as expected: On X11, the
> callback is called when the clipboard has changed by another
> application; On Wayland, the callback is called if the clipboard
> has changed and when we have the focus.

That's of course true.
Just though it might be worth mentioning.
>
> > > + */
> > >  static void clipboard_owner_change(GtkClipboard*clipboard,
> > > GdkEventOwnerChange *event,
> > > gpointeruser_data)
> > > @@ -631,30 +648,37 @@ static void clipboard_owner_change(GtkClipboard 
> > >*clipboard,
> > >  selection = get_selection_from_clipboard(s, clipboard);
> > >  g_return_if_fail(selection != -1);
> > >
> > > -if (s->main == NULL)
> > > +if (s->main == NULL) {
> > >  return;
> > > +}
> > >
> > > +/* In case we sent a grab to the agent, we need to release it now as
> > > + * previous clipboard data should not be reachable anymore */
> > >  if (s->clip_grabbed[selection]) {
> > >  s->clip_grabbed[selection] = FALSE;
> > > -if (spice_main_channel_agent_test_capability(s->main, 
> > > VD_AGENT_CAP_CLIPBOARD_BY_DEMAND))
> > > +if (spice_main_channel_agent_test_capability(s->main, 
> > >

Re: [Spice-devel] [spice-gtk v5] gtk-session: improve doc on owner-changed

[Jakub Janku]

Hi,

On Tue, Jan 15, 2019 at 11:22 AM Victor Toso  wrote:
>
> From: Victor Toso 
>
> * Set -> Sets (Jakub)
> * Clarify when onwer-changed event is called with
>   owner == self (Jakub)
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-gtk-session.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index adc72a2..32f857d 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -631,7 +631,7 @@ static void clipboard_get_targets(GtkClipboard *clipboard,
>   * Situation 2: When spice-gtk holds the focus and is changing the clipboard 
> by
>   * either setting new content information with 
> gtk_clipboard_set_with_owner() or
>   * clearing up old content with gtk_clipboard_clear(). The main difference 
> between
> - * Wayland and X11 is that on X11, gtk_clipboard_clear() set the owner to 
> none, which
> + * Wayland and X11 is that on X11, gtk_clipboard_clear() sets the owner to 
> none, which
>   * emits owner-change event; On Wayland that does not happen as spice-gtk 
> still is
>   * the owner of the clipboard.
>   */
> @@ -668,8 +668,7 @@ static void clipboard_owner_change(GtkClipboard
> *clipboard,
>  return;
>  }
>
> -/* This situation happens when clipboard is being cleared by us, when 
> agent
> - * sends a release-grab for instance */
> +/* This situation happens when clipboard is being set by us (grab 
> message) */
>  if (gtk_clipboard_get_owner(clipboard) == G_OBJECT(self)) {
>  return;
>  }
> --
> 2.20.1
>

Now it looks good :)

Acked-by: Jakub Janků 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v2] gtk-session: clipboard request: notify agent on failure

[Jakub Janku]

Hi,

On Wed, Jan 16, 2019 at 10:11 AM Victor Toso  wrote:
>
> From: Victor Toso 
>
> Similar to 172c521271a3d - if we don't, the agent might be waiting for
> data till some timeout happens in the system, blocking copy-paste
> feature and possibly freezing applications.
>
> A way to reproduce is copy-paste big clipboard data between two spice
> clients.
>
> Also add some documentation to the checks, in order to quickly
> understand what they are about.
>
> Related: https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
> Related: https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
>
> v1 -> v2:
> - Fixed comment on s->clipboard_by_guest[selection] check (Marc-André)
> - Removed the reply on read only. (Marc-André)
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-gtk-session.c | 29 +
>  1 file changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 1a19bca..82a5b35 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -1015,12 +1015,29 @@ static gboolean clipboard_request(SpiceMainChannel 
> *main, guint selection,
>  int m;
>
>  cb = get_clipboard_from_selection(s, selection);
> -g_return_val_if_fail(cb != NULL, FALSE);
> -g_return_val_if_fail(s->clipboard_by_guest[selection] == FALSE, FALSE);
> -g_return_val_if_fail(s->clip_grabbed[selection], FALSE);
> +if (cb == NULL) {
> +goto notify_agent;
> +}

cb == NULL means that the requested selection can't have been
advertised by spice-gtk, so the vdagent shouldn't request the
selection's data.
This seems like a clear bug in vdagent to me. Should we respond? I'm
afraid it might potentially result into some bugs staying unnoticed in
the vdagent.

> +
> +/* As we are holding clipboard data sent by selection-grab from guest, 
> the
> + * selection-request of clipboard data from guest must fail. We either 
> sent
> + * a bad selection-grab to the guest or the agent is buggy. */
> +if (s->clipboard_by_guest[selection]) {
> +SPICE_DEBUG("clipboard: agent request: grab on hold by agent, 
> possible race");
> +goto notify_agent;
> +}

Yes, this can happen, this is the bug we're trying to fix. But this
change doesn't really fix it, it just mitigates it.
As you're saying in the comment, it's a bug either in the client or in
the agent. I'd rather fix the bug than try to alleviate its
"symptoms".

>
> -if (read_only(self))
> +/* The selection-request by agent should happen only if the clipboard 
> data is set
> + * by client */
> +if (!s->clip_grabbed[selection]) {
> +SPICE_DEBUG("clipboard: agent request: data set by agent, possible 
> race");
> +goto notify_agent;
> +}

This can surely happen and it wouldn't be a programmer error, so the
g_return_val_if_fail() should indeed be replaced by a less severe log.

But again, I have some doubts whether we should respond. The new
clipboard code in linux vdagent clears all pending requests upon
release message. So sending the data message would actually produce a
warning on the guest side as the corresponding request wouldn't be
found. I'm not sure how the Windows agent handles this.

> +
> +/* On read only, should not reply to the agent. */
> +if (read_only(self)) {
>  return FALSE;
> +}
>
>  if (type == VD_AGENT_CLIPBOARD_UTF8_TEXT) {
>  gtk_clipboard_request_text(cb, clipboard_received_text_cb,
> @@ -1039,6 +1056,10 @@ static gboolean clipboard_request(SpiceMainChannel 
> *main, guint selection,
>  }
>
>  return TRUE;
> +
> +notify_agent:
> +spice_main_channel_clipboard_selection_notify(s->main, selection, type, 
> NULL, 0);
> +return FALSE;
>  }
>
>  static void clipboard_release(SpiceMainChannel *main, guint selection,
> --
> 2.20.1
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel

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

Re: [Spice-devel] [spice-gtk v4 2/2] gtk-session: clipboard: x11: owner-change improvement

[Jakub Janku]

Hi,

I tried to fix this bug in a less radical way, but my patch unfortunately
did not cover all the cases.

I obtained some logs from James Harvey which make the situation clearer -
it can be found here:
https://termbin.com/40un
So I'll try to explain what's happening:

James uses KDE which has a clipboard manager integrated in (klipper).

(1) user copies something in the guest, grab is sent to the spice-gtk
(2) clipboard manager immediately requests the data, data is retrieved from
the vdagent
(3) user pastes the copied data in guest, this causes a quick re-grab in
the guest = a clipboard release message is sent to spice-gtk and it is
immediately followed by a new grab
(4) spice-gtk receives clipboard release, so it clears the clipboard
(5) clipboard manager detects that the clipboard has no owner, so it grabs
it itself, advertising the data it originally obtained from us in step (2)
(this normally enables the user to paste the data even after the source app
has been closed)
(6) spice-gtk receives "owner-change" signal caused by the grab in step
(5), requests clipboard targets and sends a grab to vdagent
(7) spice-gtk finally receives the grab from step (3), so it sets the
clipboard using gtk_clipboard_set_with_owner()
(8) vdagent receives grab from step (6), so it too sets the clipboard using
gtk_clipboard_set_with_owner()

This is clearly a race. We ended up in a state where both spice-gtk and
vdagent thinks the other component can provide the data, but in reality
none of them can.

(This does not happen always, as can be seen in the log, the first paste
succeeds.)

Given current spice protocol, I don't see a way to detect the race on
either side, but I'd love to be wrong. So I'd update the commit log and
comment in the code to explain the situation and then it's ack from me.

Cheers,
Jakub

On Mon, Jan 14, 2019, 1:34 PM Victor Toso  From: Victor Toso 
>
> On X11, the release-grab message might end up clearing the
> GtkClipboard which triggers the owner-changed callback having the
> event owner as NULL.
>
> We should not be calling gtk_clipboard_request_targets() in this
> situation as is prone to errors as the intention here is request
> clipboard information from changes made by client OS.
>
> The fix is to avoid any such request while spice client is holding the
> keyboard grab.
>
> Related: https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
> Related: https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
>
> Changed in v4:
> - Updated commit log
>
> Signed-off-by: Victor Toso 
> Tested-by: James Harvey @jamespharvey20
> ---
>  src/spice-gtk-session.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index abce43f..20df70d 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -674,6 +674,19 @@ static void clipboard_owner_change(GtkClipboard
>   *clipboard,
>  return;
>  }
>
> +#ifdef GDK_WINDOWING_X11
> +/* In X11, while holding the keyboard-grab we are not interested in
> this
> + * event as it either came by grab or release messages from agent.  */
> +if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
> +spice_gtk_session_get_keyboard_has_focus(self)) {
> +SPICE_DEBUG("clipboard: owner-changed event: not requesting
> client's target "
> +"while holding focus");
> +return;
> +}
> +#endif
> +SPICE_DEBUG("clipboard: owner-changed event: has-focus=%d",
> +spice_gtk_session_get_keyboard_has_focus(self));
> +
>  s->clipboard_by_guest[selection] = FALSE;
>  s->clip_hasdata[selection] = TRUE;
>  if (s->auto_clipboard_enable && !read_only(self))
> --
> 2.20.1
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v1 1/2] gtk-session: clipboard: rename functions

[Jakub Janku]

Hi,

On Mon, Jan 28, 2019 at 1:23 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> * Attaching the 'guest_' prefix for actions that were started from
>   guest agent, those renames are:
>
> clipboard_grab -> guest_clipboard_grab
> clipboard_release -> guest_clipboard_release
> clipboard_request -> guest_clipboard_request_data
> clipboard_request_send_data -> guest_clipboard_request_send_data
>
> * Attaching the 'client_' prefix for actions that were triggered by
>   client and sent/received by guest agent, those renames are:
>
> clipboard_get -> client_clipboard_request_data
> clipboard_got_from_guest -> client_clipboard_received_data
>
> * Changed from 'clipboard_' to 'clipboard_handler' prefix for
>   callbacks related to GtkClipboard, those renames are:
>
> clipboard_clear -> clipboard_handler_clear
> clipboard_owner_change -> clipboard_handler_owner_change_cb
> clipboard_received_text_cb -> clipboard_handler_received_text_cb
> clipboard_get_targets -> clipboard_handler_get_targets_cb

These 4 seem a bit weird.
I would either change them all to "clipboard_*_handler", or "clipboard_*_cb".
I wouldn't use "handler" together with "cb".
They could also bear the "client_" prefix as they're all concerning
clipboard on the client side.
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-gtk-session.c | 123 
>  1 file changed, 75 insertions(+), 48 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 1a19bca..ac2ba0b 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -95,9 +95,9 @@ struct _SpiceGtkSessionPrivate {
>
>  /* -- */
>  /* Prototypes for private functions */
> -static void clipboard_owner_change(GtkClipboard *clipboard,
> -   GdkEventOwnerChange *event,
> -   gpointer user_data);
> +static void clipboard_handler_owner_change_cb(GtkClipboard *clipboard,
> +  GdkEventOwnerChange *event,
> +  gpointer user_data);
>  static void channel_new(SpiceSession *session, SpiceChannel *channel,
>  gpointer user_data);
>  static void channel_destroy(SpiceSession *session, SpiceChannel *channel,
> @@ -182,10 +182,10 @@ static void spice_gtk_session_init(SpiceGtkSession 
> *self)
>
>  s->clipboard = gtk_clipboard_get(GDK_SELECTION_CLIPBOARD);
>  g_signal_connect(G_OBJECT(s->clipboard), "owner-change",
> - G_CALLBACK(clipboard_owner_change), self);
> + G_CALLBACK(clipboard_handler_owner_change_cb), self);
>  s->clipboard_primary = gtk_clipboard_get(GDK_SELECTION_PRIMARY);
>  g_signal_connect(G_OBJECT(s->clipboard_primary), "owner-change",
> - G_CALLBACK(clipboard_owner_change), self);
> + G_CALLBACK(clipboard_handler_owner_change_cb), self);
>  spice_g_signal_connect_object(keymap, "state-changed",
>G_CALLBACK(keymap_modifiers_changed), 
> self, 0);
>  }
> @@ -222,13 +222,13 @@ static void spice_gtk_session_dispose(GObject *gobject)
>  /* release stuff */
>  if (s->clipboard) {
>  g_signal_handlers_disconnect_by_func(s->clipboard,
> -G_CALLBACK(clipboard_owner_change), self);
> +G_CALLBACK(clipboard_handler_owner_change_cb), self);
>  s->clipboard = NULL;
>  }
>
>  if (s->clipboard_primary) {
>  g_signal_handlers_disconnect_by_func(s->clipboard_primary,
> -G_CALLBACK(clipboard_owner_change), self);
> +G_CALLBACK(clipboard_handler_owner_change_cb), self);
>  s->clipboard_primary = NULL;
>  }
>
> @@ -537,10 +537,10 @@ static gpointer free_weak_ref(gpointer data)
>  return object;
>  }
>
> -static void clipboard_get_targets(GtkClipboard *clipboard,
> -  GdkAtom *atoms,
> -  gint n_atoms,
> -  gpointer user_data)
> +static void clipboard_handler_get_targets_cb(GtkClipboard *clipboard,
> + GdkAtom *atoms,
> + gint n_atoms,
> + gpointer user_data)
>  {
>  SpiceGtkSession *self = free_weak_ref(user_data);
>
> @@ -635,9 +635,10 @@ static void clipboard_get_targets(GtkClipboard 
> *clipboard,
>   * emits owner-change event; On Wayland that does not happen as spice-gtk 
> still is
>   * the owner of the clipboard.
>   */
> -static void clipboard_owner_change(GtkClipboard*clipboard,
> -   GdkEventOwnerChange *event,
> -   gpointeruser_data)
> +static void
> +clipboard_handler_owner_change_cb(GtkClipboard *clipboard,
> +

Re: [Spice-devel] [spice-gtk v1 2/2] gtk-session: clipboard: add some more debugs

[Jakub Janku]

Hi,

On Mon, Jan 28, 2019 at 1:23 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> To help track race conditions and bad/unexpected behavior in general.

Awesome! I was planning on sending something similar too.
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-gtk-session.c | 24 
>  1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index ac2ba0b..bdb1d9d 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -544,7 +544,7 @@ static void clipboard_handler_get_targets_cb(GtkClipboard 
> *clipboard,
>  {
>  SpiceGtkSession *self = free_weak_ref(user_data);
>
> -SPICE_DEBUG("%s:", __FUNCTION__);
> +SPICE_DEBUG("%s natoms=%d from %p", __func__, n_atoms, clipboard);

Printing the address clipboard points to is rather useless imho. The
corresponding selection id is what we're interested in.
>
>  if (self == NULL)
>  return;
> @@ -704,9 +704,10 @@ client_clipboard_received_data(SpiceMainChannel *main,
>  SpiceGtkSessionPrivate *s = ri->self->priv;
>  gchar *conv = NULL;
>
> -g_return_if_fail(selection == ri->selection);
> +SPICE_DEBUG("%s %u bytes (%p) for sel=%u type=%u",
> +__func__, size, data, selection, type);
>
> -SPICE_DEBUG("clipboard got data");
> +g_return_if_fail(selection == ri->selection);
>
>  if (atom2agent[ri->info].vdagent == VD_AGENT_CLIPBOARD_UTF8_TEXT) {
>  /* on windows, gtk+ would already convert to LF endings, but
> @@ -751,12 +752,11 @@ client_clipboard_request_data(GtkClipboard *clipboard,
>  gboolean agent_connected = FALSE;
>  gulong clipboard_handler;
>  gulong agent_handler;
> -int selection;
>
> -SPICE_DEBUG("clipboard get");
> -
> -selection = get_selection_from_clipboard(s, clipboard);
> +int selection = get_selection_from_clipboard(s, clipboard);
>  g_return_if_fail(selection != -1);
> +SPICE_DEBUG("%s for sel=%d (%p)", __func__, selection, clipboard);

Maybe also print the type that is being requested (info,
atom2agent[info].vdagent) ?
> +
>  g_return_if_fail(info < SPICE_N_ELEMENTS(atom2agent));
>  g_return_if_fail(s->main != NULL);
>
> @@ -801,7 +801,7 @@ cleanup:
>  static void
>  clipboard_handler_clear(GtkClipboard *clipboard, gpointer user_data)
>  {
> -SPICE_DEBUG("clipboard_clear");
> +SPICE_DEBUG("%s on %p", __func__, clipboard);

Same as above: print selection instead of pointer's address

>  /* We watch for clipboard ownership changes and act on those, so we
> don't need to do anything here */
>  }
> @@ -846,6 +846,9 @@ guest_clipboard_grab(SpiceMainChannel *main,
>  }
>  }
>
> +SPICE_DEBUG("%s selection=%u (%p), might request %d/%u types",
> +__func__, selection, cb, num_targets, ntypes);

When we send a grab to vdagent, we print each target (atom's name).
Maybe we could do that here as well?
> +
>  g_free(s->clip_targets[selection]);
>  s->nclip_targets[selection] = num_targets;
>  s->clip_targets[selection] = g_memdup(targets, sizeof(GtkTargetEntry) * 
> num_targets);
> @@ -1014,6 +1017,7 @@ guest_clipboard_request_send_data(GtkClipboard 
> *clipboard,
>   */
>  g_warn_if_fail(type != VD_AGENT_CLIPBOARD_UTF8_TEXT);
>
> +SPICE_DEBUG("%s %d bytes for selection=%d (%p) type=%u", __func__, len, 
> selection, clipboard, type);

Split into two lines?

>  spice_main_channel_clipboard_selection_notify(s->main, selection, type, 
> data, len);
>  }
>
> @@ -1034,6 +1038,8 @@ guest_clipboard_request_data(SpiceMainChannel *main,
>
>  cb = get_clipboard_from_selection(s, selection);
>  g_return_val_if_fail(cb != NULL, FALSE);
> +SPICE_DEBUG("%s selection=%u (%p) type=%u", __func__, selection, cb, 
> type);
> +
>  g_return_val_if_fail(s->clipboard_by_guest[selection] == FALSE, FALSE);
>  g_return_val_if_fail(s->clip_grabbed[selection], FALSE);
>
> @@ -1072,6 +1078,8 @@ guest_clipboard_release(SpiceMainChannel *main,
>  SpiceGtkSessionPrivate *s = self->priv;
>  GtkClipboard* clipboard = get_clipboard_from_selection(s, selection);
>
> +SPICE_DEBUG("%s selection=%u (%p)", __func__, selection, clipboard);
> +
>  if (!clipboard)
>  return;
>
> --
> 2.20.1
>

In some logs, you use "sel=" while in others "selection=".

I think owner-change deserves a log too.
Logs in clipboard_handler_received_text_cb() could contain the
concerned selection.

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

Re: [Spice-devel] [vdagent-linux v2 2/2] vdagent: Favour access() over stat()

[Jakub Janku]

Hi,

On Wed, Jan 30, 2019 at 1:23 PM Christophe Fergeau  wrote:
>
> vdagent.c has a 'file_test' function which tests for the existence of
> the /dev entry for the spicevmc channel. This commit reworks it to give
> it a better name, to make it return a boolean, and to use access()
> rather than stat() which makes the goal of that function more obvious.
>
> Signed-off-by: Christophe Fergeau 
> ---
>  src/vdagent/vdagent.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/src/vdagent/vdagent.c b/src/vdagent/vdagent.c
> index ff3328c..b077d1d 100644
> --- a/src/vdagent/vdagent.c
> +++ b/src/vdagent/vdagent.c
> @@ -20,6 +20,7 @@
>  */
>  #include 
>
> +#include 

Why this include here? Can't we just use gboolean instead of bool,
like in the rest of the file?

Apart from that, looks good to me.

Cheers,
Jakub

>  #include 
>  #include 
>  #include 
> @@ -28,8 +29,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -319,11 +318,9 @@ static int daemonize(void)
>  return 0;
>  }
>
> -static int file_test(const char *path)
> +static bool file_exists(const char *path)
>  {
> -struct stat buffer;
> -
> -return stat(path, &buffer);
> +return (access(path, F_OK) == 0);
>  }
>
>  static gboolean x11_io_channel_cb(GIOChannel *source,
> @@ -450,7 +447,7 @@ int main(int argc, char *argv[])
>  openlog("spice-vdagent", do_daemonize ? LOG_PID : (LOG_PID | LOG_PERROR),
>  LOG_USER);
>
> -if (file_test(portdev) != 0) {
> +if (!file_exists(portdev)) {
>  g_debug("vdagent virtio channel %s does not exist, exiting", 
> portdev);
>  return 0;
>  }
> --
> 2.20.1
>
> ___
> 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-linux v2 1/2] vdagent: Silently ignore missing spicevmc device

[Jakub Janku]

On Wed, Jan 30, 2019 at 1:23 PM Christophe Fergeau  wrote:
>
> On most distros, spice-vdagent will be autostarted as part of the
> startup of the desktop environment session. This is done by
> spice-vdagent.desktop, which has no way of checking if we are in a virt
> environment with the needed devices present.
>
> Currently, if /dev/virtio-ports/com.redhat.spice.0 is missing, we log an
> error in syslog, and exit with an error exit code. This is too noisy
> when autostarting it on a bare metal machine which have no use for
> spice-vdagent. This reverts 0159111b to get rid of these warnings in the
> session's logs
>
> https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/12
>
> Signed-off-by: Christophe Fergeau 
> ---
> Changes since v1:
> - switched to g_debug as g_print would show in journalctl

Why is this wanted? What if the vdagent is running in a virtualized
system and the device is missing? In that case, I would expect to see
at least some info in the system journal.
So why not just lowering the log level to something like LOG_INFO?

Cheers,
Jakub

> - reworded the message
>
>  src/vdagent/vdagent.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/vdagent/vdagent.c b/src/vdagent/vdagent.c
> index 90247f9..ff3328c 100644
> --- a/src/vdagent/vdagent.c
> +++ b/src/vdagent/vdagent.c
> @@ -451,8 +451,8 @@ int main(int argc, char *argv[])
>  LOG_USER);
>
>  if (file_test(portdev) != 0) {
> -syslog(LOG_ERR, "Cannot access vdagent virtio channel %s", portdev);
> -return 1;
> +g_debug("vdagent virtio channel %s does not exist, exiting", 
> portdev);
> +return 0;
>  }
>
>  if (do_daemonize)
> --
> 2.20.1
>
> ___
> 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-linux v2 1/2] vdagent: Silently ignore missing spicevmc device

[Jakub Janku]

On Wed, Jan 30, 2019 at 6:06 PM Christophe Fergeau  wrote:
>
> On Wed, Jan 30, 2019 at 01:46:21PM +0100, Jakub Janku wrote:
> > On Wed, Jan 30, 2019 at 1:23 PM Christophe Fergeau  
> > wrote:
> > >
> > > On most distros, spice-vdagent will be autostarted as part of the
> > > startup of the desktop environment session. This is done by
> > > spice-vdagent.desktop, which has no way of checking if we are in a virt
> > > environment with the needed devices present.
> > >
> > > Currently, if /dev/virtio-ports/com.redhat.spice.0 is missing, we log an
> > > error in syslog, and exit with an error exit code. This is too noisy
> > > when autostarting it on a bare metal machine which have no use for
> > > spice-vdagent. This reverts 0159111b to get rid of these warnings in the
> > > session's logs
> > >
> > > https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/12
> > >
> > > Signed-off-by: Christophe Fergeau 
> > > ---
> > > Changes since v1:
> > > - switched to g_debug as g_print would show in journalctl
> >
> > Why is this wanted? What if the vdagent is running in a virtualized
> > system and the device is missing? In that case, I would expect to see
> > at least some info in the system journal.
> > So why not just lowering the log level to something like LOG_INFO?
>

Thanks for the summary!

> I don't know what the expectations are with respect to the amount of
> logging in the bare metal case. To be honest, we should not even be
> trying to load spice-vdagent in that situation. So logging anything is
> just going to be noise.
>
> Rather than silencing the warning, I tried to find other solutions, but
> I could not think of anything. We could say we don't want to try to run
> spice-vdagent if spice-vdagentd is not running, however these days
> spice-vdagentd is socket activated, and it's spice-vdagent which
> triggers the actual start of spice-vdagentd.
>
> Then I tried to make use of systemd user session support to start
> spice-vdagent rather than relying on /etc/xdg/autostart, however there
> were 2 issues that I'm not sure are going to be easy to solve:
> - the agent needs an X display, so we need to express in a systemd user
>   unit that xorg needs to be running

Tried searching a bit: maybe graphical-session.target could help?
https://www.freedesktop.org/software/systemd/man/systemd.special.html#graphical-session.target

> - I tried a unit file which tries to start spice-vdagent only if the
>   needed device is present, but then spice-vdagentd fails to get the session 
> info
>   from systemd because spice-vdagent was not run in a 'user session'
>   context I guess. We need to know if the spice-vdagent which is running
>   is run by the user in the 'active seat', and I have no idea if this
>   is compatible with systemd user units...
>
> At this point, I'd just go with this patch

This surely looks like the easiest way. I think it is fine.

Jakub
>
> Christophe
>
> >
> > Cheers,
> > Jakub
> >
> > > - reworded the message
> > >
> > >  src/vdagent/vdagent.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/vdagent/vdagent.c b/src/vdagent/vdagent.c
> > > index 90247f9..ff3328c 100644
> > > --- a/src/vdagent/vdagent.c
> > > +++ b/src/vdagent/vdagent.c
> > > @@ -451,8 +451,8 @@ int main(int argc, char *argv[])
> > >  LOG_USER);
> > >
> > >  if (file_test(portdev) != 0) {
> > > -syslog(LOG_ERR, "Cannot access vdagent virtio channel %s", 
> > > portdev);
> > > -return 1;
> > > +g_debug("vdagent virtio channel %s does not exist, exiting", 
> > > portdev);
> > > +return 0;
> > >  }
> > >
> > >  if (do_daemonize)
> > > --
> > > 2.20.1
> > >
> > > ___
> > > 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-linux v3] vdagent: Use g_file_test() instead of direct stat call

[Jakub Janku]

On Wed, Jan 30, 2019 at 1:50 PM Christophe Fergeau  wrote:
>
> vdagent.c has a 'file_test' function which tests for the existence of
> the /dev entry for the spicevmc channel. glib already provides such a
> g_file_test() function, so we can use it instead.
>
> Signed-off-by: Christophe Fergeau 
> ---
>  src/vdagent/vdagent.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/src/vdagent/vdagent.c b/src/vdagent/vdagent.c
> index ff3328c..adb56c4 100644
> --- a/src/vdagent/vdagent.c
> +++ b/src/vdagent/vdagent.c
> @@ -28,8 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -319,13 +317,6 @@ static int daemonize(void)
>  return 0;
>  }
>
> -static int file_test(const char *path)
> -{
> -struct stat buffer;
> -
> -return stat(path, &buffer);
> -}
> -
>  static gboolean x11_io_channel_cb(GIOChannel *source,
>GIOCondition condition,
>gpointer data)
> @@ -450,7 +441,7 @@ int main(int argc, char *argv[])
>  openlog("spice-vdagent", do_daemonize ? LOG_PID : (LOG_PID | LOG_PERROR),
>  LOG_USER);
>
> -if (file_test(portdev) != 0) {
> +if (!g_file_test(portdev, G_FILE_TEST_EXISTS)) {
>  g_debug("vdagent virtio channel %s does not exist, exiting", 
> portdev);
>  return 0;
>  }
> --

Acked-by: Jakub Janků 

> 2.20.1
>
> ___
> 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 v4 2/2] gtk-session: clipboard: x11: owner-change improvement

[Jakub Janku]

ping?

On Mon, Jan 28, 2019 at 10:29 AM Jakub Janku  wrote:
>
> Hi,
>
> I tried to fix this bug in a less radical way, but my patch unfortunately did 
> not cover all the cases.
>
> I obtained some logs from James Harvey which make the situation clearer - it 
> can be found here:
> https://termbin.com/40un
> So I'll try to explain what's happening:
>
> James uses KDE which has a clipboard manager integrated in (klipper).
>
> (1) user copies something in the guest, grab is sent to the spice-gtk
> (2) clipboard manager immediately requests the data, data is retrieved from 
> the vdagent
> (3) user pastes the copied data in guest, this causes a quick re-grab in the 
> guest = a clipboard release message is sent to spice-gtk and it is 
> immediately followed by a new grab
> (4) spice-gtk receives clipboard release, so it clears the clipboard
> (5) clipboard manager detects that the clipboard has no owner, so it grabs it 
> itself, advertising the data it originally obtained from us in step (2) (this 
> normally enables the user to paste the data even after the source app has 
> been closed)
> (6) spice-gtk receives "owner-change" signal caused by the grab in step (5), 
> requests clipboard targets and sends a grab to vdagent
> (7) spice-gtk finally receives the grab from step (3), so it sets the 
> clipboard using gtk_clipboard_set_with_owner()
> (8) vdagent receives grab from step (6), so it too sets the clipboard using 
> gtk_clipboard_set_with_owner()
>
> This is clearly a race. We ended up in a state where both spice-gtk and 
> vdagent thinks the other component can provide the data, but in reality none 
> of them can.
>
> (This does not happen always, as can be seen in the log, the first paste 
> succeeds.)
>
> Given current spice protocol, I don't see a way to detect the race on either 
> side, but I'd love to be wrong. So I'd update the commit log and comment in 
> the code to explain the situation and then it's ack from me.
>
> Cheers,
> Jakub
>
> On Mon, Jan 14, 2019, 1:34 PM Victor Toso >
>> From: Victor Toso 
>>
>> On X11, the release-grab message might end up clearing the
>> GtkClipboard which triggers the owner-changed callback having the
>> event owner as NULL.
>>
>> We should not be calling gtk_clipboard_request_targets() in this
>> situation as is prone to errors as the intention here is request
>> clipboard information from changes made by client OS.
>>
>> The fix is to avoid any such request while spice client is holding the
>> keyboard grab.
>>
>> Related: https://gitlab.freedesktop.org/spice/win32/vd_agent/issues/6
>> Related: https://gitlab.freedesktop.org/spice/linux/vd_agent/issues/9
>> Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
>>
>> Changed in v4:
>> - Updated commit log
>>
>> Signed-off-by: Victor Toso 
>> Tested-by: James Harvey @jamespharvey20
>> ---
>>  src/spice-gtk-session.c | 13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
>> index abce43f..20df70d 100644
>> --- a/src/spice-gtk-session.c
>> +++ b/src/spice-gtk-session.c
>> @@ -674,6 +674,19 @@ static void clipboard_owner_change(GtkClipboard
>> *clipboard,
>>  return;
>>  }
>>
>> +#ifdef GDK_WINDOWING_X11
>> +/* In X11, while holding the keyboard-grab we are not interested in this
>> + * event as it either came by grab or release messages from agent.  */
>> +if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
>> +spice_gtk_session_get_keyboard_has_focus(self)) {
>> +SPICE_DEBUG("clipboard: owner-changed event: not requesting 
>> client's target "
>> +"while holding focus");
>> +return;
>> +}
>> +#endif
>> +SPICE_DEBUG("clipboard: owner-changed event: has-focus=%d",
>> +spice_gtk_session_get_keyboard_has_focus(self));
>> +
>>  s->clipboard_by_guest[selection] = FALSE;
>>  s->clip_hasdata[selection] = TRUE;
>>  if (s->auto_clipboard_enable && !read_only(self))
>> --
>> 2.20.1
>>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v4 2/2] gtk-session: clipboard: x11: owner-change improvement

[Jakub Janku]

On Mon, Feb 11, 2019 at 10:30 AM Victor Toso  wrote:
>
> Hi,
>
> On Mon, Feb 11, 2019 at 10:12:42AM +0100, Jakub Janku wrote:
> > ping?
>
> Should be fixed by:

You can double-check with James to be sure, but I don't think that's true.

If you look at the logs ( https://termbin.com/40un ), there's the
following line:
|   (virt-viewer:25767): GSpice-DEBUG: 21:29:06.743:
spice-gtk-session.c:556 Retrieving the clipboard data has failed
And the commit you mention below fixes exactly that and that's all,
the race is still there.

Cheers,
Jakub
>
> commit 214f8fd969127c41a7d53def196118ee0549a411
> Author: Jakub Janků 
> Date:   Sun Jan 27 18:14:20 2019 +0100
>
> clipboard: don't request targets without owner on X11
>
> On X11, if the owner in GdkEventOwnerChange is set to NULL,
> it means there's no data in the clipboard, so it's pointless to
> request targets as the request will fail anyway.
>
> On Wayland, owner is always NULL, so don't do anything there.
>
> Signed-off-by: Jakub Janků 
> Acked-by: Victor Toso 
>
> The fact that the patch in this mail thread is related to keyboard-grab
> was the reason to be nacked. If you want to discuss that, we might move
> along to that thread on clibpoard-managers, sent as RFC
>
>     
> https://lists.freedesktop.org/archives/spice-devel/2019-January/047259.html
>
> > On Mon, Jan 28, 2019 at 10:29 AM Jakub Janku  wrote:
> > >
> > > Hi,
> > >
> > > I tried to fix this bug in a less radical way, but my patch unfortunately 
> > > did not cover all the cases.
> > >
> > > I obtained some logs from James Harvey which make the situation clearer - 
> > > it can be found here:
> > > https://termbin.com/40un
> > > So I'll try to explain what's happening:
> > >
> > > James uses KDE which has a clipboard manager integrated in (klipper).
> > >
> > > (1) user copies something in the guest, grab is sent to the
> > > spice-gtk
> > > (2) clipboard manager immediately requests the data, data is
> > > retrieved from the vdagent
> > > (3) user pastes the copied data in guest, this causes a quick
> > > re-grab in the guest = a clipboard release message is sent to
> > > spice-gtk and it is immediately followed by a new grab
> > > (4) spice-gtk receives clipboard release, so it clears the clipboard
> > > (5) clipboard manager detects that the clipboard has no owner, so it
> > > grabs it itself, advertising the data it originally obtained from us
> > > in step (2) (this normally enables the user to paste the data even
> > > after the source app has been closed)
> > > (6) spice-gtk receives "owner-change" signal caused by the grab in
> > > step (5), requests clipboard targets and sends a grab to vdagent
> > > (7) spice-gtk finally receives the grab from step (3), so it sets
> > > the clipboard using gtk_clipboard_set_with_owner()
> > > (8) vdagent receives grab from step (6), so it too sets the
> > > clipboard using gtk_clipboard_set_with_owner()
> > >
> > > This is clearly a race. We ended up in a state where both spice-gtk
> > > and vdagent thinks the other component can provide the data, but in
> > > reality none of them can.
> > >
> > > (This does not happen always, as can be seen in the log, the first
> > > paste succeeds.)
> > >
> > > Given current spice protocol, I don't see a way to detect the
> > > race on either side, but I'd love to be wrong. So I'd update
> > > the commit log and comment in the code to explain the
> > > situation and then it's ack from me.
>
> I think we can still improve documentation to clarify the race and
> behaviors. There are a few things that I thought were obvious and in
> fact Marc-André pointed out I was wrong.
>
> Either way, let me know if I'm missing something.
>
> Cheers!
>
> > > Cheers,
> > > Jakub
> > >
> > > On Mon, Jan 14, 2019, 1:34 PM Victor Toso  > >>
> > >> From: Victor Toso 
> > >>
> > >> On X11, the release-grab message might end up clearing the
> > >> GtkClipboard which triggers the owner-changed callback having the
> > >> event owner as NULL.
> > >>
> > >> We should not be calling gtk_clipboard_request_targets() in this
> > >> situation as is prone to errors as the intention here is request
> > >> clipboard information from changes made by client OS.
> > >>
&g

Re: [Spice-devel] [spice-gtk [rfc] 0/2] Clipboard managers and Spice

[Jakub Janku]

Hi,

not a full review, but this is my main concern with this series:

If you enable the new --allow-clipboard-managers property, the
behaviour stays the same as it is at the moment, so you're basically
enabling a bug in the code and it's being advertised as a feature.
This seems just wrong to me.

Given that this use-case seems rather rare and that a fix of the race
(most likely) requires a change of the protocol, I'm still in favour
of accepting a patch like [0] that you sent earlier:

[0] https://lists.freedesktop.org/archives/spice-devel/2019-January/047192.html

Cheers,
Jakub

On Tue, Jan 15, 2019 at 5:11 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> Hi,
>
> Several iteractions trying to avoid some bug in X11 but in the end I
> found the iteraction with Clibpoard managers (or any other application
> that request/set clipboard data) a bit more urgent.
>
> Simple try here, to not allow another application to request clipboard
> data from guest while the user is theoretically interacting with that
> guest machine as spice client holds the keyboard-grab.
>
> As pointed out by elmarco [0], that might be something desireable. So,
> I'm introducing the possibility to enable it but have it disabled by
> default.
>
> Tested on X11 and Wayland clients.
>
> There are more than on away to achieve this idea so feedback is welcome.
>
> I expect that the spice client would implement some sort to commandline
> option like --allow-clipobard-managers to enable/disable the
> SpiceGtkSession property on the fly. For now, there is an option in
> spicy testing tool.
>
> James, would be great if you could verify if this series keep your
> environment bug free.
>
> Cheers,
>
> Victor Toso (2):
>   gtk-session: introduce clipboard-managers property
>   gtk-session: add request targets delayed
>
>  src/spice-gtk-session.c | 128 +---
>  tools/spicy.c   |   6 ++
>  2 files changed, 125 insertions(+), 9 deletions(-)
>
> --
> 2.20.1
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk [rfc] 0/2] Clipboard managers and Spice

[Jakub Janku]

On Mon, Feb 11, 2019 at 3:05 PM Victor Toso  wrote:
>
> Hi,
>
> On Mon, Feb 11, 2019 at 02:46:55PM +0100, Jakub Janku wrote:
> > Hi,
> >
> > not a full review, but this is my main concern with this series:
> >
> > If you enable the new --allow-clipboard-managers property, the
> > behaviour stays the same as it is at the moment, so you're basically
> > enabling a bug in the code and it's being advertised as a feature.
> > This seems just wrong to me.
> >
> > Given that this use-case seems rather rare and that a fix of the race
> > (most likely) requires a change of the protocol, I'm still in favour
> > of accepting a patch like [0] that you sent earlier:
> >
> > [0] 
> > https://lists.freedesktop.org/archives/spice-devel/2019-January/047192.html
>
> Those things are unrelated. This series does not intend to solve
> the bug, but to take in consideration sharing or not clipboard in
> situations that might be unexpected.
>
> That is, if user is browsing a website in Firefox app while
> remote-viewer might be sending clipboard changes to remote guest
> or, similarly, user is interacting with some App in the remote
> guest and another application in the client is eavesdropping
> that.
>
> I would like to disable by default those scenarios and if user
> really wants that behavior, it should so something like
> --allow-clipboard-managers.

Ah, I see, so this series tries to address security concerns, correct?

Sorry, I got confused as you mentioned this series today in the
discussion on the patch I linked here:
"The fact that the patch in this mail thread is related to keyboard-grab
was the reason to be nacked. If you want to discuss that, we might move
along to that thread on clibpoard-managers, sent as RFC"

Apart from that, if allow_clipboard_managers is set to FALSE, the
behaviour matches the one with the patch that does try to solve the
bug, although the rationale is different.

>
> > Cheers,
> > Jakub
> >
> > On Tue, Jan 15, 2019 at 5:11 PM Victor Toso  wrote:
> > >
> > > From: Victor Toso 
> > >
> > > Hi,
> > >
> > > Several iteractions trying to avoid some bug in X11 but in the end I
> > > found the iteraction with Clibpoard managers (or any other application
> > > that request/set clipboard data) a bit more urgent.
> > >
> > > Simple try here, to not allow another application to request clipboard
> > > data from guest while the user is theoretically interacting with that
> > > guest machine as spice client holds the keyboard-grab.
> > >
> > > As pointed out by elmarco [0], that might be something desireable. So,
> > > I'm introducing the possibility to enable it but have it disabled by
> > > default.
> > >
> > > Tested on X11 and Wayland clients.
> > >
> > > There are more than on away to achieve this idea so feedback is welcome.
> > >
> > > I expect that the spice client would implement some sort to commandline
> > > option like --allow-clipobard-managers to enable/disable the
> > > SpiceGtkSession property on the fly. For now, there is an option in
> > > spicy testing tool.
> > >
> > > James, would be great if you could verify if this series keep your
> > > environment bug free.
> > >
> > > Cheers,
> > >
> > > Victor Toso (2):
> > >   gtk-session: introduce clipboard-managers property
> > >   gtk-session: add request targets delayed
> > >
> > >  src/spice-gtk-session.c | 128 +---
> > >  tools/spicy.c   |   6 ++
> > >  2 files changed, 125 insertions(+), 9 deletions(-)
> > >
> > > --
> > > 2.20.1
> > >
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk [rfc] 1/2] gtk-session: introduce clipboard-managers property

[Jakub Janku]

Hi,

On Tue, Jan 15, 2019 at 5:11 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> SpiceGtkSession::allow-clipboard-managers property is introduced to
> enable other applications in the Client OS to set or fetch clipboard
> data from a spice-gtk-session that is under keyboard-grab, which is
> expected to be in use by the user.
>
> This option is disabled by default as to avoid:
> 1) Another application in the client to fetch clipboard data while the
>user is interacting with the remote machine;

You're implementing this by leaving the GtkSelectionData empty upon
GtkClipboardGetFunc.
This seems weird to me. By grabbing the clipboard, spice-gtk proclaims
it can provide clipboard data, but if another app asks for this data,
spice-gtk provides none.
It naturally depends on the implementation of the given app, but I
think that in the case of a clipboard manager, user could see empty
entries in the clipboard history, which is imho unwanted. (haven't
tested)
If spice-gtk is not willing to give the data to other apps, it
shouldn't advertise it in the first place, I think.
So I would rather implement it by delaying the grab the same way you
do it in case 2) below.

> 2) Another application to set clipboard data *and* send that to the
>remote machine while the user is *not* interacting with the remote
>machine (without keyboard grab)

I see that you're trying to prevent apps in guest from eavesdropping
on the client clipboard while the user is not interacting with the
remote machine.
But I think there's another point of view: if the given app grabbed
the clipboard, it can also be interpreted as that the app decided to
share its data with other apps. And in that case, I don't see why
spice-gtk should impede the sharing. Note, that e.g. obscured
passwords in browsers cannot be copied in the clipboard (this is an
example of the case when app doesn't want to share its data).

Apart from that, there isn't really any good way to clear the
clipboard afaik, unless you store something new in it. Doesn't seem
like something a lot of users would do. So the sensitive data would
get leaked anyway the moment you click into the remote machine's
window.

So I'm rather inclined to agree with the opinion that this should be
enforced by the desktop, not us.

Cheers,
Jakub
>
> This patch disables (1) and following patch disables (2) if
> allow-clipboard-managers is disabled which is set to be default.
>
> This patch also fixes some indentation found in spice-gtk-session.c
>
> Signed-off-by: Victor Toso 
> ---
>  src/spice-gtk-session.c | 51 +
>  tools/spicy.c   |  6 +
>  2 files changed, 53 insertions(+), 4 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index adc72a2..7391e6a 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -59,6 +59,7 @@ struct _SpiceGtkSessionPrivate {
>  gbooleanclip_hasdata[CLIPBOARD_LAST];
>  gbooleanclip_grabbed[CLIPBOARD_LAST];
>  gbooleanclipboard_by_guest[CLIPBOARD_LAST];
> +gbooleanback_from_focus_out;
>  /* auto-usbredir related */
>  gbooleanauto_usbredir_enable;
>  int auto_usbredir_reqs;
> @@ -66,6 +67,7 @@ struct _SpiceGtkSessionPrivate {
>  gbooleankeyboard_has_focus;
>  gbooleanmouse_has_pointer;
>  gbooleansync_modifiers;
> +gbooleanallow_clipboard_managers;
>  };
>
>  /**
> @@ -114,6 +116,7 @@ enum {
>  PROP_AUTO_USBREDIR,
>  PROP_POINTER_GRABBED,
>  PROP_SYNC_MODIFIERS,
> +PROP_ALLOW_CLIPBOARD_MANAGER,
>  };
>
>  static guint32 get_keyboard_lock_modifiers(void)
> @@ -287,6 +290,9 @@ static void spice_gtk_session_get_property(GObject
> *gobject,
>  case PROP_SYNC_MODIFIERS:
>  g_value_set_boolean(value, s->sync_modifiers);
>  break;
> +case PROP_ALLOW_CLIPBOARD_MANAGER:
> +g_value_set_boolean(value, s->allow_clipboard_managers);
> +break;
>  default:
> G_OBJECT_WARN_INVALID_PROPERTY_ID(gobject, prop_id, pspec);
> break;
> @@ -337,6 +343,9 @@ static void spice_gtk_session_set_property(GObject  
> *gobject,
>  case PROP_SYNC_MODIFIERS:
>  s->sync_modifiers = g_value_get_boolean(value);
>  break;
> +case PROP_ALLOW_CLIPBOARD_MANAGER:
> +s->allow_clipboard_managers = g_value_get_boolean(value);
> +break;
>  default:
>  G_OBJECT_WARN_INVALID_PROPERTY_ID(gobject, prop_id, pspec);
>  break;
> @@ -441,6 +450,23 @@ static void 
> spice_gtk_session_class_init(SpiceGtkSessionClass *klass)
>G_PARAM_READWRITE |
>G_PARAM_CONSTRUCT |
>G_PARAM_STATIC_STRINGS));
> +/**
> + * SpiceGtkSession:allow-clipboard-managers
> + *
> + * Allow clip

Re: [Spice-devel] [linux/vd-agent 0/3] rm TODO and README -> README.md

[Jakub Janku]

Hi,

while we're at it, what about merging ChangeLog and NEWS into one file
and using markdown here as well?

Gitlab seems to favour ChangeLog over NEWS, so if you click the
"CHANGELOG" button at [0], the ChangeLog file is shown which does not
contain the latest updates.
[0] https://gitlab.freedesktop.org/spice/linux/vd_agent

Cheers,
Jakub

On Fri, Feb 22, 2019 at 4:19 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> Hi,
>
> Just some minor changes. We probably want to update README.md for the
> upcoming release.
>
> Victor Toso (3):
>   Remove TODO
>   Make README a markdown file
>   README: Use block quotes for code or paths
>
>  README => README.md | 17 +++--
>  TODO|  3 ---
>  2 files changed, 11 insertions(+), 9 deletions(-)
>  rename README => README.md (89%)
>  delete mode 100644 TODO
>
> --
> 2.20.1
>
> ___
> 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] [linux/vd-agent 3/3] README: Use block quotes for code or paths

[Jakub Janku]

Hi,

in the README file, there are some formatting errors that I think
could be fixed in this patch as well, namely:

* Sentence starting with "Then connect" should be in a new paragraph,
not in the nested list
* the command "spicec --full-screen=auto-config" could be enclosed in
backquotes rather than doubleqoutes
* the sublist containing limitations of multi-monitor setup is not
properly formatted

Cheers,
Jakub

On Fri, Feb 22, 2019 at 4:19 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> Makes it easier to copy-and-paste.
>
> Signed-off-by: Victor Toso 
> ---
>  README.md | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/README.md b/README.md
> index 67a66a5..089c0e5 100644
> --- a/README.md
> +++ b/README.md
> @@ -44,15 +44,20 @@ All vdagent communications on the guest side run over a 
> single pipe which
>  gets presented to the guest os as a virtio serial port.
>
>  Under windows this virtio serial port has the following name:
> -.\\Global\\com.redhat.spice.0
> +>>>
> +.\\Global\\com.redhat.spice.0
> +>>>
>
>  Under Linux this virtio serial port has the following name:
> -/dev/virtio-ports/com.redhat.spice.0
> +>>>
> +/dev/virtio-ports/com.redhat.spice.0
> +>>>
>
>  To enable the virtio serial port you need to pass the following params on
>  the qemu cmdline:
>
> --device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \
> --chardev spicevmc,name=vdagent,id=vdagent \
> --device \
> -virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0
> +>>>
> +-device 
> virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \
> +-chardev spicevmc,name=vdagent,id=vdagent \
> +-device 
> virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0
> +>>>
> --
> 2.20.1
>
> ___
> 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] [linux/vd-agent 5/5] CHANGELOG: Move NEWS' content

[Jakub Janku]

Hi,

NEWS is appended to EXTRA_DIST var in Makefile.am, so we should change
that to CHANGELOG.md, if I'm not mistaken.

Jakub

On Fri, Feb 22, 2019 at 6:23 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> And add some Markdown style.
>
> Signed-off-by: Victor Toso 
> ---
>  CHANGELOG.md | 47 +++
>  NEWS | 46 --
>  2 files changed, 47 insertions(+), 46 deletions(-)
>  delete mode 100644 NEWS
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 0ce7a62..6245f53 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -1,3 +1,50 @@
> +News in spice-vdagent 0.18.0
> +
> +
> +* Add GTK+ framework to handle x11 backend such as clipboard
> +* Deprecate X11 backend in favor of GTK+ framework
> +* Ask pkg-config to appropriate directory to install udev rules
> +* Fix leak of udscs's file descriptor
> +* Better quote directory path when calling xdg-open to save file transfer
> +* Bump GLib to 2.34
> +* Add systemd socket activation (rhbz#1340160)
> +* Add support to detailed errors on file transfers
> +* Add check for available free space in guest before starting a file transfer
> +* Use better names for duplicated files on file transfer
> +* Improve support on big endian guests (#5)
> +* Use IdleHint to check if a session is locked over console-kit 
> (rhbz#1412673)
> +* Fixes double free on errors over udscs by improving memory ownership
> +* Hide autostart file on Unity
> +* Improve command line messages for vdagentd
> +* Fix typo in --enable-static-uinput configure option
> +* Code repository moved to gitlab.freedesktop.org
> +
> +News in spice-vdagent 0.17.0
> +
> +
> +* Denies file-transfer in locked sessions
> +  * systems under systemd (rhbz#1323623)
> +  * systems under console-kit (rhbz#1323630)
> +* Denies file-transfer in login screen
> +  * systems under systemd (rhbz#1328761)
> +  * systems under console-kit (rhbz#1323640)
> +* Bump glib version to 2.28
> +* Set exit code to 1 instead of 0 when virtio device cannot be opened
> +* Fix double-free on uinput->screen_info (rhbz#1262635)
> +* Code improvement over unix domain client server support (udcs)
> +* Fix build compatiblity with different libsystemd versions (fdo#94209)
> +
> +News in spice-vdagent 0.16.0
> +
> +
> +* Add audio volume synchronization support
> +* Add support for maximum clipboard size
> +* Add support for more clipboard targets (STRING and TIMESTAMP)
> +* Improve handling of transfers of multiple files
> +* Fix transfer of >2GB files on 32 bit systems
> +* XSpice improvements
> +* Various bug fixes related to resolution changes
> +
>  News in spice-vdagent 0.15.0
>  
>
> diff --git a/NEWS b/NEWS
> deleted file mode 100644
> index 86ee8e9..000
> --- a/NEWS
> +++ /dev/null
> @@ -1,46 +0,0 @@
> -Overview of changes in SPICE vdagent 0.18.0
> -===
> -
> -- Add GTK+ framework to handle x11 backend such as clipboard
> -- Deprecate X11 backend in favor of GTK+ framework
> -- Ask pkg-config to appropriate directory to install udev rules
> -- Fix leak of udscs's file descriptor
> -- Better quote directory path when calling xdg-open to save file transfer
> -- Bump GLib to 2.34
> -- Add systemd socket activation (rhbz#1340160)
> -- Add support to detailed errors on file transfers
> -- Add check for available free space in guest before starting a file transfer
> -- Use better names for duplicated files on file transfer
> -- Improve support on big endian guests (#5)
> -- Use IdleHint to check if a session is locked over console-kit 
> (rhbz#1412673)
> -- Fixes double free on errors over udscs by improving memory ownership
> -- Hide autostart file on Unity
> -- Improve command line messages for vdagentd
> -- Fix typo in --enable-static-uinput configure option
> -- Code repository moved to gitlab.freedesktop.org
> -
> -Overview of changes in SPICE vdagent 0.17.0
> -===
> -
> -- Denies file-transfer in locked sessions
> -  * systems under systemd (rhbz#1323623)
> -  * systems under console-kit (rhbz#1323630)
> -- Denies file-transfer in login screen
> -  * systems under systemd (rhbz#1328761)
> -  * systems under console-kit (rhbz#1323640)
> -- Bump glib version to 2.28
> -- Set exit code to 1 instead of 0 when virtio device cannot be opened
> -- Fix double-free on uinput->screen_info (rhbz#1262635)
> -- Code improvement over unix domain client server support (udcs)
> -- Fix build compatiblity with different libsystemd versions (fdo#94209)
> -
> -Overview of changes in SPICE vdagent 0.16.0
> -===
> -
> -- Add audio volume synchronization support
> -- Add support for maximum clipboard size
> -- Add support for more clipboard targets (STRING and TIMESTAMP)
> -- Improve handling of transfers of multiple files
> -- Fix transfer o

Re: [Spice-devel] [linux/vd-agent v2 3/5] README: Remove non relevant features information

[Jakub Janku]

Hi,

On Mon, Feb 25, 2019 at 6:04 PM Victor Toso  wrote:
>
> From: Victor Toso 
>
> It is not relevant nowadays that *spicec* client was removed and even
> monitors_config does not reach spice-vdagent in modern Guests.
>
Can't really evaluate this with my current knowledge of spice &
monitor config handling.

The rest looks good to me.

Cheers,
Jakub

> Also add block quote for qemu cmdline and system's paths to make it
> easier to copy-and-paste.
>
> Signed-off-by: Victor Toso 
> ---
>  README.md | 34 +-
>  1 file changed, 13 insertions(+), 21 deletions(-)
>
> diff --git a/README.md b/README.md
> index 67a66a5..82a0103 100644
> --- a/README.md
> +++ b/README.md
> @@ -23,36 +23,28 @@ Features:
>  * Support for transferring files from the client to the agent
>  * Full support for multiple displays using Xrandr, this requires a new
>enough xorg-x11-drv-qxl driver, as well as a new enough host.
> -* Limited support for multiple displays using Xinerama, prerequisites:
> -  * A new enough Xorg server: Fedora 17 or greater, for RHEL 6
> -xorg-x11-server-1.10.4-6.el6_2.3 or greater.
> -  * A vm configured with multiple qxl devices
> -  * A guest running the latest spice-vdagent
> -  Then connect to the vm with the multiple monitor client which you want to
> -  use it with using: "spicec --full-screen=auto-config" (or the user portal
> -  equivalent). At this point the agent will write out a:
> -  /run/spice-vdagentd/xorg.conf.spice file. With all the necessary magic
> -  to get Xinerama working. Move this file to /etc/X11/xorg.conf, then kill
> -  Xorg so that it will get restarted and you should be good to go.
> +* Limited support for multiple displays using Xinerama.
>  * Limited support for setups with multiple Screens (multiple qxl devices each
> -  mapped to their own screen), limitations:
> - -Max one monitor per Screen / qxl device
> - -All monitors / Screens must have the same resolution
> - -No client -> guest resolution syncing
> +  mapped to their own screen)
>
>  All vdagent communications on the guest side run over a single pipe which
>  gets presented to the guest os as a virtio serial port.
>
>  Under windows this virtio serial port has the following name:
> -.\\Global\\com.redhat.spice.0
> +>>>
> +.\\Global\\com.redhat.spice.0
> +>>>
>
>  Under Linux this virtio serial port has the following name:
> -/dev/virtio-ports/com.redhat.spice.0
> +>>>
> +/dev/virtio-ports/com.redhat.spice.0
> +>>>
>
>  To enable the virtio serial port you need to pass the following params on
>  the qemu cmdline:
>
> --device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \
> --chardev spicevmc,name=vdagent,id=vdagent \
> --device \
> -virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0
> +>>>
> +-device 
> virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \
> +-chardev spicevmc,name=vdagent,id=vdagent \
> +-device 
> virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0
> +>>>
> --
> 2.20.1
>
> ___
> 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 1/3] clipboard: accept grab only from the side with keyboard focus

[Jakub Janku]

Hi,

thanks for having a look!

On Wed, Mar 6, 2019 at 6:42 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků  wrote:
> >
> > If two grab messages in opposite directions "meet" on their way
> > to their destinations, we end up in a state when both spice-gtk
> > and spice-vdagent think that the other component can provide
> > clipboard data. As a consequence of this, neither of them can.
> >
> > This is a bug in the spice-protocol. To mitigate the issue,
>
> With such as statement, you should provide detailed analysis, and
> strong arguments for workarounds.

Depends on what you consider to be "detailed analysis". Since you
correctly restated the problem with your own words, it seems like my
rather short description served its purpose :)
Also please note that I've tried to provide a more detailed analysis
of the issue reported by James Harvey earlier in [0]

[0] https://lists.freedesktop.org/archives/spice-devel/2019-January/047614.html

As for the arguments, I've actually expressed my main argument in the
cover letter, have you read it?
"Intention of these patches is to make spice-gtk
behave reasonably well with older agents."
I would like to have this patch reviewed with this in mind.
So this patch NOT trying to be a final solution to the problem.

If you look at the race condition from the standpoint of spice-gtk,
the situation looks the following:
1) spice-gtk sends grab
2) spice-gtk receives grab
You can't tell if it's a race or not. The normal behaviour can look the same.

Now, if you consider fix in spice-gtk only (to make older vdagents
play nicely with new spice-gtk), I see these possible mitigations:
a) measure time between 1) and 2) and discard one grab if the elapsed
time is too short:
this solution is rather empirical and seems unreliable to me
b) accept grab only from one side at a moment - that is what this patch does

>
> I think you are describing this conflicting situation: (all messages
> are asynchronous here, A & B are either client or remote end
> interchangeably)
>
> A->B: grab
> B->A: grab
> A: handle B grab
> B: handle A grab
>
> Both A&B think the other end has the grab...
>
> If we would instead explicitly release the grab, none would have it,
> which could be considered an improvement:

Yes, a slight improvement. However, the original grabs both in client
and guest would be lost, which is unwanted.
>
> A->B: grab
> B->A: grab
> A: handle B grab
> A->B: release
> B: handle A grab
> B->A: release
> B: handle A release
> A: handle B release
>
> Instead, we should probably have a priority for who wins. I suppose it
> should be the client.

Not necessarily. Consider James' case: if we make the client win, the
clipboard manager in the client would take over the clipboard in the
guest. The clipboard manager filters out some of the targets and
additionally, the "marching ants" in Excel would disappear.

>But how to distinguish the conflict case with
> the normal case? Perhaps an incremental counter (age/generation,
> whatever you call it) would be enough.

This would need a protocol change.
So given my note in the cover letter, this comment is quite unrelated
to this patch. I would prefer to discuss the protocol change later.
>
> Did you thought about something along those lines? Would you be able
> to come up with protocol changes for that?
>
> At this point, I think we could use some nice sequence diagrams in the spec!
>
>
> > accept grab only from the side that currently has keyboard focus,
> > this means:
> > (1) spice-gtk has focus ==>
> > * accept grabs from vdagent,
> > * ignore grabs from other apps running in the host
>
> I have a hard time understanding why keyboard focus is related to
> clipboard. clipboard can be interacted with mouse only, or
> independently from any user input. Or from multiple inputs. I try to
> fit the keyboard input this into clipboard interaction issues, and I
> don't think that helps much.

If spice-gtk has keyboard focus, the user interacts with the guest system.
If it doesn't, user interacts with the client system.

Sure, the clipboard can change without user's input. E.g. with some
automation systems, as you pointer out earlier.
However, this is not the usual use case. And with this patch, I'm
trying to fix the most common scenario to provide a better default
experience.
>
> > (2) spice-gtk doesn't have focus ==>
> > * accept grabs from other apps running in the host
> > * ignore grabs from vdagent
> >
> > The check in clipboard_owner_change() is X11-specific,
> > because on Wayland, spice-gtk is first notified about the
> > owner-change once it gains focus.
> >
> > The check in clipboard_grab() can be generic.
> > Note that on Wayland, calling gtk_clipboard_set_with_owner()
> > while not having focus doesn't have any effect anyway,
> > only focused clients can set clipboard.
> >
> > With this patch, the race can still occur around the time
> > when focus changes (rare, but possible), on X11 as well 

Re: [Spice-devel] [PATCH spice-gtk 3/3] clipboard: invalidate targets request when needed

[Jakub Janku]

Hi,

On Wed, Mar 6, 2019 at 7:11 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků  wrote:
> >
> > Targets request is no longer relevant when
> > clipboard owner changes since the retrieved targets
> > will be outdated.
> >
> > When the request is no longer relevant,
> > invalidate it by pointing its weak ref to NULL.
> > As a consequence, free_weak_ref() call returns NULL
> > and clipboard_get_targets() exits.
>
> Why not simply check if user_data == last_targets_request?

This surely looks simpler,
thanks :)

Jakub
>
> What does nullify_weak_ref() really helps with?
>
> >
> > Signed-off-by: Jakub Janků 
> > ---
> >
> > This addresses the same issue that
> > was present in spice-vdagent and is already fixed.
> >
> > ---
> >  src/spice-gtk-session.c | 39 +--
> >  1 file changed, 29 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > index 018cb4b..037547a 100644
> > --- a/src/spice-gtk-session.c
> > +++ b/src/spice-gtk-session.c
> > @@ -59,6 +59,7 @@ struct _SpiceGtkSessionPrivate {
> >  gbooleanclip_hasdata[CLIPBOARD_LAST];
> >  gbooleanclip_grabbed[CLIPBOARD_LAST];
> >  gbooleanclipboard_by_guest[CLIPBOARD_LAST];
> > +GWeakRef*last_targets_request[CLIPBOARD_LAST];
> >  /* auto-usbredir related */
> >  gbooleanauto_usbredir_enable;
> >  int auto_usbredir_reqs;
> > @@ -537,6 +538,16 @@ static gpointer free_weak_ref(gpointer data)
> >  return object;
> >  }
> >
> > +static void nullify_weak_ref(GWeakRef **weak_ref_p)
> > +{
> > +gpointer null_object = NULL;
> > +
> > +if (*weak_ref_p) {
> > +g_weak_ref_set(*weak_ref_p, null_object);
> > +*weak_ref_p = NULL;
> > +}
> > +}
> > +
> >  static void clipboard_get_targets(GtkClipboard *clipboard,
> >GdkAtom *atoms,
> >gint n_atoms,
> > @@ -551,23 +562,25 @@ static void clipboard_get_targets(GtkClipboard 
> > *clipboard,
> >
> >  g_return_if_fail(SPICE_IS_GTK_SESSION(self));
> >
> > -if (atoms == NULL) {
> > -SPICE_DEBUG("Retrieving the clipboard data has failed");
> > -return;
> > -}
> > -
> >  SpiceGtkSessionPrivate *s = self->priv;
> >  guint32 types[SPICE_N_ELEMENTS(atom2agent)] = { 0 };
> >  gint num_types;
> >  int a;
> >  int selection;
> >
> > -if (s->main == NULL)
> > -return;
> > -
> >  selection = get_selection_from_clipboard(s, clipboard);
> >  g_return_if_fail(selection != -1);
> >
> > +s->last_targets_request[selection] = NULL;
> > +
> > +if (atoms == NULL) {
> > +SPICE_DEBUG("Retrieving the clipboard data has failed");
> > +return;
> > +}
> > +
> > +if (s->main == NULL)
> > +return;
> > +
> >  if (s->clip_grabbed[selection]) {
> >  SPICE_DEBUG("Clipboard is already grabbed, ignoring %d atoms", 
> > n_atoms);
> >  return;
> > @@ -652,6 +665,8 @@ static void clipboard_owner_change(GtkClipboard
> > *clipboard,
> >  return;
> >  }
> >
> > +nullify_weak_ref(&s->last_targets_request[selection]);
> > +
> >  /* In case we sent a grab to the agent, we need to release it now as
> >   * previous clipboard data should not be reachable anymore */
> >  if (s->clip_grabbed[selection]) {
> > @@ -690,9 +705,11 @@ static void clipboard_owner_change(GtkClipboard
> > *clipboard,
> >  #endif
> >
> >  s->clip_hasdata[selection] = TRUE;
> > -if (s->auto_clipboard_enable && !read_only(self))
> > +if (s->auto_clipboard_enable && !read_only(self)) {
> > +s->last_targets_request[selection] = get_weak_ref(self);
> >  gtk_clipboard_request_targets(clipboard, clipboard_get_targets,
> > -  get_weak_ref(self));
> > +  s->last_targets_request[selection]);
> > +}
> >  }
> >
> >  typedef struct
> > @@ -866,6 +883,8 @@ static gboolean clipboard_grab(SpiceMainChannel *main, 
> > guint selection,
> >  return TRUE;
> >  }
> >
> > +nullify_weak_ref(&s->last_targets_request[selection]);
> > +
> >  if (!gtk_clipboard_set_with_owner(cb,
> >targets,
> >num_targets,
> > --
> > 2.20.1
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
> --
> Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk 1/3] clipboard: accept grab only from the side with keyboard focus

[Jakub Janku]

Hi,

On Fri, Mar 8, 2019 at 1:15 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Thu, Mar 7, 2019 at 10:36 PM Jakub Janku  wrote:
> >
> > Hi,
> >
> > thanks for having a look!
> >
> > On Wed, Mar 6, 2019 at 6:42 PM Marc-André Lureau
> >  wrote:
> > >
> > > Hi
> > >
> > > On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků  wrote:
> > > >
> > > > If two grab messages in opposite directions "meet" on their way
> > > > to their destinations, we end up in a state when both spice-gtk
> > > > and spice-vdagent think that the other component can provide
> > > > clipboard data. As a consequence of this, neither of them can.
> > > >
> > > > This is a bug in the spice-protocol. To mitigate the issue,
> > >
> > > With such as statement, you should provide detailed analysis, and
> > > strong arguments for workarounds.
> >
> > Depends on what you consider to be "detailed analysis". Since you
> > correctly restated the problem with your own words, it seems like my
> > rather short description served its purpose :)
> > Also please note that I've tried to provide a more detailed analysis
> > of the issue reported by James Harvey earlier in [0]
> >
> > [0] 
> > https://lists.freedesktop.org/archives/spice-devel/2019-January/047614.html
> >
> > As for the arguments, I've actually expressed my main argument in the
> > cover letter, have you read it?
> > "Intention of these patches is to make spice-gtk
> > behave reasonably well with older agents."
> > I would like to have this patch reviewed with this in mind.
> > So this patch NOT trying to be a final solution to the problem.
> >
> > If you look at the race condition from the standpoint of spice-gtk,
> > the situation looks the following:
> > 1) spice-gtk sends grab
> > 2) spice-gtk receives grab
> > You can't tell if it's a race or not. The normal behaviour can look the 
> > same.
> >
> > Now, if you consider fix in spice-gtk only (to make older vdagents
> > play nicely with new spice-gtk), I see these possible mitigations:
> > a) measure time between 1) and 2) and discard one grab if the elapsed
> > time is too short:
> > this solution is rather empirical and seems unreliable to me
> > b) accept grab only from one side at a moment - that is what this patch does
> >
> > >
> > > I think you are describing this conflicting situation: (all messages
> > > are asynchronous here, A & B are either client or remote end
> > > interchangeably)
> > >
> > > A->B: grab
> > > B->A: grab
> > > A: handle B grab
> > > B: handle A grab
> > >
> > > Both A&B think the other end has the grab...
> > >
> > > If we would instead explicitly release the grab, none would have it,
> > > which could be considered an improvement:
> >
> > Yes, a slight improvement. However, the original grabs both in client
> > and guest would be lost, which is unwanted.
> > >
> > > A->B: grab
> > > B->A: grab
> > > A: handle B grab
> > > A->B: release
> > > B: handle A grab
> > > B->A: release
> > > B: handle A release
> > > A: handle B release
> > >
> > > Instead, we should probably have a priority for who wins. I suppose it
> > > should be the client.
> >
> > Not necessarily. Consider James' case: if we make the client win, the
> > clipboard manager in the client would take over the clipboard in the
> > guest. The clipboard manager filters out some of the targets and
> > additionally, the "marching ants" in Excel would disappear.
> >
> > >But how to distinguish the conflict case with
> > > the normal case? Perhaps an incremental counter (age/generation,
> > > whatever you call it) would be enough.
> >
> > This would need a protocol change.
> > So given my note in the cover letter, this comment is quite unrelated
> > to this patch. I would prefer to discuss the protocol change later.
> > >
> > > Did you thought about something along those lines? Would you be able
> > > to come up with protocol changes for that?
> > >
> > > At this point, I think we could use some nice sequence diagrams in the 
> > > spec!
> > >
> > >
> > > > accept grab only from the side that currently has keyboard focus,
> > > > this means:
> > > > (1

Re: [Spice-devel] [PATCH spice-gtk 1/3] clipboard: accept grab only from the side with keyboard focus

[Jakub Janku]

Hi again,

On Fri, Mar 8, 2019 at 4:00 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Fri, Mar 8, 2019 at 1:41 PM Jakub Janku  wrote:
> >
> > Hi,
> >
> > On Fri, Mar 8, 2019 at 1:15 PM Marc-André Lureau
> >  wrote:
> > >
> > > Hi
> > >
> > > On Thu, Mar 7, 2019 at 10:36 PM Jakub Janku  wrote:
> > > >
> > > > Hi,
> > > >
> > > > thanks for having a look!
> > > >
> > > > On Wed, Mar 6, 2019 at 6:42 PM Marc-André Lureau
> > > >  wrote:
> > > > >
> > > > > Hi
> > > > >
> > > > > On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků  wrote:
> > > > > >
> > > > > > If two grab messages in opposite directions "meet" on their way
> > > > > > to their destinations, we end up in a state when both spice-gtk
> > > > > > and spice-vdagent think that the other component can provide
> > > > > > clipboard data. As a consequence of this, neither of them can.
> > > > > >
> > > > > > This is a bug in the spice-protocol. To mitigate the issue,
> > > > >
> > > > > With such as statement, you should provide detailed analysis, and
> > > > > strong arguments for workarounds.
> > > >
> > > > Depends on what you consider to be "detailed analysis". Since you
> > > > correctly restated the problem with your own words, it seems like my
> > > > rather short description served its purpose :)
> > > > Also please note that I've tried to provide a more detailed analysis
> > > > of the issue reported by James Harvey earlier in [0]
> > > >
> > > > [0] 
> > > > https://lists.freedesktop.org/archives/spice-devel/2019-January/047614.html
> > > >
> > > > As for the arguments, I've actually expressed my main argument in the
> > > > cover letter, have you read it?
> > > > "Intention of these patches is to make spice-gtk
> > > > behave reasonably well with older agents."
> > > > I would like to have this patch reviewed with this in mind.
> > > > So this patch NOT trying to be a final solution to the problem.
> > > >
> > > > If you look at the race condition from the standpoint of spice-gtk,
> > > > the situation looks the following:
> > > > 1) spice-gtk sends grab
> > > > 2) spice-gtk receives grab
> > > > You can't tell if it's a race or not. The normal behaviour can look the 
> > > > same.
> > > >
> > > > Now, if you consider fix in spice-gtk only (to make older vdagents
> > > > play nicely with new spice-gtk), I see these possible mitigations:
> > > > a) measure time between 1) and 2) and discard one grab if the elapsed
> > > > time is too short:
> > > > this solution is rather empirical and seems unreliable to me
> > > > b) accept grab only from one side at a moment - that is what this patch 
> > > > does
> > > >
> > > > >
> > > > > I think you are describing this conflicting situation: (all messages
> > > > > are asynchronous here, A & B are either client or remote end
> > > > > interchangeably)
> > > > >
> > > > > A->B: grab
> > > > > B->A: grab
> > > > > A: handle B grab
> > > > > B: handle A grab
> > > > >
> > > > > Both A&B think the other end has the grab...
> > > > >
> > > > > If we would instead explicitly release the grab, none would have it,
> > > > > which could be considered an improvement:
> > > >
> > > > Yes, a slight improvement. However, the original grabs both in client
> > > > and guest would be lost, which is unwanted.
> > > > >
> > > > > A->B: grab
> > > > > B->A: grab
> > > > > A: handle B grab
> > > > > A->B: release
> > > > > B: handle A grab
> > > > > B->A: release
> > > > > B: handle A release
> > > > > A: handle B release
> > > > >
> > > > > Instead, we should probably have a priority for who wins. I suppose it
> > > > > should be the client.
> > > >
> > > > Not necessarily. Consider James' case: if we make the client win, the
> > > >

Re: [Spice-devel] [PATCH spice-gtk 1/3] clipboard: accept grab only from the side with keyboard focus

[Jakub Janku]

Hi,

On Thu, Mar 14, 2019 at 6:18 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků  wrote:
> >
> > If two grab messages in opposite directions "meet" on their way
> > to their destinations, we end up in a state when both spice-gtk
> > and spice-vdagent think that the other component can provide
> > clipboard data. As a consequence of this, neither of them can.
> >
> > This is a bug in the spice-protocol. To mitigate the issue,
> > accept grab only from the side that currently has keyboard focus,
> > this means:
> > (1) spice-gtk has focus ==>
> > * accept grabs from vdagent,
> > * ignore grabs from other apps running in the host
> > (2) spice-gtk doesn't have focus ==>
> > * accept grabs from other apps running in the host
> > * ignore grabs from vdagent
> >
> > The check in clipboard_owner_change() is X11-specific,
> > because on Wayland, spice-gtk is first notified about the
> > owner-change once it gains focus.
> >
> > The check in clipboard_grab() can be generic.
> > Note that on Wayland, calling gtk_clipboard_set_with_owner()
> > while not having focus doesn't have any effect anyway,
> > only focused clients can set clipboard.
> >
> > With this patch, the race can still occur around the time
> > when focus changes (rare, but possible), on X11 as well as Wayland.
> >
> > Related: https://gitlab.freedesktop.org/spice/spice-gtk/issues/82
> > Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
> >
> > Signed-off-by: Jakub Janků 
> > ---
> >
> > Victor, half of this patch is basically yours,
> > so feel free to add signed-off or something,
> > in the case this gets upstream :)
> >
> > ---
> >  src/spice-gtk-session.c | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > index b48f92a..7b7370c 100644
> > --- a/src/spice-gtk-session.c
> > +++ b/src/spice-gtk-session.c
> > @@ -680,6 +680,13 @@ static void clipboard_owner_change(GtkClipboard
> > *clipboard,
> >  s->clip_hasdata[selection] = FALSE;
> >  return;
> >  }
> > +
> > +if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
> > +spice_gtk_session_get_keyboard_has_focus(self)) {
> > +SPICE_DEBUG("%s: spice-gtk has keyboard focus, "
> > +"ignoring grab from other app", __FUNCTION__);
> > +return;
> > +}
> >  #endif
>
> This will break clipboard managers interactions, which may take the
> clipboard content, save it and/or modify it.

Depends on the implementation of the given clipboard manager, I'd say.
I tried the "clipboard indicator" you're using. Seems like no problem there :)
>
> >
> >  s->clip_hasdata[selection] = TRUE;
> > @@ -823,6 +830,12 @@ static gboolean clipboard_grab(SpiceMainChannel *main, 
> > guint selection,
> >  cb = get_clipboard_from_selection(s, selection);
> >  g_return_val_if_fail(cb != NULL, FALSE);
> >
> > +if (!spice_gtk_session_get_keyboard_has_focus(self)) {
> > +SPICE_DEBUG("%s: spice-gtk doesn't have keyboard focus, "
> > +"ignoring grab from guest agent", __FUNCTION__);
> > +return FALSE;
> > +}
>
>
> Beside automation, the cursor alone may easily create a new clipboard
> content which won't be available to the client side (the auto-grab may
> fail to follow cursor etc).
>
> It's a bit unclear why it's not X11 specific but for client side
> change it is, this could deserve a code comment.

Tried to describe that in the commit log. I could add a comment in the
code as well.
>
> All in all, this feels weak and breaks some legitimate cases.
>
> I am not very strongly against this, as I understand it may help with
> some races we discussed,

Is this an ack or nack?
Seems like we're just going round in circles now...

> but it feels like the problem is elsewhere

sorry, but that's very vague, I have no idea what you're referring to

> and we need a better solution to prevent the race from happening.
>
> I haven't read the bug reports: this kind of workaround needs a
> description of a broken use case (not a theoretical description of a
> race that "never" happen in practice).

I described a broken case in the previous email:
KDE with klipper, "prevent empty clipboard" enabled + slow network

Cheers,
Jakub

>
>
> > +
> >  for (n = 0; n < ntypes; ++n) {
> >  found = FALSE;
> >  for (m = 0; m < SPICE_N_ELEMENTS(atom2agent); m++) {
> > --
> > 2.20.1
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
> --
> Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk 1/3] clipboard: accept grab only from the side with keyboard focus

[Jakub Janku]

Hey,

On Fri, Mar 15, 2019 at 8:02 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Fri, Mar 15, 2019 at 4:43 PM Jakub Janku  wrote:
> >
> > Hi,
> >
> > On Thu, Mar 14, 2019 at 6:18 PM Marc-André Lureau
> >  wrote:
> > >
> > > Hi
> > >
> > > On Thu, Feb 28, 2019 at 8:12 PM Jakub Janků  wrote:
> > > >
> > > > If two grab messages in opposite directions "meet" on their way
> > > > to their destinations, we end up in a state when both spice-gtk
> > > > and spice-vdagent think that the other component can provide
> > > > clipboard data. As a consequence of this, neither of them can.
> > > >
> > > > This is a bug in the spice-protocol. To mitigate the issue,
> > > > accept grab only from the side that currently has keyboard focus,
> > > > this means:
> > > > (1) spice-gtk has focus ==>
> > > > * accept grabs from vdagent,
> > > > * ignore grabs from other apps running in the host
> > > > (2) spice-gtk doesn't have focus ==>
> > > > * accept grabs from other apps running in the host
> > > > * ignore grabs from vdagent
> > > >
> > > > The check in clipboard_owner_change() is X11-specific,
> > > > because on Wayland, spice-gtk is first notified about the
> > > > owner-change once it gains focus.
> > > >
> > > > The check in clipboard_grab() can be generic.
> > > > Note that on Wayland, calling gtk_clipboard_set_with_owner()
> > > > while not having focus doesn't have any effect anyway,
> > > > only focused clients can set clipboard.
> > > >
> > > > With this patch, the race can still occur around the time
> > > > when focus changes (rare, but possible), on X11 as well as Wayland.
> > > >
> > > > Related: https://gitlab.freedesktop.org/spice/spice-gtk/issues/82
> > > > Related: https://bugzilla.redhat.com/show_bug.cgi?id=1594876
> > > >
> > > > Signed-off-by: Jakub Janků 
> > > > ---
> > > >
> > > > Victor, half of this patch is basically yours,
> > > > so feel free to add signed-off or something,
> > > > in the case this gets upstream :)
> > > >
> > > > ---
> > > >  src/spice-gtk-session.c | 13 +
> > > >  1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > > index b48f92a..7b7370c 100644
> > > > --- a/src/spice-gtk-session.c
> > > > +++ b/src/spice-gtk-session.c
> > > > @@ -680,6 +680,13 @@ static void clipboard_owner_change(GtkClipboard
> > > > *clipboard,
> > > >  s->clip_hasdata[selection] = FALSE;
> > > >  return;
> > > >  }
> > > > +
> > > > +if (GDK_IS_X11_DISPLAY(gdk_display_get_default()) &&
> > > > +spice_gtk_session_get_keyboard_has_focus(self)) {
> > > > +SPICE_DEBUG("%s: spice-gtk has keyboard focus, "
> > > > +"ignoring grab from other app", __FUNCTION__);
> > > > +return;
> > > > +}
> > > >  #endif
> > >
> > > This will break clipboard managers interactions, which may take the
> > > clipboard content, save it and/or modify it.
> >
> > Depends on the implementation of the given clipboard manager, I'd say.
> > I tried the "clipboard indicator" you're using. Seems like no problem there 
> > :)
>
> without, and with that patch I suppose

Sure
>
> > >
> > > >
> > > >  s->clip_hasdata[selection] = TRUE;
> > > > @@ -823,6 +830,12 @@ static gboolean clipboard_grab(SpiceMainChannel 
> > > > *main, guint selection,
> > > >  cb = get_clipboard_from_selection(s, selection);
> > > >  g_return_val_if_fail(cb != NULL, FALSE);
> > > >
> > > > +if (!spice_gtk_session_get_keyboard_has_focus(self)) {
> > > > +SPICE_DEBUG("%s: spice-gtk doesn't have keyboard focus, "
> > > > +"ignoring grab from guest agent", __FUNCTION__);
> > > > +return FALSE;
> > > > +}
> > >
> > >
> > > Beside automation, the cursor alone may easily create a new clipboard
> > > content which won't 

Re: [Spice-devel] [PATCH linux/vd-agent 06/11] configure: bump gobject >= 2.50

[Jakub Janku]

Hi,

On Fri, Mar 22, 2019 at 4:13 PM  wrote:
>
> From: Marc-André Lureau 
>
> This is required for using the new GObject macros.

Which macros are you referring to?
G_DECLARE_FINAL_TYPE is available since 2.44
>
> According to commit 61fc548fe1a323dd2344c8ae267e3ce05e86da7d ("Bump
> GLib version to 2.34"), RHEL6 is no longer supported.
>
> GLib version across some distributions, from repology:
> - Debian Stable (9): 2.50.3
> - CentOS 7: 2.56.1
> - Fedora 26: 2.52.3 (fwiw, Fedora 30: 2.60.0)
>
> Signed-off-by: Marc-André Lureau 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index fb0675f..9808f58 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -100,7 +100,7 @@ AC_ARG_ENABLE([static-uinput],
>[enable_static_uinput="$enableval"],
>[enable_static_uinput="no"])
>
> -PKG_CHECK_MODULES([GOBJECT], [gobject-2.0 >= 2.34])
> +PKG_CHECK_MODULES([GOBJECT], [gobject-2.0 >= 2.50])

You could bump glib version as well

>  PKG_CHECK_MODULES(X, [xfixes xrandr >= 1.3 xinerama x11])
>  PKG_CHECK_MODULES(SPICE, [spice-protocol >= 0.12.16])
>  PKG_CHECK_MODULES(ALSA, [alsa >= 1.0.22])
> --
> 2.21.0.4.g36eb1cb9cf
>

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

Re: [Spice-devel] [PATCH spice-protocol 3/3] vdagent: introduce VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL

[Jakub Janku]

On Fri, Mar 22, 2019 at 2:57 PM  wrote:
>
> From: Marc-André Lureau 
>
> When this capability is negoticated by both the client & the agent,
> the clipboard grab messages have an associated serial counter.
>
> The serial is reset to 0 upon client connection.
>
> The counter is increment by 1 on each grab message, by both sides.
>
> The sender of the message with the highest serial should be the
> clipboard grab owner, and the current session serial should be
> updated.
>
> If a lower serial than the current session serial is received, the
> grab should be discarded.
>
> Whenever two grabs share the same serial, the one coming from the
> client should have a higher priority and the client should gain the
> clipboard ownership.

Why should the client be the one with a higher priority?

If you look at James' case again:
with you proposed change, the clipboard manager would take over if a
race occurs, but the clipboard manager usually supports only a limited
number of targets.
For example, you copy a graph in Excel, (regrab and race occurs),
clipboard manager from the client wins and sets the clipboard, now
you're able to paste the graph only as a non-editable image.

So to provide an "uninterrupted" experience, I think that the
component with keyboard focus should actually get the priority.
>
> No special treatement is done for the unlikely case of overflowing the
> counter. It may temporarily inverse the priority, until both side have
> overflown and/or synchronized.
>
> Note: this mechanism isn't aiming at making "the most recent" (as in
> time) side gaining the ownership. One side sending subsequent grab
> messages earlier will likely take the ownership over a side sending a
> single message simultaneously the other way. It only clears the
> situation where both side believe that the other is the current
> clipboard owner, by having a global ordering and priority in case of
> serial conflict.
>
> Signed-off-by: Marc-André Lureau 
> ---
>  spice/vd_agent.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/spice/vd_agent.h b/spice/vd_agent.h
> index 862cb5c..9ae3cc7 100644
> --- a/spice/vd_agent.h
> +++ b/spice/vd_agent.h
> @@ -218,6 +218,9 @@ typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
>  #if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
>  uint8_t selection;
>  uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> +#endif
> +#if 0 /* VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL */
> +uint32_t serial;
>  #endif
>  uint32_t types[0];
>  } VDAgentClipboardGrab;
> @@ -288,6 +291,7 @@ enum {
>  VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS,
>  VD_AGENT_CAP_GRAPHICS_DEVICE_INFO,
>  VD_AGENT_CAP_CLIPBOARD_NO_RELEASE_ON_REGRAB,
> +VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL,
>  VD_AGENT_END_CAP,
>  };
>
> --
> 2.21.0.4.g36eb1cb9cf
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk 2/2] clipboard: do not release between remote grabs

[Jakub Janku]

Hi,

On Thu, Mar 21, 2019 at 1:21 PM  wrote:
>
> From: Marc-André Lureau 
>
> Delay the release events for 0.5 sec. If no further grab comes in,
> then release the grab. Otherwise, let's skip the release. This avoids
> some races with clipboard managers.
>
> Related to:
> https://gitlab.freedesktop.org/spice/spice-gtk/issues/82
>
> Signed-off-by: Marc-André Lureau 

In the 0.5 second period, any requests from apps in the client for
clipboard data should be ignored since the vdagent can't provide the
data any more, so we shouldn't request it.
So I would add a condition to clipboard_get():
if (s->clipboard_release_delay[selection]) {
SPICE_DEBUG("...");
return;
}
> ---
>  src/spice-gtk-session.c | 80 -
>  1 file changed, 72 insertions(+), 8 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 0e748b6..d73a44b 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -59,6 +59,7 @@ struct _SpiceGtkSessionPrivate {
>  gbooleanclip_hasdata[CLIPBOARD_LAST];
>  gbooleanclip_grabbed[CLIPBOARD_LAST];
>  gbooleanclipboard_by_guest[CLIPBOARD_LAST];
> +guint   clipboard_release_delay[CLIPBOARD_LAST];
>  /* auto-usbredir related */
>  gbooleanauto_usbredir_enable;
>  int auto_usbredir_reqs;
> @@ -95,6 +96,7 @@ struct _SpiceGtkSessionPrivate {
>
>  /* -- */
>  /* Prototypes for private functions */
> +static void clipboard_release(SpiceGtkSession *self, guint selection);
>  static void clipboard_owner_change(GtkClipboard *clipboard,
> GdkEventOwnerChange *event,
> gpointer user_data);
> @@ -247,6 +249,23 @@ static void spice_gtk_session_dispose(GObject *gobject)
>  G_OBJECT_CLASS(spice_gtk_session_parent_class)->dispose(gobject);
>  }
>
> +static void clipboard_release_delay_remove(SpiceGtkSession *self, guint 
> selection,
> +   gboolean release_if_delayed)
> +{
> +SpiceGtkSessionPrivate *s = self->priv;
> +
> +if (!s->clipboard_release_delay[selection])
> +return;
> +
> +if (release_if_delayed) {
> +SPICE_DEBUG("delayed clipboard release, sel:%u", selection);
> +clipboard_release(self, selection);
> +}
> +
> +g_source_remove(s->clipboard_release_delay[selection]);
> +s->clipboard_release_delay[selection] = 0;
> +}
> +
>  static void spice_gtk_session_finalize(GObject *gobject)
>  {
>  SpiceGtkSession *self = SPICE_GTK_SESSION(gobject);
> @@ -256,6 +275,7 @@ static void spice_gtk_session_finalize(GObject *gobject)
>  /* release stuff */
>  for (i = 0; i < CLIPBOARD_LAST; ++i) {
>  g_clear_pointer(&s->clip_targets[i], g_free);
> +clipboard_release_delay_remove(self, i, true);
>  }
>
>  /* Chain up to the parent class */
> @@ -815,6 +835,8 @@ static gboolean clipboard_grab(SpiceMainChannel *main, 
> guint selection,
>  int m, n;
>  int num_targets = 0;
>
> +clipboard_release_delay_remove(self, selection, false);
> +
>  cb = get_clipboard_from_selection(s, selection);
>  g_return_val_if_fail(cb != NULL, FALSE);
>
> @@ -1044,17 +1066,12 @@ static gboolean clipboard_request(SpiceMainChannel 
> *main, guint selection,
>  return TRUE;
>  }
>
> -static void clipboard_release(SpiceMainChannel *main, guint selection,
> -  gpointer user_data)
> +static void clipboard_release(SpiceGtkSession *self, guint selection)
>  {
> -g_return_if_fail(SPICE_IS_GTK_SESSION(user_data));
> -
> -SpiceGtkSession *self = user_data;
>  SpiceGtkSessionPrivate *s = self->priv;
>  GtkClipboard* clipboard = get_clipboard_from_selection(s, selection);
>
> -if (!clipboard)
> -return;
> +g_return_if_fail(clipboard != NULL);
>
>  s->nclip_targets[selection] = 0;
>
> @@ -1064,6 +1081,53 @@ static void clipboard_release(SpiceMainChannel *main, 
> guint selection,
>  s->clipboard_by_guest[selection] = FALSE;
>  }
>
> +typedef struct SpiceGtkClipboardRelease {
> +SpiceGtkSession *self;
> +guint selection;
> +} SpiceGtkClipboardRelease;
> +
> +static gboolean clipboard_release_timeout(gpointer user_data)
> +{
> +SpiceGtkClipboardRelease *rel = user_data;
> +
> +clipboard_release_delay_remove(rel->self, rel->selection, true);
> +
> +return G_SOURCE_REMOVE;
> +}
> +
> +/*
> + * The agents send release between two grabs. This may trigger
> + * clipboard managers trying to grab the clipboard. We end up with two
> + * sides, client and remote, racing for the clipboard grab, and
> + * believing each other is the owner.
> + *
> + * Workaround this problem by delaying the release event by 0.5 sec.
> + * FIXME: protocol change to solve the conflict and set c

Re: [Spice-devel] [PATCH spice-gtk 1/2] clipboard: do not release between client grabs

[Jakub Janku]

Hi,

On Thu, Mar 21, 2019 at 1:21 PM  wrote:
>
> From: Marc-André Lureau 
>
> On the client side, whenever the grab owner changes (and the clipboard
> was previously grabbed), spice-gtk sends a clipboard release followed
> immediately by a new grab. But some clipboard managers on the remote
> side react to clipboard release events by taking a clipboard grab,
> presumably to avoid empty clipboards.
>
> The two grabs, coming from the client and from the remote sides, will
> race in both directions, which may confuse the client & remote side,
> as both believe the other side is the current grab owner, and thus
> further clipboard data requests are likely to fail.
>
> Let's avoid sending a release event when re-grabing.
>
> The race described above may still happen in other rare circunstances,
> and will require a protocol change. To avoid the conflict, a discussed
> solution could use a clipboard serial number.
>
> Tested with current linux & windows vdagent. Looking at earlier
> version of the code, it doesn't seem like subsequent grabs will be
> treated as an error.
>
> Signed-off-by: Marc-André Lureau 
> ---
>  src/spice-gtk-session.c | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index b48f92a..0e748b6 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -569,8 +569,7 @@ static void clipboard_get_targets(GtkClipboard *clipboard,
>  g_return_if_fail(selection != -1);
>
>  if (s->clip_grabbed[selection]) {
> -SPICE_DEBUG("Clipboard is already grabbed, ignoring %d atoms", 
> n_atoms);
> -return;
> +SPICE_DEBUG("Clipboard is already grabbed, re-grab: %d atoms", 
> n_atoms);
>  }
>
>  /* Set all Atoms that matches our current protocol implementation */
> @@ -652,18 +651,14 @@ static void clipboard_owner_change(GtkClipboard
> *clipboard,
>  return;
>  }
>
> -/* In case we sent a grab to the agent, we need to release it now as
> - * previous clipboard data should not be reachable anymore */
> -if (s->clip_grabbed[selection]) {
> -s->clip_grabbed[selection] = FALSE;
> -if (spice_main_channel_agent_test_capability(s->main, 
> VD_AGENT_CAP_CLIPBOARD_BY_DEMAND)) {
> -spice_main_channel_clipboard_selection_release(s->main, 
> selection);
> -}
> -}

If event->owner is NULL, the clipboard is empty at the moment and this
function exits without requesting the new targets. So in this case, we
should still send release to the agent, otherwise the guest might
think that clipboard data can be provided while the clipboard in the
client is empty for a long time. Pasting data in the guest would
result into an invalid request being sent to spice-gtk.
> -
> -/* We are mostly interested when owner has changed in which case
> - * we would like to let agent know about new clipboard data. */
>  if (event->reason != GDK_OWNER_CHANGE_NEW_OWNER) {
> +if (s->clip_grabbed[selection]) {
> +/* grab was sent to the agent, so release it */
> +s->clip_grabbed[selection] = FALSE;
> +if (spice_main_channel_agent_test_capability(s->main, 
> VD_AGENT_CAP_CLIPBOARD_BY_DEMAND)) {
> +spice_main_channel_clipboard_selection_release(s->main, 
> selection);
> +}
> +}
>  s->clip_hasdata[selection] = FALSE;
>  return;
>  }
> --
> 2.21.0.4.g36eb1cb9cf
>

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

Re: [Spice-devel] [PATCH spice-gtk 0/2] clipboard: skip release between grabs

[Jakub Janku]

Hi,

On Fri, Mar 22, 2019 at 10:15 AM Victor Toso  wrote:
>
> Hi James,
>
> If you have the time, could you give this a try?

CC-ing James
>
> Cheers,
>
> On Thu, Mar 21, 2019 at 01:21:32PM +0100, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau 
> >
> > Hi,
> >
> > There has been several reports of clipboard issues that seem related
> > to clipboard managers interactions. Although it's not crystal clear
> > what are the problems,

Hmmm. What's left to be cleared?

>> we realized the spice protocol does't handle
> > well conflicting grabs coming simultaneously from client and remote.
> > Each other believe the other side is the owner. This situation
> > is rare, but with a clipboard manager that reacts to release events,
> > it may be more easily reproducible.
> >
> > Both agent & client send release between grabs today. This series
> > propose to stop releasing between grabs on client side, and adds a
> > 0.5s delay for the release event coming from the agent side, to filter
> > out release between grabs.

Delaying the release for 0.5 seconds seems wrong to me. Given it's
just a temporary workaround, I'm fine with it.
But it should be tested by someone who's experienced the issues in the
real world to see if the delay is sufficient and doesn't cause any
other problems.
> >
> > Further protocol improvements should remove the need for a delay, and
> > solve the conflicting situation in all cases. This will come in a
> > future series.
> >
> > Marc-André Lureau (2):
> >   clipboard: do not release between client grabs
> >   clipboard: do not release between remote grabs
> >
> >  src/spice-gtk-session.c | 101 +++-
> >  1 file changed, 80 insertions(+), 21 deletions(-)
> >
> > --
> > 2.21.0.4.g36eb1cb9cf
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel

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

Re: [Spice-devel] [PATCH linux/vd-agent 02/11] session: free active session

[Jakub Janku]

On Fri, Mar 22, 2019 at 4:13 PM  wrote:
>
> From: Marc-André Lureau 
>
> According to sd_seat_get_active(2), you must free() the pointer.
>
> Signed-off-by: Marc-André Lureau 
> ---
>  src/vdagentd/systemd-login.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/vdagentd/systemd-login.c b/src/vdagentd/systemd-login.c
> index a11b66d..0b2dd0a 100644
> --- a/src/vdagentd/systemd-login.c
> +++ b/src/vdagentd/systemd-login.c
> @@ -266,6 +266,7 @@ const char *session_info_get_active_session(struct 
> session_info *si)
>  int r;
>  char *old_session = si->session;
>
> +free(si->session);

The session does get freed just a couple of lines below here.

Cheers,
Jakub

>  si->session = NULL;
>  r = sd_seat_get_active("seat0", &si->session, NULL);
>  /* ENOENT happens when a seat is switching from one session to another */
> --
> 2.21.0.4.g36eb1cb9cf
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH linux/vd-agent 08/11] clipboard: gobject-ify VDAgentClipboards

[Jakub Janku]

Hi,

On Mon, Mar 25, 2019, 11:34 AM Marc-André Lureau 
wrote:

> Hi
>
> On Mon, Mar 25, 2019 at 10:26 AM Frediano Ziglio 
> wrote:
> >
> > >
> > > From: Marc-André Lureau 
> > >
> > > This will allow easier lifecycle management,
> > > and usage of gtk_clipboard_set_with_owner()
> > >
> > > Signed-off-by: Marc-André Lureau 
> > > ---
> > >  src/vdagent/clipboard.c | 67 +++--
> > >  src/vdagent/clipboard.h | 12 +---
> > >  src/vdagent/vdagent.c   |  7 +++--
> > >  3 files changed, 56 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/src/vdagent/clipboard.c b/src/vdagent/clipboard.c
> > > index 1e49248..cf6e344 100644
> > > --- a/src/vdagent/clipboard.c
> > > +++ b/src/vdagent/clipboard.c
> > > @@ -76,15 +76,25 @@ typedef struct {
> > >  } Selection;
> > >  #endif
> > >
> > > -struct VDAgentClipboards {
> > > -#ifdef WITH_GTK
> > > +struct _VDAgentClipboards {
> >
> > Can we use C99 complaints identifiers?
>
> I didn't think much about the struct identifiers.
>
> fwiw, glib/gobject/gtk uses "struct _Foo" everywhere.
>

I think it's necessary as long as you want to use the new GObject macro.

G_DECLARE_FINAL_TYPE typedefs VdagentClipboards as struct _VDAgentClipboards
afaik.

Cheers,
Jakub

>
> >
> > > +GObject parent;
> > > +
> > >  struct udscs_connection *conn;
> > > -Selectionselections[SELECTION_COUNT];
> > > +
> > > +#ifdef WITH_GTK
> > > +Selection selections[SELECTION_COUNT];
> > >  #else
> > >  struct vdagent_x11 *x11;
> > >  #endif
> > >  };
> > >
> > > +struct _VDAgentClipboardsClass
> > > +{
> >
> > 2 structure style declaration in one patch
>
> Hmm? are you talking about braces indentation here?
>
> >
> > > +GObjectClass parent;
> > > +};
> > > +
> > > +G_DEFINE_TYPE(VDAgentClipboards, vdagent_clipboards, G_TYPE_OBJECT)
> > > +
> > >  #ifdef WITH_GTK
> > >  static const struct {
> > >  guint type;
> > > @@ -453,43 +463,56 @@ err:
> > >  #endif
> > >  }
> > >
> > > -VDAgentClipboards *vdagent_clipboards_init(struct vdagent_x11
> *x11,
> > > -   struct udscs_connection
> *conn)
> > > +static void
> > > +vdagent_clipboards_init(VDAgentClipboards *self)
> > >  {
> > > -#ifdef WITH_GTK
> > > -guint sel_id;
> > > -#endif
> > > +}
> > > +
> > > +VDAgentClipboards *vdagent_clipboards_new(struct vdagent_x11 *x11)
> > > +{
> > > +VDAgentClipboards *self = g_object_new(VDAGENT_TYPE_CLIPBOARDS,
> NULL);
> > >
> > > -VDAgentClipboards *c;
> > > -c = g_new0(VDAgentClipboards, 1);
> > >  #ifndef WITH_GTK
> > > -c->x11 = x11;
> > > +self->x11 = x11;
> > >  #else
> > > -c->conn = conn;
> > > +guint sel_id;
> > >
> > >  for (sel_id = 0; sel_id < SELECTION_COUNT; sel_id++) {
> > >  GtkClipboard *clipboard = gtk_clipboard_get(sel_atom[sel_id]);
> > > -c->selections[sel_id].clipboard = clipboard;
> > > +self->selections[sel_id].clipboard = clipboard;
> > >  g_signal_connect(G_OBJECT(clipboard), "owner-change",
> > > - G_CALLBACK(clipboard_owner_change_cb), c);
> > > + G_CALLBACK(clipboard_owner_change_cb), self);
> > >  }
> > >  #endif
> > >
> > > -return c;
> > > +return self;
> > >  }
> > >
> > > -void vdagent_clipboards_finalize(VDAgentClipboards *c, gboolean
> conn_alive)
> > > +void
> > > +vdagent_clipboards_set_conn(VDAgentClipboards *self, struct
> udscs_connection
> > > *conn)
> > > +{
> > > +self->conn = conn;
> > > +}
> > > +
> > > +static void vdagent_clipboards_dispose(GObject *obj)
> > >  {
> > >  #ifdef WITH_GTK
> > > +VDAgentClipboards *self = VDAGENT_CLIPBOARDS(obj);
> > >  guint sel_id;
> > > +
> > >  for (sel_id = 0; sel_id < SELECTION_COUNT; sel_id++)
> > > -
> > > g_signal_handlers_disconnect_by_func(c->selections[sel_id].clipboard,
> > > -G_CALLBACK(clipboard_owner_change_cb), c);
> > > +
> > >
> g_signal_handlers_disconnect_by_func(self->selections[sel_id].clipboard,
> > > +G_CALLBACK(clipboard_owner_change_cb), self);
> > >
> > > -if (conn_alive == FALSE)
> > > -c->conn = NULL;
> > > -vdagent_clipboards_release_all(c);
> > > +if (self->conn)
> > > +vdagent_clipboards_release_all(self);
> > >  #endif
> > > +}
> > > +
> > > +static void
> > > +vdagent_clipboards_class_init(VDAgentClipboardsClass *klass)
> > > +{
> > > +GObjectClass *oclass = G_OBJECT_CLASS(klass);
> > >
> > > -g_free(c);
> > > +oclass->dispose = vdagent_clipboards_dispose;
> > >  }
> > > diff --git a/src/vdagent/clipboard.h b/src/vdagent/clipboard.h
> > > index f819b49..cd8eacb 100644
> > > --- a/src/vdagent/clipboard.h
> > > +++ b/src/vdagent/clipboard.h
> > > @@ -19,16 +19,18 @@
> > >  #ifndef __VDAGENT_CLIPBOARD_H
> > >  #define __VDAGENT_CLIPBOARD_H
> > >
> > > -#include 
> > > +#include 
> > >
> > >  #include "x11.h"
> > >  #include "udscs.h"
> > >
> > > -typedef struct VDAgentClipboard

Re: [Spice-devel] [PATCH spice-gtk 1/2] clipboard: do not release between client grabs

[Jakub Janku]

Hi,

On Sun, Mar 24, 2019 at 7:26 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Sun, Mar 24, 2019 at 6:50 PM Jakub Janku  wrote:
> >
> > Hi,
> >
> > On Thu, Mar 21, 2019 at 1:21 PM  wrote:
> > >
> > > From: Marc-André Lureau 
> > >
> > > On the client side, whenever the grab owner changes (and the clipboard
> > > was previously grabbed), spice-gtk sends a clipboard release followed
> > > immediately by a new grab. But some clipboard managers on the remote
> > > side react to clipboard release events by taking a clipboard grab,
> > > presumably to avoid empty clipboards.
> > >
> > > The two grabs, coming from the client and from the remote sides, will
> > > race in both directions, which may confuse the client & remote side,
> > > as both believe the other side is the current grab owner, and thus
> > > further clipboard data requests are likely to fail.
> > >
> > > Let's avoid sending a release event when re-grabing.
> > >
> > > The race described above may still happen in other rare circunstances,
> > > and will require a protocol change. To avoid the conflict, a discussed
> > > solution could use a clipboard serial number.
> > >
> > > Tested with current linux & windows vdagent. Looking at earlier
> > > version of the code, it doesn't seem like subsequent grabs will be
> > > treated as an error.
> > >
> > > Signed-off-by: Marc-André Lureau 
> > > ---
> > >  src/spice-gtk-session.c | 21 -
> > >  1 file changed, 8 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > index b48f92a..0e748b6 100644
> > > --- a/src/spice-gtk-session.c
> > > +++ b/src/spice-gtk-session.c
> > > @@ -569,8 +569,7 @@ static void clipboard_get_targets(GtkClipboard 
> > > *clipboard,
> > >  g_return_if_fail(selection != -1);
> > >
> > >  if (s->clip_grabbed[selection]) {
> > > -SPICE_DEBUG("Clipboard is already grabbed, ignoring %d atoms", 
> > > n_atoms);
> > > -return;
> > > +SPICE_DEBUG("Clipboard is already grabbed, re-grab: %d atoms", 
> > > n_atoms);
> > >  }
> > >
> > >  /* Set all Atoms that matches our current protocol implementation */
> > > @@ -652,18 +651,14 @@ static void clipboard_owner_change(GtkClipboard 
> > >*clipboard,
> > >  return;
> > >  }
> > >
> > > -/* In case we sent a grab to the agent, we need to release it now as
> > > - * previous clipboard data should not be reachable anymore */
> > > -if (s->clip_grabbed[selection]) {
> > > -s->clip_grabbed[selection] = FALSE;
> > > -if (spice_main_channel_agent_test_capability(s->main, 
> > > VD_AGENT_CAP_CLIPBOARD_BY_DEMAND)) {
> > > -spice_main_channel_clipboard_selection_release(s->main, 
> > > selection);
> > > -}
> > > -}
> >
> > If event->owner is NULL, the clipboard is empty at the moment and this
> > function exits without requesting the new targets. So in this case, we
> > should still send release to the agent, otherwise the guest might
> > think that clipboard data can be provided while the clipboard in the
> > client is empty for a long time. Pasting data in the guest would
> > result into an invalid request being sent to spice-gtk.
>
> This is going into undocumented territories. But if what you say is
> true in commit 9af2c481b74077ab7d6cb9d4bf589f9855a302f5, then yes,
> client should probably release the clipboard.
>
> I don't quite understand why gtk+ would allow NEW_OWNER, with owner ==
> NULL and empty clipboard. It sounds more like a bug to me.

Well, in vdagent we release the clipboard with the following call:
XSetSelectionOwner(x11->display, clip, None, CurrentTime);
So it seems completely fine to me that we get a GdkEventOwnerChange
with reason NEW_OWNER and owner set to NULL. I don't think it's a bug.
>
> Would this be enough ?

Sure.

Cheers,
Jakub
>
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 5b2c27c..3dbcae6 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -671,7 +671,11 @@ static void clipboard_owner_change(GtkClipboard
>  *clipboard,
>  return;
>  }
>
> -if (event->reason != GDK_OWNER_CHANGE_NEW_OWNER) {
> +if (event->

Re: [Spice-devel] [PATCH spice-gtk 2/2] clipboard: do not release between remote grabs

[Jakub Janku]

Hi,

On Sun, Mar 24, 2019 at 7:45 PM Marc-André Lureau <
marcandre.lur...@gmail.com> wrote:
>
> Hi
>
> On Sun, Mar 24, 2019 at 6:49 PM Jakub Janku  wrote:
> >
> > Hi,
> >
> > On Thu, Mar 21, 2019 at 1:21 PM  wrote:
> > >
> > > From: Marc-André Lureau 
> > >
> > > Delay the release events for 0.5 sec. If no further grab comes in,
> > > then release the grab. Otherwise, let's skip the release. This avoids
> > > some races with clipboard managers.
> > >
> > > Related to:
> > > https://gitlab.freedesktop.org/spice/spice-gtk/issues/82
> > >
> > > Signed-off-by: Marc-André Lureau 
> >
> > In the 0.5 second period, any requests from apps in the client for
> > clipboard data should be ignored since the vdagent can't provide the
> > data any more, so we shouldn't request it.
> > So I would add a condition to clipboard_get():
> > if (s->clipboard_release_delay[selection]) {
> > SPICE_DEBUG("...");
> > return;
> > }
>
> yes, thanks
>
> > > ---
> > >  src/spice-gtk-session.c | 80
-
> > >  1 file changed, 72 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> > > index 0e748b6..d73a44b 100644
> > > --- a/src/spice-gtk-session.c
> > > +++ b/src/spice-gtk-session.c
> > > @@ -59,6 +59,7 @@ struct _SpiceGtkSessionPrivate {
> > >  gbooleanclip_hasdata[CLIPBOARD_LAST];
> > >  gbooleanclip_grabbed[CLIPBOARD_LAST];
> > >  gbooleanclipboard_by_guest[CLIPBOARD_LAST];
> > > +guint   clipboard_release_delay[CLIPBOARD_LAST];
> > >  /* auto-usbredir related */
> > >  gbooleanauto_usbredir_enable;
> > >  int auto_usbredir_reqs;
> > > @@ -95,6 +96,7 @@ struct _SpiceGtkSessionPrivate {
> > >
> > >  /*
-- */
> > >  /* Prototypes for private functions */
> > > +static void clipboard_release(SpiceGtkSession *self, guint
selection);
> > >  static void clipboard_owner_change(GtkClipboard *clipboard,
> > > GdkEventOwnerChange *event,
> > > gpointer user_data);
> > > @@ -247,6 +249,23 @@ static void spice_gtk_session_dispose(GObject
*gobject)
> > >
G_OBJECT_CLASS(spice_gtk_session_parent_class)->dispose(gobject);
> > >  }
> > >
> > > +static void clipboard_release_delay_remove(SpiceGtkSession *self,
guint selection,
> > > +   gboolean
release_if_delayed)
> > > +{
> > > +SpiceGtkSessionPrivate *s = self->priv;
> > > +
> > > +if (!s->clipboard_release_delay[selection])
> > > +return;
> > > +
> > > +if (release_if_delayed) {
> > > +SPICE_DEBUG("delayed clipboard release, sel:%u", selection);
> > > +clipboard_release(self, selection);
> > > +}
> > > +
> > > +g_source_remove(s->clipboard_release_delay[selection]);
> > > +s->clipboard_release_delay[selection] = 0;
> > > +}
> > > +
> > >  static void spice_gtk_session_finalize(GObject *gobject)
> > >  {
> > >  SpiceGtkSession *self = SPICE_GTK_SESSION(gobject);
> > > @@ -256,6 +275,7 @@ static void spice_gtk_session_finalize(GObject
*gobject)
> > >  /* release stuff */
> > >  for (i = 0; i < CLIPBOARD_LAST; ++i) {
> > >  g_clear_pointer(&s->clip_targets[i], g_free);
> > > +clipboard_release_delay_remove(self, i, true);
> > >  }
> > >
> > >  /* Chain up to the parent class */
> > > @@ -815,6 +835,8 @@ static gboolean clipboard_grab(SpiceMainChannel
*main, guint selection,
> > >  int m, n;
> > >  int num_targets = 0;
> > >
> > > +clipboard_release_delay_remove(self, selection, false);
> > > +
> > >  cb = get_clipboard_from_selection(s, selection);
> > >  g_return_val_if_fail(cb != NULL, FALSE);
> > >
> > > @@ -1044,17 +1066,12 @@ static gboolean
clipboard_request(SpiceMainChannel *main, guint selection,
> > >  return TRUE;
> > >  }
> > >
> > > -static void clipboard_release(SpiceMa

Re: [Spice-devel] [PATCH spice-protocol 3/3] vdagent: introduce VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL

[Jakub Janku]

Hi,

On Sun, Mar 24, 2019 at 7:40 PM Marc-André Lureau
 wrote:
>
> Hi
>
> On Sun, Mar 24, 2019 at 6:49 PM Jakub Janku  wrote:
> >
> > On Fri, Mar 22, 2019 at 2:57 PM  wrote:
> > >
> > > From: Marc-André Lureau 
> > >
> > > When this capability is negoticated by both the client & the agent,
> > > the clipboard grab messages have an associated serial counter.
> > >
> > > The serial is reset to 0 upon client connection.
> > >
> > > The counter is increment by 1 on each grab message, by both sides.
> > >
> > > The sender of the message with the highest serial should be the
> > > clipboard grab owner, and the current session serial should be
> > > updated.
> > >
> > > If a lower serial than the current session serial is received, the
> > > grab should be discarded.
> > >
> > > Whenever two grabs share the same serial, the one coming from the
> > > client should have a higher priority and the client should gain the
> > > clipboard ownership.
> >
> > Why should the client be the one with a higher priority?
>
> No strong reason, there has to be a winner in this case: both side are
> taking the grab simultaneously, we have to decide which one actually
> holds it in the end.  Other ideas?

As I said - depending on the keyboard focus. However, this would
probably further complicate the protocol and so I have doubts whether
it's worth it, since this already handles a rather uncommon scenario.
Would love to hear opinions on who should be the "winner" in this case
from others too.

Apart from that, would be great if James tested it to see how his
environment behaves with these patches.
>
> >
> > If you look at James' case again:
> > with you proposed change, the clipboard manager would take over if a
> > race occurs, but the clipboard manager usually supports only a limited
> > number of targets.
> > For example, you copy a graph in Excel, (regrab and race occurs),
> > clipboard manager from the client wins and sets the clipboard, now
> > you're able to paste the graph only as a non-editable image.
>
> If there is a clipboard manager on the client side, it's the client
> desire to do such transformation, isn't it?

That's hard to say. I can imagine it could confuse some users while
others would appreciate it (e.g. in the case when they'd run some
automation systems in the client).
>
> >
> > So to provide an "uninterrupted" experience, I think that the
> > component with keyboard focus should actually get the priority.
>
> You are working against the clipboard manager in this case, which may
> do as much harm as good.

Correct, but you can still run another clipboard manager in the guest system.
>
> > >
> > > No special treatement is done for the unlikely case of overflowing the
> > > counter. It may temporarily inverse the priority, until both side have
> > > overflown and/or synchronized.
> > >
> > > Note: this mechanism isn't aiming at making "the most recent" (as in
> > > time) side gaining the ownership. One side sending subsequent grab
> > > messages earlier will likely take the ownership over a side sending a
> > > single message simultaneously the other way. It only clears the
> > > situation where both side believe that the other is the current
> > > clipboard owner, by having a global ordering and priority in case of
> > > serial conflict.
> > >
> > > Signed-off-by: Marc-André Lureau 
> > > ---
> > >  spice/vd_agent.h | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/spice/vd_agent.h b/spice/vd_agent.h
> > > index 862cb5c..9ae3cc7 100644
> > > --- a/spice/vd_agent.h
> > > +++ b/spice/vd_agent.h
> > > @@ -218,6 +218,9 @@ typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab 
> > > {
> > >  #if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
> > >  uint8_t selection;
> > >  uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> > > +#endif
> > > +#if 0 /* VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL */
> > > +uint32_t serial;
> > >  #endif
> > >  uint32_t types[0];
> > >  } VDAgentClipboardGrab;
> > > @@ -288,6 +291,7 @@ enum {
> > >  VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS,
> > >  VD_AGENT_CAP_GRAPHICS_DEVICE_INFO,
> > >  VD_AGENT_CAP_CLIPBOARD_NO_RELEASE_ON_REGRAB,
> > > +VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL,
> > >  VD_AGENT_END_CAP,
> > >  };
> > >
> > > --
> > > 2.21.0.4.g36eb1cb9cf
> > >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
> --
> Marc-André Lureau

Overall, I'm not against this implementation, but testing from someone
who's experienced the issues is a must, imho.

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

Re: [Spice-devel] Working seamless mode

[Jakub Janku]

Hi,

On Sat, Jan 2, 2021 at 9:49 AM Roland Baudin  wrote:
>
> Hi,
>
> perhaps this is not the right place for this request? Could you give me
> some place where I can post this request?

This is the right place, I believe. Alternatively, you could open a
new issue here:
https://gitlab.freedesktop.org/spice/spice-protocol/-/issues

But to be honest, I wouldn't expect anyone to take it up anytime soon.

I don't know how these patches have aged since the time I published them,
but I assume that there will be some issues with Wayland (both on the client
and guest side).

The main problem is probably the design itself.

spice-gkt/virt-viewer shows a single fullscreen window that is
partially transparent
(in the areas where there's no guest window). This results in a poor integration
with the client's system -- what you'd want is to have a new window in
the client for each
window/application on the guest and separate drawing contexts for each app.
The original thread goes into more detail on the issues, I think.

So the patches would probably require a lot of further work, or
complete rewrite.
I would be happy to have this feature as well, but the chances are
imho slim, sorry.

Regards,
Jakub

>
> Thanks a lot,
> RB
>
>
> Le 31/12/2020 à 10:42, Roland Baudin a écrit :
> > Hi there,
> >
> > for my own purpose, I have ported the seamless mode patches written by
> > Jakub Janků, Ondřej Holý and Lukáš Venhoda (see
> > https://www.spinics.net/lists/spice-devel/msg30177.html) to Ubuntu 20.04.
> >
> > I have also hacked the virt-viewer gtk app to allow easily entering
> > and leaving seamless mode. This is a very convenient way to work with
> > the VM in Ubuntu. It's probably not difficult to do the same with
> > virt-manager but alas I'm not a Python programmer.
> >
> > So, I have a set of packages for Ubuntu 20.04 and installation of
> > these packages is very simple. In the Windows VM, it is also required
> > to replace the vdagent and vdservice programs by the patched ones.
> > This is not difficult, but it's a manual process for now.
> >
> > Everything works well (but there are probably issues I didn't see,
> > possibly with multiple screens) and I think this could be a major
> > improvement to the kvm/qemu user experience in Linux.
> >
> > However, I don't have time (and skills) to maintain these packages and
> > patches. I have two other open source projects (Xfe and TexMaths) and
> > a full time job...
> >
> > So, I'm asking here if someone is interestedto get this work and
> > maintain it? I could give you my packages (the patches are in the
> > source packages) and a little explanation to start.
> >
> > I'd be happy if the community could build something useful upon this
> > work.
> >
> > If someone is interested, how can I send the files? Mail attachment to
> > this list? Google drive?
> >
> > Thanks for andy answer and have a nice day,
> >
> > RB
> >
> >
> >
>
> ___
> 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] No Sound with RemoteViewer on OSX Client

[Jakub Janku]

Hi,

On Sun, Feb 21, 2021 at 9:37 AM Matthew Sienko  wrote:
>
> Hello,
>
> When connecting to a VM running on a Linux server from a client on OSX, the 
> connection works but without sound. I am using the RemoteViewer bundle 
> version 0.5.7 on OS X 11.2.1. When the guest OS sends audio, I get the 
> following errors in verbose mode:
>
>
> (RemoteViewer-bin:6323): GStreamer-CRITICAL **: gst_element_query: assertion 
> `GST_IS_ELEMENT (element)' failed
>
> ** (RemoteViewer-bin:6323): CRITICAL **: gst_app_src_push_buffer_full: 
> assertion `GST_IS_APP_SRC (appsrc)' failed
>
> ** (RemoteViewer-bin:6323): CRITICAL **: gst_app_src_push_buffer_full: 
> assertion `GST_IS_APP_SRC (appsrc)' failed


This looks very similar to the following issue:
https://gitlab.freedesktop.org/spice/spice-gtk/-/merge_requests/7
So I'd guess that you don't have the gst-plugins-good package installed.

Apart from these errors, I think that you should also see a warning
starting with "Failed to create a pipeline...", correct?

If installing the mentioned package doesn't help, please run remote
viewer with the --spice-debug option and send the log here.

Thanks,
Jakub
>
>
> Does anybody have any tips as to what could be going wrong and how to fix it?
>
> Thanks,
>  -Matt
>
>
> ___
> 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] No Sound with RemoteViewer on OSX Client

[Jakub Janku]

Forgot to include the mailing list, so I'm replying again, sorry.
Jakub

On Wed, Feb 24, 2021 at 12:49 PM Jakub Janku  wrote:
>
> On Tue, Feb 23, 2021 at 11:47 PM Matthew Sienko  wrote:
> >
> > Thanks for the reply. I installed gst-plugins-good using brew and I still 
> > can't get the sound to work. I attached the output of remote viewer with 
> > the --spice-debug flag. I connected to a running windows guest, tried to 
> > play a sound, then disconnected.
>
> Thanks for the log. I thought there might be a problem with the plugin
> installation, but appsrc should be one of the base plugins and that's
> already in the bundle.
>
> The remote-viewer in brew is pretty outdated, I see. So I'd suggest
> you install the spice-gtk package instead, [0], it should contain all
> the necessary gstreamer dependencies. The package should include a
> tool called spicy which you can use instead of remote viewer, although
> it is meant primarily for testing.
>
> There's also a formula for a newer version of virt-viewer, [1]. Not
> sure why it's not in brew though.
>
> [0] https://formulae.brew.sh/formula/spice-gtk
> [1] https://github.com/jeffreywildman/homebrew-virt-manager
>
> Cheers,
> Jakub
>
> >
> > Thanks,
> >  -Matt
> >
> > On Sunday, February 21, 2021, 8:52:10 AM PST, Jakub Janku 
> >  wrote:
> >
> >
> > Hi,
> >
> > On Sun, Feb 21, 2021 at 9:37 AM Matthew Sienko  
> > wrote:
> > >
> > > Hello,
> > >
> > > When connecting to a VM running on a Linux server from a client on OSX, 
> > > the connection works but without sound. I am using the RemoteViewer 
> > > bundle version 0.5.7 on OS X 11.2.1. When the guest OS sends audio, I get 
> > > the following errors in verbose mode:
> > >
> > >
> > > (RemoteViewer-bin:6323): GStreamer-CRITICAL **: gst_element_query: 
> > > assertion `GST_IS_ELEMENT (element)' failed
> > >
> > > ** (RemoteViewer-bin:6323): CRITICAL **: gst_app_src_push_buffer_full: 
> > > assertion `GST_IS_APP_SRC (appsrc)' failed
> > >
> > > ** (RemoteViewer-bin:6323): CRITICAL **: gst_app_src_push_buffer_full: 
> > > assertion `GST_IS_APP_SRC (appsrc)' failed
> >
> >
> > This looks very similar to the following issue:
> > https://gitlab.freedesktop.org/spice/spice-gtk/-/merge_requests/7
> > So I'd guess that you don't have the gst-plugins-good package installed.
> >
> > Apart from these errors, I think that you should also see a warning
> > starting with "Failed to create a pipeline...", correct?
> >
> > If installing the mentioned package doesn't help, please run remote
> > viewer with the --spice-debug option and send the log here.
> >
> > Thanks,
> > Jakub
> >
> > >
> > >
> > > Does anybody have any tips as to what could be going wrong and how to fix 
> > > it?
> > >
> > > Thanks,
> > >  -Matt
> >
> > >
> > >
> > > ___
> > > 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