[Spice-devel] [PATCH] Add Czech Translation

[David Jaša]

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

Changes since v2:
* fixed the remaining typos

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..20bfba8
--- /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, "
+"odemkněte ji a zkuste soubor přenést znovu."
+
+#: 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 bylo hostitelem odmítnuto"
+
+#: 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 algorit

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

[David Jaša]

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."
+
+#: 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"
+
+#: 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

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

[David Jaša]

At last. :)

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"
+
+#: 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)"
+
+#: 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."
+
+#: src/channel-main.c:1920
+msgid "Session agent not connected."
+msgstr "Agent sezení není připojen"
+
+#: src/channel-main.c:1924
+msgid "File transfer is disabled."
+msgstr "Přenos souboru je vypnutý."
+
+#: 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)"
+
+#: 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"
+
+#: 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 efekty zobrazení na vzdáleném stroji"
+
+#: src/spice-option.c:167
+msgid "Guest display color depth (deprecated)"
+msgstr "Barevná hloubka vzdále

Re: [Spice-devel] Feature suggestion: Port tunneling between VM & client over spice-channel

[David Jaša]

Hi Boris,

On Wed, 2018-11-14 at 11:38 +0900, Boris Morozov wrote:
> Hello, dear friends. I would like a share idea with you about new feature. 
> Please forgive me if i wrong.
> 
> Current approach to publish ports from virtual machine is connecting it to 
> network by network adapter.
> 
> In this case administrator should to write:
> - Routes
> - DNS-records
> - Firewall rules
> 
> In final result: 
> - Virtual machine start going to Internet from host local or ISP network.
> - Virtual machine user can attack gateways and peer nodes in host network.
> - Virtual machine user can attack global sites, services and leave host IP it 
> will raise problems with owners of attacked sites and services, authorities.
> - Virtual machine user can download illegal or forbidden content and leave 
> host IP it will raise problems with authorities.
> - Virtual machine can be attacked from other nodes in host network and 
> internet.
> Internet gateway on host network should open extra ports to perform access to 
> virtual machine.
> - Some computing power of host is begin to spent on NIC and network 
> emulation. 
> - Some time of administrator was spent to configuring and testing routing, 
> dns, firewall.

All of these are standard and both software and people are used to it.
I dare say that it's actually a feature in most cases as administrators
need to keep track of network metadata. Anyway...

> 
> To avoid this responibility and performance problems and reduce time on 
> configuration when public access to virtual machine not needed it's better 
> way to tunnel ports on virtual machine from guest and vice-versa by SPICE.
> 

You're introducing extra latency and limitation on network bandwidth
when connecting to outside networks as network traffic from the VM has
to hairpin through client computer.

> In case of port tunneling over SPICE 
> 
> 1. In virtual machine running services and they opened ports (HTTP, SSH for 
> example) on localhost (127.0.0.1). 
> 2. Spice guest agent in virtual machine open client-port and become ready to 
> connect to services ports from client-port and redirect data to spice 
> channel. 
> 3. In other end of spice channel on client spice client open ports for 
> listening incoming connections on client localhost (127.0.0.1). 
> 4. Client user connect to tunneled ports on client-side localhost and start 
> working with tunneled ports as with local ones. 
> 5. Spice client & guest agent perform traffic redirection.
> 
> As we can see offered approach is more simple. It can't be used against 
> traditional approach in public access but in personal access it's look 
> better. Also it's looks possible to tunnel not only localhost ports on 
> virtual machine and others nodes ones if network is working. 
> 
> Use cases:
> - Web-browsing virtual machine sites on client machine
> - Web-sites, network services (daemons) development
> - Internet access in virtual machine via proxies on client (TOR, VPN, SOCKS, 
> HTTP)
> - Monitoring (getting access to API and dashboards) of various services: 
> printers, miners, solar power chargers, UPS and others. 
> - File transfer between client and virtual machine via FTP, SFTP, HTTP
> - Stream transfer between client and virtual machine video, audio and others.
> - VDI-hosting (Isolated preinstalled VM without NIC)
> 
> 

I think that you could use spiceport channel as a building block with
TUN/TAP device attached to virtio device inside the guest. On client
side, you'd have to write the connector however (similarly to file
transfer or webdav features).

Cheers,

David

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

Re: [Spice-devel] Windows 10: Smartcard is not redirected

[David Jaša]

On Thu, 2017-07-20 at 15:42 +0200, David Jaša wrote:
> Hi Oscar,
> 
> spice client uses on Windows also NSS library to access smart cards,
> so you need to tell NSS where to look for library that provides
> pkcs#11 interface (or "smart card middleware") for your smart card.
> Once you know the .dll, you can create the nssdb and add the library
> there:
> 
> mkdir %PROGRAMFILES%\nssdb%PROGRAMFILES%\VirtViewer*\bin\certutil -d
> %PROGRAMFILES%\nssdb -N%PROGRAMFILES%\VirtViewer*\bin\modutil -dbdir
> %PROGRAMFILES%\nssdb -add "my smartcard middleware" -libfile
> C:\...\my_middleware_pkcs11_library.dll

The path for nssdb should be actually %PROGRAMDATA%\nssdb, so on most
systems C:\ProgramData\nssdb. Sorry for the mistake.
David
> With these steps taken, remote-viewer should pick you smartcard and
> expose it in the guest.
> 
> HTH,
> 
> David
> 
> 
> On Mon, 2017-05-08 at 13:48 +0200, Oscar Segarra wrote:
> > Hi, 
> > In my environment I have a Windows 10 guest and a Windows 10
> > client.
> > 
> > I have configured smartcard as it is suggested in documentation:
> > 
> > https://www.spice-space.org/spice-user-manual.html
> > 
> > 
> > 
> >   
> > 
> > I can see on virt-manager the controller and the devices correctly
> > added. Even in guest Windows 10 appears the ccid smartcard reader
> > device.
> > 
> > I launch my remote-viewer.exe with the following parameters:
> > 
> > remote-viewer.exe -f --spice-smartcard
> > 
> > But when I connect my smartcard in the client, it is not redirected
> > to the guest.
> > 
> > Is there any documentation about how to redirect my smartcard with
> > authentication/sign certificate?
> > 
> > Thanks a lot.
> >  
> > 
> > 
> > 
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Windows 10: Smartcard is not redirected

[David Jaša]

Hi Oscar,
spice client uses on Windows also NSS library to access smart cards, so
you need to tell NSS where to look for library that provides pkcs#11
interface (or "smart card middleware") for your smart card. Once you
know the .dll, you can create the nssdb and add the library there:
mkdir %PROGRAMFILES%\nssdb%PROGRAMFILES%\VirtViewer*\bin\certutil -d
%PROGRAMFILES%\nssdb -N%PROGRAMFILES%\VirtViewer*\bin\modutil -dbdir
%PROGRAMFILES%\nssdb -add "my smartcard middleware" -libfile
C:\...\my_middleware_pkcs11_library.dll
With these steps taken, remote-viewer should pick you smartcard and
expose it in the guest.
HTH,
David

On Mon, 2017-05-08 at 13:48 +0200, Oscar Segarra wrote:
> Hi, 
> In my environment I have a Windows 10 guest and a Windows 10 client.
> 
> I have configured smartcard as it is suggested in documentation:
> 
> https://www.spice-space.org/spice-user-manual.html
> 
> 
> 
>   
> 
> I can see on virt-manager the controller and the devices correctly
> added. Even in guest Windows 10 appears the ccid smartcard reader
> device.
> 
> I launch my remote-viewer.exe with the following parameters:
> 
> remote-viewer.exe -f --spice-smartcard
> 
> But when I connect my smartcard in the client, it is not redirected
> to the guest.
> 
> Is there any documentation about how to redirect my smartcard with
> authentication/sign certificate?
> 
> Thanks a lot.
>  
> 
> 
> 
> 
> ___
> 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] Ultra Wide resolution

[David Jaša]

On Mon, 2017-05-22 at 11:34 +0300, Uri Lublin wrote:
> On 05/22/2017 10:59 AM, Pavel Grunt wrote:
> > Hi,
> > 
> > On Sat, 2017-05-20 at 20:18 -0300, guidu...@gmail.com wrote:
> > > Hi,
> > > 
> > > I have an ultra wide monitor that has max resolution of
> > > 2560x1080. I
> > > use KVM + Spice QXL on all VMs. Unfortunately, I cannot use this
> > > resolution on my virtual machines. Since I can reach this
> > > resolution
> > > if
> > > I use GPU passthrough, I believe the limitation is in spice.
> > > 
> > > If my suspicion is correct, how do I add this resolution?
> > 
> > you must install the latest spice vdagent and set qxl memory
> > parameters.
> > 
> > For more details see:
> > https://www.spice-space.org/multiple-monitors.html
> > 
> > Pavel
> 
> 
> Hi,
> 
> I just want to add that by default (64 MB ram (Bar0)
> and 16MB vgamem) this resolution should be supported
> and that if you change to fullscreen mode (and
> spice-vdagent is running on the guest) then Spice
> should automatically change the guest resolution to fit
> your monitor.
> 
> Uri.
> 

Exactly, spice in default settings is limited to 2560x1600 or 2048x2048
resolution. If 2560x1080 doesn't work, something is wrong.

David

> > 
> > > 
> > > Thank you,
> > > 
> > > Carlos
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server] sound: Use bool type coherently

[David Jaša]

On Wed, 2017-04-19 at 16:51 +0100, Frediano Ziglio wrote:
> Many function already used bool as boolean type.
> Change last gboolean occurrencies and values.

Probably already merged, but: "occurrences"

> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/sound.c | 70 +---
> --
>  1 file changed, 35 insertions(+), 35 deletions(-)
> 
> diff --git a/server/sound.c b/server/sound.c
> index 72dfefb..0d8e154 100644
> --- a/server/sound.c
> +++ b/server/sound.c
> @@ -86,8 +86,8 @@ GType snd_channel_client_get_type(void)
> G_GNUC_CONST;
>  struct SndChannelClient {
>  RedChannelClient parent;
>  
> -gboolean active;
> -gboolean client_active;
> +bool active;
> +bool client_active;
>  
>  uint32_t command;
>  
> @@ -117,7 +117,7 @@ struct AudioFrame {
>  PlaybackChannelClient *client;
>  AudioFrame *next;
>  AudioFrameContainer *container;
> -gboolean allocated;
> +bool allocated;
>  };
>  
>  #define NUM_AUDIO_FRAMES 3
> @@ -169,7 +169,7 @@ struct SndChannel {
>  SndChannelClient *connection; /* Only one client is supported */
>  SndChannel *next; /* For the global SndChannel list */
>  
> -gboolean active;
> +bool active;
>  SpiceVolumeState volume;
>  uint32_t frequency;
>  };
> @@ -278,7 +278,7 @@ static bool
> snd_record_handle_write(RecordChannelClient *record_client, size_t s
>  uint32_t now;
>  
>  if (!record_client) {
> -return FALSE;
> +return false;
>  }
>  
>  packet = (SpiceMsgcRecordPacket *)message;
> @@ -292,7 +292,7 @@ static bool
> snd_record_handle_write(RecordChannelClient *record_client, size_t s
>  decode_size = sizeof(record_client->decode_buf);
>  if (snd_codec_decode(record_client->codec, packet->data,
> packet->data_size,
>  record_client->decode_buf, _size) !=
> SND_CODEC_OK)
> -return FALSE;
> +return false;
>  data = (uint32_t *) record_client->decode_buf;
>  size = decode_size >> 2;
>  }
> @@ -311,7 +311,7 @@ static bool
> snd_record_handle_write(RecordChannelClient *record_client, size_t s
>  if (record_client->write_pos - record_client->read_pos >
> RECORD_SAMPLES_SIZE) {
>  record_client->read_pos = record_client->write_pos -
> RECORD_SAMPLES_SIZE;
>  }
> -return TRUE;
> +return true;
>  }
>  
>  static
> @@ -349,12 +349,12 @@ record_channel_handle_message(RedChannelClient
> *rcc, uint16_t type, uint32_t siz
>  record_client->mode = mode->mode;
>  } else {
>  spice_printerr("create decoder failed");
> -return FALSE;
> +return false;
>  }
>  }
>  else {
>  spice_printerr("unsupported mode %d", record_client-
> >mode);
> -return FALSE;
> +return false;
>  }
>  }
>  else
> @@ -373,7 +373,7 @@ record_channel_handle_message(RedChannelClient
> *rcc, uint16_t type, uint32_t siz
>  default:
>  return red_channel_client_handle_message(rcc, type, size,
> message);
>  }
> -return TRUE;
> +return true;
>  }
>  
>  static bool snd_channel_send_migrate(SndChannelClient *client)
> @@ -387,7 +387,7 @@ static bool
> snd_channel_send_migrate(SndChannelClient *client)
>  spice_marshall_msg_migrate(m, );
>  
>  red_channel_client_begin_send_message(rcc);
> -return TRUE;
> +return true;
>  }
>  
>  static bool snd_playback_send_migrate(PlaybackChannelClient *client)
> @@ -405,7 +405,7 @@ static bool snd_send_volume(SndChannelClient
> *client, uint32_t cap, int msg)
>  SpiceVolumeState *st = >volume;
>  
>  if (!red_channel_client_test_remote_cap(rcc, cap)) {
> -return FALSE;
> +return false;
>  }
>  
>  vol = alloca(sizeof (SpiceMsgAudioVolume) +
> @@ -418,7 +418,7 @@ static bool snd_send_volume(SndChannelClient
> *client, uint32_t cap, int msg)
>  spice_marshall_SpiceMsgAudioVolume(m, vol);
>  
>  red_channel_client_begin_send_message(rcc);
> -return TRUE;
> +return true;
>  }
>  
>  static bool snd_playback_send_volume(PlaybackChannelClient
> *playback_client)
> @@ -436,7 +436,7 @@ static bool snd_send_mute(SndChannelClient
> *client, uint32_t cap, int msg)
>  SpiceVolumeState *st = >volume;
>  
>  if (!red_channel_client_test_remote_cap(rcc, cap)) {
> -return FALSE;
> +return false;
>  }
>  
>  red_channel_client_init_send_data(rcc, msg);
> @@ -444,7 +444,7 @@ static bool snd_send_mute(SndChannelClient
> *client, uint32_t cap, int msg)
>  spice_marshall_SpiceMsgAudioMute(m, );
>  
>  red_channel_client_begin_send_message(rcc);
> -return TRUE;
> +return true;
>  }
>  
>  static bool snd_playback_send_mute(PlaybackChannelClient
> *playback_client)
> @@ -465,7 +465,7 @@ static bool
> 

Re: [Spice-devel] Multi Console

[David Jaša]

On Thu, 2017-03-02 at 15:01 +0100, Pavel Grunt wrote:
> On Wed, 2017-03-01 at 10:21 +0100, Christian Rilke wrote:
> > Hi,
> >  
> > first think i have to say is THANK YOU! Spice is the best think
> > happened to the qmeu community since we need graphical consoles.
> >  
> > I just have a short question about multiple console feature. I read
> > that is still experimental? Is this still true? I found out that i
> > need SPICE_DEBUG_ALLOW_MC=1 to get it working.
> > Are there any more concrete plants to improve this feature? We use
> > this daily. The most time we have no trouble but sometimes its
> > buggy. Specially if some change the size of he spice window.
> 
> It is problematic - if one changes the size, the change is
> transferred
> to other users. Sometimes there can be a race - for instance when one
> uses virt-manager as a client - it has a fixed size, so it keeps
> sending a size request matching its size (and possibly overwriting
> request from other clients).
> 
> A solution may be to accept size request only from one client (or
> agent messages in general)

Yeah. It would be good to have receive-only consoles that would allow
e.g. distributed presentations as it is possible with VNC, they should
be also easier to polish than full-featured multiple clients.

David

> 
> 
> If you find some bugs, please report them.
> 
> Thanks,
> Pavel
> 
> >  
> > Cheers,
> > Chris
> > 
> > 
> > Diese E-
> > Mail wurde von einem automatischen Virenscanner überprüft und für v
> > i
> > renfrei befunden.
> > Es kann jedoch nicht ausgeschlossen werden, dass Mails mit noch unb
> > e
> > kannten Viren verseucht sind.
> > IBIX Informationssysteme GmbH übernimmt keine Haftung für Schäden d
> > u
> > rch Virenbefall.
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Blurry spice-widget

[David Jaša]

On St, 2016-12-21 at 02:57 +0100, Jason A. Donenfeld wrote:
> Hi folks,
> 
> Since spicy is gtk3, it supports HiDPI scaling of widgets, which is
> great. The menus and icons are all in beautiful proportion, scaled up
> 2x, since I'm on a 192-dpi screen. Yay.
> 
> However, the spice-widget.c view of the Windows 10 VM, which is
> showing what's essentially a bitmap stream, is also scaled 2x. Scaling
> a bitmap 2x makes everything look blurry and awful. The solution is
> for spice-widget.c *not* to scale up 2x. This widget should always be
> at 1x.
> 
> Example: my 15 inch laptop screen has a resolution of 3840x2160.

 
You're actually on 294 dpi screen :)

sqrt(3840**2 + 2160**2) / 15
293.7209560109731

>  All
> icons and menus of Gtk programs are correctly scaled at 2x. At full
> screen, when the spice-widget view is scaled at 2x, it reports to
> Windows 10 over spice that it only is 1920x1080. Windows 10 renders as
> such. Then this 1920x1080 view is scaled up by 2x. This is incorrect
> behavior. The correct behavior would be for the spice-widget to render
> at 1x, and at full screen to report to Windows 10 that it is
> 3840x2160, and then scale the Windows 10 view by 1x (no scaling).
> 
> Is this something that might be possible? Otherwise, spice-gtk won't
> be suitable for HiDPI screens.

This is actually good RFE that can work for different cases both by
extending the normal-DPI guest screen (for older guest systems or apps
that don't need good grahpics - to save bandwidth) or by conveying the
actual DPI to the guest to make all your screen real-estate usable.

David

> Thanks,
> Jason
> ___
> 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] mouse mode

[David Jaša]

Hi,

I understand your question only vaguely so I'm writing my best guess
answer. The server mouse mode means that mouse events are sent via
server to the guest OS that in turn renders cursor on it's own. The main
downside is big latency, the mouse pointer position changes with
noticeable delay even on local networks.

Client mouse mode fixes this issue by drawing the cursor right away and
sending it's coordinates to the guest OS. Guest OS however needs to know
that it should not render cursor (to avoid double cursor) and current
pointer position. This is the task for spice agent that receives these
instructions via virtio-serial device.

Linux guests should support client mouse mode right away, if it doesn't
work for you, you have to install and run spice-vdagentd service. On
Windows guests, you have to install virtio-serial driver and spice
vdagent for Windows.
In both cases, spice will use client mouse mode whenever available.

You can also enforce server mouse mode even if all things necessary for
client mouse are in place.

HTH,

David

On Pá, 2016-12-16 at 16:45 +0800, BCFarsight wrote:
> Execue me, you know, Spice supports two mouse modes: server and
> client.
> Now, I want to know the details about server mouse modes. When setting
> server mode about mouse,
> What I need to do any work or change on servers? If you have any
> suggestions, you could tell me.
> Thank you very very much!
> 
> 
> 
> 
>  
> 
> ___
> 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] I am a China java development engineer, i had achinese keyboard qusetion need to be solved

[David Jaša]

Hi,

just, for information, what app do you use to access VMs over spice, is
it Iordan's aSpice project or something else? What keyboard app do you
use?

How did you find out that "spice and qemu-kvm can't handle chinese
characters"? Did you encounter some qemu crash (then please get the
backtrace and attach it), or were there some errors in qemu log?

Adding more information raises chances that you'll solve your problem.

Best Regards,

David Jaša


On Pá, 2016-12-09 at 09:31 +0800, 史建超 wrote:
>  
> yes， i am  trying to connect to a virtual machine using Spice with an Android 
> pad client(like apple pad,but it is Android 
> 
> system,not ios).
> when i input in chinese with Android pad,i must used  Android system original 
> keyboard,but spice and qemu-kvm can't handle 
> 
> chinese characters ,so the system in the virtual machine can't handle that. 
> I have also tried to use the PC paste interface to achieve the Chinese 
> character transmission on Android keyboard, but the transmission in the past 
> can not be processed, as if being truncated, can only receive a single 
> English character.
>  
>  
> 史建超  Johnny
> 卓朗科技软件事业
> 部
> 手机（Mobile）：18612717308 TROILA TECHNOLOGY
> DEVELOPMENT CO.,LTD
> 
> 
> 座机（Phone）：022-58301500-8048 天津卓朗科技发展有限公司
> 
> 传真（Fax）：022-58301518
> 
> 
> 
> __
> 发件人： Frediano Ziglio 
> 发送时间： 2016-12-08  20:10:46 
> 收件人： 史建超 
> 抄送： spice-devel 
> 主题： Re: [Spice-devel] I am a China java development engineer, i had
> achinese keyboard qusetion need to be solved 
> 
> Which SDK are you referring to? Android?
> 
> Officially we don't provide Android application/library, which website
> are you referring to?
> 
> What's the problem with Android keyboard input you are having?
> 
> I can guess you are trying to connect to a virtual machine using Spice
> and an Android client
> 
> but having problem with input methods. We (as a team) are not that
> used to different input
> 
> methods, can you describe the problem you are having and how do you
> expect it should work?
> 
> 
> 
> Frediano
> 
> 
> 
> 
> __
> From: "史建超" <shijianc...@troila.com>
> To: "spice-devel" <spice-devel@lists.freedesktop.org>,
> "spice-devel" <spice-devel@lists.freedesktop.org>
> Sent: Thursday, December 8, 2016 2:46:11 AM
> Subject: [Spice-devel] I am a China java development
> engineer,i had a chinese keyboard qusetion need to be
> solved
> 
> 
> Hello.
> I am a China java development engineer,  
> My Android mobile project has used spice, 
> but according to the website to download the relevant steps SDK has 4 
> unexpected error resources on the web link is not available, 
> now I need to solve Chinese by Android keyboard input, transmission 
> interface to channel window in the system of virtual desktop, 
> tried before pasting channel, but only the PC end can be realized. 
> Can you give me a full SDK,
> or in the channel to change the keyboard channel interface, do not 
> cut off or read all of the character, to complete the transmission of 
> keyboard input characters. 
> and
> Spice for the Chinese keyboard input in the future whether there is 
> support for the plan? 
>  
> 2016-12-08 
> 
> __
> 
> __
>  
> 史建超  Johnny
> 卓朗科技软件事业
> 部 
>
> 手机（Mobile）：18612717308 TROILA TECHNOLOGY
> DEVELOPMENT CO.,LTD
> 
> 
> 座机（Phone）：022-58301500-8048 天津卓朗科技发展有限
> 公司
> 
> 传真（Fax）：022-58301518
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] Spice-devel Digest, Vol 80, Issue 35

[David Jaša]

This very mail contains unsubscribe links in header:


List-Unsubscribe:
 , 
 


First link is web interface and 2nd one is mail - just click, send,
maybe confirm and that's it.

David

On St, 2016-09-07 at 11:49 +0800, nlx wrote:
> 
> 
> 
> Hi
>   I want to unsubscribe this mailing list , please help me.
> Thank you very much 
> 
> 
> BR.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 2016-09-05 16:34:42, spice-devel-requ...@lists.freedesktop.org wrote:
> >Send Spice-devel mailing list submissions to
> > spice-devel@lists.freedesktop.org
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> >or, via email, send a message with subject or body 'help' to
> > spice-devel-requ...@lists.freedesktop.org
> >
> >You can reach the person managing the list at
> > spice-devel-ow...@lists.freedesktop.org
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of Spice-devel digest..."
> >
> >
> >Today's Topics:
> >
> >   1. [PATCH qxl-wddm-dod v2 00/25] Win10 support patches
> >  (Sameeh Jubran)
> >   2. [PATCH qxl-wddm-dod v2 01/25] Upgrade to Windows 10WDK
> >  (Sameeh Jubran)
> >
> >
> >--
> >
> >Message: 1
> >Date: Mon,  5 Sep 2016 11:33:57 +0300
> >From: Sameeh Jubran 
> >To: spice-devel@lists.freedesktop.org
> >Cc: Dmitry Fleytman 
> >Subject: [Spice-devel] [PATCH qxl-wddm-dod v2 00/25] Win10 support
> > patches
> >Message-ID: <1473064462-8220-1-git-send-email-sam...@daynix.com>
> >
> >This series contains the latest patches to support Windows 10.
> >
> >Visual Studio 2015 with Win10 WDK is required to compile this code,
> >Current patches may be compiled and will work for Windows 10.
> >
> >To ease the process of the reviews, those patches are avilable on:
> >https://github.com/daynix/qxl-wddm-dod branch: gitlab_win10_v2
> >
> >The patches were applied on the master branch of 
> >https://gitlab.com/spice/qxl-wddm-dod
> >
> >Dmitry Fleytman (2):
> >  Fixing framebuffer usage logic
> >  Support future Qxl revisions
> >
> >Sameeh Jubran (16):
> >  Upgrade to Windows 10 WDK
> >  Add delete operator
> >  Add debug print macro to dump debug print statements to kernel
> >debugger output
> >  Add type enum to qxl/vga device
> >  On power wake call the init functions before setting the vidpn to
> >black. Otherwise, BSOD.
> >  Fix interrupt mask
> >  Remove unused notify present display only interrupt
> >  Add arbitrary resolution and monitors_config Escape
> >  Rename mspace.c to mspace.cpp
> >  Code Analysis clean up
> >  Replacing tabs with spaces
> >  Fixing Move rectangles implementation
> >  Reserved must be set to 0
> >  Fixing monitor flicker on resolution change
> >  Removing unnecessary call to BlackOutScreen
> >  Fixing possible BSOD
> >
> >Sandy Stutsman (7):
> >  Set DriverStarted flag at the begining of the StartDriver function
> >  Fix Code Integrity error generated by the Drive Verifier
> >  Use SrcPitch when calculating size of memory to map PresentDisplayOnly
> >  Use the second bar (VRAM) for qxl command buffer.
> >  Enable HW cursor support and fix handling of monochrome cursors.
> >  Remove minimum size restrict for custom resolution.
> >  Use frame buffer in VGA mode only
> >
> > Tools/vs_cmdline.vbs   |   23 +
> > Tools/vs_run.bat   |   26 +
> > buildAll.bat   |   15 +
> > buildAll_NoSign.bat|   19 +
> > qxldod Package/qxldod Package.vcxproj  |  173 +-
> > qxldod Package/qxldod Package.vcxproj.user |   15 +
> > qxldod.sln |  106 +-
> > qxldod/BaseObject.cpp  |   11 +
> > qxldod/BaseObject.h|1 +
> > qxldod/QxlDod.cpp  | 1167 +++--
> > qxldod/QxlDod.h|   44 +-
> > qxldod/buildAll.bat|   31 -
> > qxldod/callVisualStudio.bat|   28 -
> > qxldod/checkWin8Tools.bat  |8 -
> > qxldod/clean.bat   |   12 -
> > qxldod/driver.cpp  |   16 +-
> > qxldod/driver.h|   12 +-
> > qxldod/include/qxl_windows.h   |9 +
> > qxldod/mspace.c| 2437 
> > 
> > qxldod/mspace.cpp  | 2437 
> > 
> > qxldod/qxldod.vcxproj  |  247 ++-
> > qxldod/qxldod.vcxproj.filters  |2 +-
> > qxldod/qxldod.vcxproj.user |   15 +
> > 23 files changed, 3498 insertions(+), 3356 deletions(-)
> > create mode 100644 

Re: [Spice-devel] question: how to test the gstreamer:h264 with qemu ?

[David Jaša]

On Pá, 2016-07-29 at 10:19 +0200, cferg...@redhat.com wrote:
> On Fri, Jul 29, 2016 at 08:10:46AM +, Li, ZhijianX wrote:
> > 
> > > -Original Message-
> > > From: cferg...@redhat.com [mailto:cferg...@redhat.com]
> > > Sent: Friday, July 29, 2016 3:17 PM
> > > To: Li, ZhijianX 
> > > Cc: gou...@codeweavers.com; Spice-devel@lists.freedesktop.org
> > > Subject: Re: [Spice-devel] question: how to test the gstreamer:h264 with
> > > qemu ?
> > > 
> > > Hey,
> > > 
> > > On Fri, Jul 29, 2016 at 03:05:21AM +, Li, ZhijianX wrote:
> > > > Hello  guys,
> > > >
> > > > Recently, I found that spice have supported gstremer:h264 encoding, so I
> > > want to have a try.
> > > > But I'm not sure how to test this feature(I am a spice newbie)
> > > >
> > > > If I play a h264 encoding video in the guest, how can I *confirm* that
> > > > the gstremer:h264 works or not ?
> > > >
> > > > If I miss something, please let me know.
> > > > Below is my environment:
> > > > Host, Ubuntu 16.04 lts
> > > > 1.  guest
> > > > Win7 +" Red Hat QXL GPU(6.1.0.10020)"
> > > > 2. qemu
> > > > Branch: master + gstreamer related
> > > > patch(https://lists.freedesktop.org/archives/spice-devel/2015-May/0197
> > > > 71.html) Start qemu with " -spice video-codes=gstreamer:h264" options
> > > > 3. spice
> > > > Branch: master(comit: 29caba2)
> > > > Configuration with "--enable-gstreamer=1.0"
> > > > 4. spice-gtk
> > > > Branch: master(commit: 9b82e92)
> > > > Configuration with "--enable-gstvideo=yes"
> > > > 5. spice-protocol
> > > > Branch: master
> > > 
> > > Usually I just change default_video_codecs in spice-server/server/reds.c 
> > > so
> > > that it starts with gstreamer:h264.
> > That's interesting  :)  
> > More question: Does the spice-client side(remote-viewer) or the guest
> > driver need some special options to notify the client 
> > to use the gstreamer:h264. 
> 
> Once the streaming code triggers, use of h264 instead of mjpeg should be
> automatic if both the server and the client have the required gstreamer
> plugins.

Are we going to use some automagic decision between video formats based
on CPU and network conditions? (We were discussing something in that
vein for image compression in last months).

David

> 
> Christophe
> ___
> 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 RFC 00/12] Remote Virgl support

[David Jaša]

Hi,

On Po, 2016-07-18 at 16:16 +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > What is the state of the hardware supported encoding?
> > > How can we pass buffers to the hardware encoder? 
> > 
> > The state here is a bit of a mess.
> > One reason to pass texture instead of dma buffers is that we use gstreamer
> > and gstreamer for hardware acceleration uses VAAPI and one way to pass
> > frames to VAAPI is to use GL textures. There is a quite strong requirement
> > that dma buffers should be mmap-able in gstreamer but this is not true.
> > Note that in theory VAAPI can import DRM prime/dma buffers however this is
> > currently not exported/implemented by gstreamer-vaapi.
> 
> Any chance to extend gstreamer-vaapi?
> 
> > The current status of hardware encoding is a bit confusing.
> > On one side there is VAAPI which should be an independent (from card brand)
> > library to use hardware decoding/encoding however some vendor (like Nvidia)
> > seems not really keen on supporting it for encoding (the binding for Nvidia
> > is using vdpau which is limited to decoding). VAAPI was proposed by Intel
> > so for Intel is really good.
> 
> Hmm.  But vaapi support is pretty much required to have gstreamer handle
> video encoding for us I guess?
> 
> > On the other side we could have patent/licensing issues due to the fact that
> > main encoding supported (basically mpeg2, h264, hevc) all have patents while
> > more open encoding (vp8, vp9) are not currently widely supported.
> 
> That is nasty indeed.  Recent intel hardware supports vp8 + vp9 too.
> Nvidia is H.264 only as far I know.
> 
> Not sure if offloading the encoding to the hardware helps with the
> patent situation.  At least we don't have to ship a (cpu) software
> encoder then.  But possibly some kind of firmware or gpu program must be
> uploaded ...
> 

Cisco's OpenH264 encodes and decodes basic profile of h.264 and Cisco is
covering patent fees for anybody who uses it. It is not shipped with
everybody's OS by default but given the motivation and implementation,
it should be available pretty much anywhere in quite near term (it
actually is available on most systems running Firefox - but it Firefox's
directories, not system ones).

Cisco already provides a Fedora repo with decoder packaged for Firefox
and Gstreamer. Given that, we could probably depend on h.264 basic being
available universally pretty soon.

David

Fedora's OpenH264 wiki page: https://fedoraproject.org/wiki/OpenH264

> > >  (1) Extend the display channel interface to have callbacks for these
> > >  (and thin wrapper functions which map spice display channel to
> > >  QemuConsole so spice-server doesn't need to worry about that).
> > > 
> > 
> > So you mean a way for spice-server display channel to call some Qemu
> > function, right?
> 
> Yes.  Add function pointers to QXLInterface & raise minor display
> channel interface version should do.
> 
> > >  (2) Have qemu create one context per spice-server (or per display
> > >  channel) and create a new spice_server_set_egl_context() function
> > >  to hand over the context to spice-server.
> > > 
> > 
> > Yes, I added a spice_qxl_gl_init function which set display and context.
> 
> Ah, didn't notice that on the first check.  Yes, that looks good
> interface-wise.  Possibly we should create a new context instead of
> reusing qemu_egl_rn_ctx.  But that doesn't affect the spice-server
> interface.
> 
> But can you make that a separate patch please?
> 
> > Probably I feel more confident having more flexibility as is not clear
> > the resulting information we need.
> 
> I surely don't want to rush things on the interface side.  I think we
> should have at least a proof-of-concept implementation showing the
> qemu/spice-server we created actually works before merging things.
> 
> > Another stuff I would like to have changed in Qemu is the number of
> > pending frames sent by it. I think that a single frame is not enough.
> > There should be at least 2/3 frames. The reason is that streaming/network
> > requires more time and would be better if there could be one frame which
> > is encoding/pending and one which is new which could be replaced by a
> > new frame that will arrive if encoding/network is not fast enough.
> 
> Hmm.  The guest will not give us 2-3 frames though.  We'll have either
> one or two, depending on whenever the guest uses page-flips or not.  So
> implementing a buffering scheme as outlined above requires us to copy
> (or let the gpu copy) the frames.
> 
> Question is where to do it best.  It is doable in qemu and spice-server.
> But spice-server knows more about the network/encoder state and can
> possibly avoid the copy, for example in case it isn't going the encode
> the frame anyway due to full network buffers, or in case no client is
> connected in the first place.
> 
> cheers,
>   Gerd
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> 

Re: [Spice-devel] [ovirt-users] Accessing VM over WAN

[David Jaša]

On Ne, 2016-06-26 at 09:36 +0530, RK RK wrote:
> Hi,
> 
> 
> I am planning to deploy oVirt 4.0.0 in a production environment where
> initially it will host 150 VDIs and will expand by 20 to 25 in
> subsequent years with Windows 7, 8.1 and 10.
> 

Please note that official win8+ qxl driver is not ready yet so you won't
have continuous resolution change (just in steps of well-known
resolutions), multi monitor support and some video performance
optimizations with those OSs

> 
> Users will be accessing these VDIs from their android tab or any tiny
> thin client devices which will have only very small footprint OS with
> HTML5 supported browser. 
> 

Please consider use of native apps: aSpice/Opaque [1] or "flexVDI
Client" [2] or moVirt [3]. Opaque and moVirt give you oVirt integration
right away, flexVDI has iOS support

[1] 
https://play.google.com/store/apps/developer?id=Iordan%20Iordanov%20%28Undatech%29
[2] https://github.com/flexVDI/launcher-mobile
[3] https://play.google.com/store/apps/details?id=org.ovirt.mobile.movirt

All of them are going to have better UX than spice-html5. FlexVDI also
developed their own html5 client (available at their github as well)
with some stuff better and some worse than spice-html5 client.

> I wish to give users to access the VDIs over WAN(from their home or on
> travel). Is it possible to access the VDIs via spice-html5 over the
> WAN.
> 

IIRC spice-html5 supports all the compression types so protocol-side
optimizations should be available automatically and without issues.

The "WAN options" of user portal mean that agent disables "fancy" bits
of Windows graphics, the only support from client is to do the setting
when establishing connection. You could give it a try

> 
> Any special configurations to be made to enable it? How should I make
> spice-html5 as the default protocol to access the VDIs?

set ClientModeSpiceDefault engine-config variable to Html5 (as per
https://bugzilla.redhat.com/show_bug.cgi?id=1311408 )

HTH,

David

> 
> -- 
> 
> With Regards,
> RK,
> +91 9840483044
> 
> ___
> Users mailing list
> us...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users


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

Re: [Spice-devel] [PATCH spice-gtk 1/4] tests: Add test for SpiceUri

[David Jaša]

On Po, 2016-05-16 at 10:10 -0400, Frediano Ziglio wrote:
> > 
> > Related: rhbz#1335239
> > ---
> >  tests/Makefile.am  |  2 ++
> >  tests/test-spice-uri.c | 64
> >  ++
> >  2 files changed, 66 insertions(+)
> >  create mode 100644 tests/test-spice-uri.c
> > 
> > diff --git a/tests/Makefile.am b/tests/Makefile.am
> > index c1d95c1..fb97138 100644
> > --- a/tests/Makefile.am
> > +++ b/tests/Makefile.am
> > @@ -4,6 +4,7 @@ noinst_PROGRAMS =
> >  TESTS = coroutine  \
> > util\
> > session \
> > +   test-spice-uri  \
> > $(NULL)
> >  
> >  if WITH_PHODAV
> > @@ -35,6 +36,7 @@ util_SOURCES = util.c
> >  coroutine_SOURCES = coroutine.c
> >  session_SOURCES = session.c
> >  pipe_SOURCES = pipe.c
> > +test_spice_uri_SOURCES = test-spice-uri.c
> >  usb_acl_helper_SOURCES = usb-acl-helper.c
> >  usb_acl_helper_CFLAGS = -DTESTDIR=\"$(abs_builddir)\"
> >  mock_acl_helper_SOURCES = mock-acl-helper.c
> > diff --git a/tests/test-spice-uri.c b/tests/test-spice-uri.c
> > new file mode 100644
> > index 000..993cc78
> > --- /dev/null
> > +++ b/tests/test-spice-uri.c
> > @@ -0,0 +1,64 @@
> > +/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
> > +/*
> > +   Copyright (C) 2016 Red Hat, Inc.
> > +
> > +   This library is free software; you can redistribute it and/or
> > +   modify it under the terms of the GNU Lesser General Public
> > +   License as published by the Free Software Foundation; either
> > +   version 2.1 of the License, or (at your option) any later version.
> > +
> > +   This library 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
> > +   Lesser General Public License for more details.
> > +
> > +   You should have received a copy of the GNU Lesser General Public
> > +   License along with this library; if not, see
> > .
> > +*/
> > +#include 
> > +#include 
> > +#include "spice-uri-priv.h"
> > +
> > +static void test_spice_uri_ipv4(void)
> > +{
> > +SpiceURI *uri = spice_uri_new();
> > +g_assert_nonnull(uri);
> > +
> > +/* missing hostname */
> > +g_assert_false(spice_uri_parse(uri, "http://:80;, NULL));
> > +/* invalid port */
> > +g_assert_false(spice_uri_parse(uri, "http://127.0.0.1:port;, NULL));
> > +
> > +g_assert_true(spice_uri_parse(uri, "http://127.0.0.1/;, NULL));
> > +g_assert_cmpstr(spice_uri_get_scheme(uri), ==, "http");
> > +g_assert_cmpstr(spice_uri_get_hostname(uri), ==, "127.0.0.1");
> > +g_assert_cmpuint(spice_uri_get_port(uri), ==, 3128);
> > +
> > +g_assert_true(spice_uri_parse(uri, "https://127.0.0.1;, NULL));
> > +g_assert_cmpstr(spice_uri_get_scheme(uri), ==, "https");
> > +g_assert_cmpstr(spice_uri_get_hostname(uri), ==, "127.0.0.1");
> > +g_assert_cmpuint(spice_uri_get_port(uri), ==, 3129);
> > +
> > +g_assert_true(spice_uri_parse(uri, "127.0.0.1", NULL));
> > +g_assert_cmpstr(spice_uri_get_scheme(uri), ==, "http");
> > +g_assert_cmpstr(spice_uri_get_hostname(uri), ==, "127.0.0.1");
> > +g_assert_cmpuint(spice_uri_get_port(uri), ==, 3128);
> > +
> > +g_assert_true(spice_uri_parse(uri, "http://user:password@host:80;,
> > NULL));
> > +g_assert_cmpstr(spice_uri_get_scheme(uri), ==, "http");
> > +g_assert_cmpstr(spice_uri_get_hostname(uri), ==, "host");
> > +g_assert_cmpstr(spice_uri_get_user(uri), ==, "user");
> > +g_assert_cmpstr(spice_uri_get_password(uri), ==, "password");
> > +g_assert_cmpuint(spice_uri_get_port(uri), ==, 80);
> > +
> > +g_object_unref(uri);
> > +}
> > +
> > +int main(int argc, char* argv[])
> > +{
> > +g_test_init(, , NULL);
> > +
> > +g_test_add_func("/spice_uri/ipv4", test_spice_uri_ipv4);
> > +
> > +return g_test_run();
> > +}
> > --
> > 2.8.2
> > 
> 
> Looks ok, a bit weird that default ports are 3128 and 3129, looks different
> from the "URI" definition.

IIUC there is no real standard port for http CONNECT proxies, let alone
for much less used https. 3128 is default for squid, some other default
to 8080/8443 and some use just standard http(s) ports of 80/443 (e.g.
apache's mod_proxy).

David

> 
> Frediano
> ___
> 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] Seeking kind help

[David Jaša]

Hello,

this list is for Spice the VDI protocol, not Spice the Circuit
simulator. What you're probably looking for is some of ngspice project
mailing lists: http://ngspice.sourceforge.net/mlarch.html

David

On Ne, 2016-05-08 at 19:31 +0800, jakkula bhoolaxmi wrote:
> Dear Sir/Madam,
> 
> 
> I have simulated one circuit which is from one of the IEEE paper, they
> have got power dissipation in micro watts,  but I am getting power
> dissipation in nano watts for the same circuit. May I seek your kind
> help whats wrong in my code. Many thanks in advance for your kind
> help.
> 
> 
> 
> 
>  1. The Circuit I referred,
> Inline image 2
> 
> 
> 
> 
> 
>  The referred paper is attached herewith.
> ___
> 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-devel]How to reduce the image resolution or definition ?

[David Jaša]

Hi,

This code comment suggests that during streaming, JPG quality adjustment
takes place:

/*
 * Adjusting the stream jpeg quality and frame rate (fps):
 * When during_quality_eval=TRUE, we compress different frames with different
 * jpeg quality. By considering (1) the resulting compression ratio, and (2) 
the available
 * bit rate, we evaluate the max frame frequency for the stream with the given 
quality,
 * and we choose the highest quality that will allow a reasonable frame rate.
 * during_quality_eval is set for new streams and can also be set any time we 
want
 * to re-evaluate the stream parameters (e.g., when the bit rate and/or
 * compressed frame size significantly change).
 */
- taken from 
https://cgit.freedesktop.org/spice/spice/tree/server/mjpeg-encoder.c#n122

That should do pretty much exactly what you want - adjust stream
bandwidth to available network throughput, albeit by using jpeg quality
instead of downscaling. That's better approach IMO as b/w savings can be
as big as with downscaling but CPU load will be significantly lower.

Regards,

David


On Út, 2016-04-12 at 17:18 +0800, hongzhen_...@sina.com wrote:
>  Hello  
> 
> 
>Could you tell  me how to reduce the image resolution or
> definition ?
> 
>I plan to reduce the image definition so that  decrease data
> transmission from server to client .
> 
>For example ,I assume if I have a low bandwidth in my network
> environment,but it's stable , I want to reduce the image definition
> to ensure a small quantity of data were sent  between the server and
> client  ,for the client can be worked normally (such as basic
> operation).
> 
> 
>   But I don't know how to modify and control it (which functions
> or attributes),  if you know that ,please help  me . Thank you very
> much ...
> 
> Best Regards 
> 
> 
> 
> 
>  
> 
> 
> ___
> 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 14/20] Use GQueue for RedCharDevice::send_queue

[David Jaša]

On Po, 2016-04-18 at 05:17 -0400, Frediano Ziglio wrote:
> > On Thu, 2016-04-14 at 16:50 -0500, Jonathon Jongsma wrote:
> > > From: Christophe Fergeau 
> > > 
> > > There was an extra RedCharDeviceMsgToClientItem type whose only
> > > purpose was to manage a linked list of items to send. GQueue has the
> > > same purpose as this type in addition to being generic. As the length of
> > > the send queue is tracked, a GQueue is more appropriate than a GList and
> > > allow to remove RedCharDevice::send_queue_size.
> > > ---
> > >  server/char-device.c | 69
> > >  ++-
> > > -
> > >  1 file changed, 23 insertions(+), 46 deletions(-)
> > > 
> > > diff --git a/server/char-device.c b/server/char-device.c
> > > index f3e16da..6b9596e 100644
> > > --- a/server/char-device.c
> > > +++ b/server/char-device.c
> > > @@ -41,8 +41,7 @@ struct RedCharDeviceClient {
> > >  uint64_t num_send_tokens; /* send to client */
> > >  SpiceTimer *wait_for_tokens_timer;
> > >  int wait_for_tokens_started;
> > > -Ring send_queue;
> > > -uint32_t send_queue_size;
> > > +GQueue *send_queue;
> > >  uint32_t max_send_queue_size;
> > >  };
> > >  
> > > @@ -105,11 +104,6 @@ static guint signals[RED_CHAR_DEVICE_LAST_SIGNAL];
> > >  static void red_char_device_write_buffer_unref(RedCharDeviceWriteBuffer
> > > *write_buf);
> > >  static void red_char_device_write_retry(void *opaque);
> > >  
> > > -typedef struct RedCharDeviceMsgToClientItem {
> > > -RingItem link;
> > > -PipeItem *msg;
> > > -} RedCharDeviceMsgToClientItem;
> > > -
> > >  static PipeItem *
> > >  red_char_device_read_one_msg_from_device(RedCharDevice *dev)
> > >  {
> > > @@ -187,19 +181,10 @@ static void
> > > red_char_device_write_buffer_pool_add(RedCharDevice *dev,
> > >  static void red_char_device_client_send_queue_free(RedCharDevice *dev,
> > > RedCharDeviceClient
> > > *dev_client)
> > >  {
> > > -spice_debug("send_queue_empty %d", ring_is_empty(_client
> > > ->send_queue));
> > > -while (!ring_is_empty(_client->send_queue)) {
> > > -RingItem *item = ring_get_tail(_client->send_queue);
> > > -RedCharDeviceMsgToClientItem *msg_item = SPICE_CONTAINEROF(item,
> > > -
> > >  RedCharDeviceMsgToClientItem,
> > > -   link);
> > > -
> > > -ring_remove(item);
> > > -pipe_item_unref(msg_item->msg);
> > > -free(msg_item);
> > > -}
> > > -dev_client->num_send_tokens += dev_client->send_queue_size;
> > > -dev_client->send_queue_size = 0;
> > > +spice_debug("send_queue_empty %d", g_queue_is_empty(dev_client
> > > ->send_queue));
> > > +g_queue_free_full(dev_client->send_queue, pipe_item_unref);
> > > +g_queue_clear(dev_client->send_queue);
> > > +dev_client->num_send_tokens += g_queue_get_length(dev_client
> > > ->send_queue);
> > 
> > This looks wrong. We're calling g_queue_get_length() immediately after
> > clearing
> > the queue, so it's guaranteed to be 0. This last line should be moved before
> > the
> > g_queue_free_full() call.
> > 
> > >  }
> > >  
> > >  static void red_char_device_client_free(RedCharDevice *dev,
> > > @@ -303,17 +288,14 @@ static void
> > > red_char_device_add_msg_to_client_queue(RedCharDeviceClient *dev_cli
> > >  PipeItem *msg)
> > >  {
> > >  RedCharDevice *dev = dev_client->dev;
> > > -RedCharDeviceMsgToClientItem *msg_item;
> > >  
> > > -if (dev_client->send_queue_size >= dev_client->max_send_queue_size) {
> > > +if (g_queue_get_length(dev_client->send_queue) >= dev_client
> > > ->max_send_queue_size) {
> > >  red_char_device_handle_client_overflow(dev_client);
> > >  return;
> > >  }
> > >  
> > > -msg_item = spice_new0(RedCharDeviceMsgToClientItem, 1);
> > > -msg_item->msg = pipe_item_ref(msg);
> > > -ring_add(_client->send_queue, _item->link);
> > > -dev_client->send_queue_size++;
> > > +pipe_item_ref(msg);
> > > +g_queue_push_head(dev_client->send_queue, msg);
> > >  if (!dev_client->wait_for_tokens_started) {
> > >  reds_core_timer_start(dev->priv->reds, dev_client
> > > ->wait_for_tokens_timer,
> > >RED_CHAR_DEVICE_WAIT_TOKENS_TIMEOUT);
> > > @@ -332,7 +314,7 @@ static void
> > > red_char_device_send_msg_to_clients(RedCharDevice *dev,
> > >  dev_client = SPICE_CONTAINEROF(item, RedCharDeviceClient, link);
> > >  if (red_char_device_can_send_to_client(dev_client)) {
> > >  dev_client->num_send_tokens--;
> > > -spice_assert(ring_is_empty(_client->send_queue));
> > > +spice_assert(g_queue_is_empty(dev_client->send_queue));
> > >  red_char_device_send_msg_to_client(dev, msg,
> > >  dev_client->client);
> > >  
> > >  

Re: [Spice-devel] [PATCH] fix 16 bpp LZ image decompression

[David Jaša]

On Čt, 2016-04-14 at 17:56 +0100, Frediano Ziglio wrote:
> LZ image decompression was broken for 16 bpp:
> - stride was computed not computed correctly (as width*4). This caused

IMO one extra 'computed' here.

>   also a buffer underflow;
> - stride in pixman is always multiple of 4 bytes (so for 16 bpp is
>   ALIGN(width*2, 4)) so image decompressed by lz_decode as some missing
>   bytes to be fixed.
> 
> The alignment code is reused from LZ4 function.
> 
> This fix also https://bugzilla.redhat.com/show_bug.cgi?id=1285469.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  common/canvas_base.c | 54 
> +++-
>  1 file changed, 32 insertions(+), 22 deletions(-)
> 
> diff --git a/common/canvas_base.c b/common/canvas_base.c
> index fa4d373..45dd75f 100644
> --- a/common/canvas_base.c
> +++ b/common/canvas_base.c
> @@ -515,13 +515,30 @@ static pixman_image_t *canvas_get_jpeg(CanvasBase 
> *canvas, SpiceImage *image)
>  return surface;
>  }
>  
> +static void canvas_fix_alignment(uint8_t *bits,
> + int stride_encoded, int stride_pixman,
> + int height)
> +{
> +if (stride_pixman > stride_encoded) {
> +// Fix the row alignment
> +int row;
> +uint8_t *dest = bits;
> +for (row = height - 1; row > 0; --row) {
> +uint32_t *dest_aligned, *dest_misaligned;
> +dest_aligned = (uint32_t *)(dest + stride_pixman*row);
> +dest_misaligned = (uint32_t*)(dest + stride_encoded*row);
> +memmove(dest_aligned, dest_misaligned, stride_encoded);
> +}
> +}
> +}
> +
>  #ifdef USE_LZ4
>  static pixman_image_t *canvas_get_lz4(CanvasBase *canvas, SpiceImage *image)
>  {
>  pixman_image_t *surface = NULL;
>  int dec_size, enc_size, available;
>  int stride, stride_abs, stride_encoded;
> -uint8_t *dest, *data, *data_end;
> +uint8_t *dest, *data, *data_end, *bits;
>  int width, height, top_down;
>  LZ4_streamDecode_t *stream;
>  uint8_t spice_format;
> @@ -576,6 +593,7 @@ static pixman_image_t *canvas_get_lz4(CanvasBase *canvas, 
> SpiceImage *image)
>  if (!top_down) {
>  dest -= (stride_abs * (height - 1));
>  }
> +bits = dest;
>  
>  do {
>  // Read next compressed block
> @@ -594,20 +612,7 @@ static pixman_image_t *canvas_get_lz4(CanvasBase 
> *canvas, SpiceImage *image)
>  data += enc_size;
>  } while (data < data_end);
>  
> -if (stride_abs > stride_encoded) {
> -// Fix the row alignment
> -int row;
> -dest = (uint8_t *)pixman_image_get_data(surface);
> -if (!top_down) {
> -dest -= (stride_abs * (height - 1));
> -}
> -for (row = height - 1; row > 0; --row) {
> -uint32_t *dest_aligned, *dest_misaligned;
> -dest_aligned = (uint32_t *)(dest + stride_abs*row);
> -dest_misaligned = (uint32_t*)(dest + stride_encoded*row);
> -memmove(dest_aligned, dest_misaligned, stride_encoded);
> -}
> -}
> +canvas_fix_alignment(bits, stride_encoded, stride_abs, height);
>  
>  LZ4_freeStreamDecode(stream);
>  return surface;
> @@ -782,7 +787,6 @@ static pixman_image_t *canvas_get_lz(CanvasBase *canvas, 
> SpiceImage *image,
>  uint8_t *comp_buf = NULL;
>  int comp_size;
>  uint8_t*decomp_buf = NULL;
> -uint8_t*src;
>  pixman_format_code_t pixman_format;
>  LzImageType type, as_type;
>  SpicePalette *palette;
> @@ -790,6 +794,7 @@ static pixman_image_t *canvas_get_lz(CanvasBase *canvas, 
> SpiceImage *image,
>  int width;
>  int height;
>  int top_down;
> +int stride_encoded;
>  int stride;
>  int free_palette;
>  
> @@ -818,10 +823,12 @@ static pixman_image_t *canvas_get_lz(CanvasBase 
> *canvas, SpiceImage *image,
>  lz_decode_begin(lz_data->lz, comp_buf, comp_size, ,
>  , , _comp_pixels, _down, palette);
>  
> +stride_encoded = width;
>  switch (type) {
>  case LZ_IMAGE_TYPE_RGBA:
>  as_type = LZ_IMAGE_TYPE_RGBA;
>  pixman_format = PIXMAN_LE_a8r8g8b8;
> +stride_encoded *= 4;
>  break;
>  case LZ_IMAGE_TYPE_RGB32:
>  case LZ_IMAGE_TYPE_RGB24:
> @@ -832,6 +839,7 @@ static pixman_image_t *canvas_get_lz(CanvasBase *canvas, 
> SpiceImage *image,
>  case LZ_IMAGE_TYPE_PLT8:
>  as_type = LZ_IMAGE_TYPE_RGB32;
>  pixman_format = PIXMAN_LE_x8r8g8b8;
> +stride_encoded *= 4;
>  break;
>  case LZ_IMAGE_TYPE_A8:
>  as_type = LZ_IMAGE_TYPE_A8;
> @@ -843,9 +851,11 @@ static pixman_image_t *canvas_get_lz(CanvasBase *canvas, 
> SpiceImage *image,
>   canvas->format == SPICE_SURFACE_FMT_32_ARGB)) {
>  as_type = LZ_IMAGE_TYPE_RGB32;
>  pixman_format = PIXMAN_LE_x8r8g8b8;
> +stride_encoded *= 4;
>  } else {

Re: [Spice-devel] [spice-common v3] use specific subdomains for better filtering

[David Jaša]

Hi, I like the approach a lot. It seems quite clear and nice to me,
but ...

On So, 2016-03-12 at 15:32 +0100, Victor Toso wrote:
> Hi! I've rebased this series and pushed to my remote branch in
> freedesktop [0] [1]. I'll try to clarify the ideia for working on this
> and if it does not get any positive feedback I'll take it as something
> not interesting to have...
> 
> [0] (common) https://cgit.freedesktop.org/~victortoso/spice-common/log/?h=logs
> [1] (gtk) https://cgit.freedesktop.org/~victortoso/spice-gtk/log/?h=logs
> fdo: https://bugs.freedesktop.org/show_bug.cgi?id=91838
> 
> So, first of all, I don't want to introduce something that everybody
> need to understand in order to get proper debug. The main idea is able
> to filter in/out stuff that you don't want to see without the need to
> | grep -v and | grep -i it.
> 
> With that said, SPICE_DEBUG=6 should work to get G_LOG_LEVEL_DEBUG of
> all code that uses spice logging functions.

... this essentially breaks compatibility in a bad way. IMO it has
already "sunk in" that G_MESSAGES_DEBUG=(GSpice|all) SPICE_DEBUG=1 means
all debug output from spice_gtk. Having just a trickle instead of
expected flood would be surprising.

I suggest adding a brief message when SPICE_DEBUG is set outlining the
new usage so that you don't have to bother with backwards compatibility
and users are warned.

The same would be suitable eventually for spice server when it's
SPICE_DEBUG_LEVEL-controlled debugging is replaced with a new one.

> With all debug enable you would see all lines prefixed with
> "[subdomain-name]" so, in case you don't want to see it (filter out),
> you could:
> 
> $SPICE_DEBUG=6,subdomain-name:- remote-viwer ...
> 
> And voilà, nothing from it will be showed as '-' is the same as '0'
> which is *no debug*. The opposite of it would be '*' or '6'.
> * Both '-' and 0 would work and "none" as well;
> * Both '*' and 6 would work and "debug" as well;
> 

+1 to Marc-André's suggestion to remove multiple choices.

> In case you only want to see some debug info, you could do something
> like:
> 
> SPICE_DEBUG=audio:*,playback:*
>
> This would show spice-audio, spice-gstaduio, spice-pulse,
> channel-playback debugs and nothing else.

I don't like asterisks because they need to be escaped in shell. For
subdomains, "all" would be IMO better and for log levels, highest
verbosity level should be sufficient. The highest level could be printed
in the logging overview message (and either taken out of the actual
code, or standardized in coding style to avoid surprises).

HTH,

David

> 
> Q: Do you want this just to avoid grep?
> A: No! We should not avoid inserting debug into the code because it
> could get verbose, we should smart handling it with something like this
> IMHO. We have a few #ifdef #DEBUG_THIS which is not useful when asking
> debug info to reporter in open bugs.
> 
> I really think that this could be improved a lot yet but it would need a
> proper discussion. If this does not seem useful, then it's fine :)
> 
> Another misc info:
> * I did not try this with spice server yet;
> * We can use spice logging tools or glib ones, I choosed spice first as
>   I think we can have better control with it;
> * I did not try to fix the spice-common tests yet;
> 
> changes from v2:
> * rebased to latest version upstream
> * Kept usage of SPICE_LOG_DOMAIN instead of G_LOG_DOMAIN that I
>   previously proposed
> * moved some changes that should be in another commit
> * changed the static variable from SPICE_LOG_DOMAIN to
>   SPICE_LOG_SUB_DOMAIN
> 
> changes from v1:
> * Use one-static-per-file approach to define each subdomain. This is
>   similar to how libvirt does and seems much cleaner.
> * Removed f(printf) debugs
> * Created subdomains for spice-common as well as now this is a must.
> 
> [spice-common]
> Victor Toso (6):
>   log: simplify log defines with SPICE_LOG
>   log: include message log level for parity with glib
>   log: allow filtering logs with subdomains
>   log: create specific subdomains for filtering
>   log: Disable multiple domains in Spice
>   don't break the build with this wip patches
> 
>  common/canvas_base.c  |   3 +-
>  common/canvas_utils.c |   1 +
>  common/log.c  | 174 
> ++
>  common/log.h  |  87 -
>  common/lz.c   |   2 +
>  common/marshaller.c   |   1 +
>  common/mem.c  |   1 +
>  common/pixman_utils.c |   1 +
>  common/quic.c |   4 +-
>  common/region.c   |   2 +
>  common/rop3.c |   4 +-
>  common/ssl_verify.c   |   3 +-
>  tests/test-logging.c  |   3 +-
>  13 files changed, 238 insertions(+), 48 deletions(-)
> 
> [spice-gtk]
> Victor Toso (13):
>   log: use glib logging on testing tools
>   log: use spice_debug instead of SPICE_DEBUG
>   log: nitpick at channel name in CHANNEL_DEBUG
>   log: remove unused SPICE_DEBUG
>   log: use spice_debug instead of g_debug
>   log: use spice_warning instead of 

Re: [Spice-devel] [spice-gtk v3 18/19] log: create subdomains for spice-gtk

[David Jaša]

Will it be possible to print all existing subdomains? Or would it be
hard to add?

On So, 2016-03-12 at 15:32 +0100, Victor Toso wrote:
> "audio"  : spice-audio.c spice-gstaudio.c spice-pulse.c
> "base"   : channel-base.c
> "channel": spice-channel.c
> "coroutine"  : coroutine_gthread.c coroutine_ucontext.c
>coroutine_winfibers.c
> "cursor" : channel-cursor.c
> "decode" : decode-glz.c decode-jpeg.c decode-zlib.c
> "display": channel-display.c channel-display-mjpeg.c
> "egl": spice-widget-egl.c
> "giopipe": giopipe.c
> "gtk-session": spice-gtk-session.c
> "input"  : channel-inputs.c
> "log": bio-gio.c continuation.c desktop-integration.c
>spice-option.c spice-grabsequence.c spice-uri.c
>spice-util.c
> "main"   : channel-main.c
> "playback"   : channel-playback.c
> "port"   : channel-port.c
> "record" : channel-record.c
> "session": spice-session.c
> "smartcard"  : channel-smartcard.c smartcard-manager.c
> "usbredir"   : channel-usbredir.c
> "usb": usb-device-manager.c usb-device-widget.c usbutil.c
>win-usb-dev.c win-usb-driver-install.c
> "vmcstream"  : vmcstream.c
> "vnc-keymap" : vncdisplaykeymap.c
> "webdav" : channel-webdav.c
> "widget" : spice-widget.c
> ---
>  src/Makefile.am| 3 +++
>  src/bio-gio.c  | 2 ++
>  src/channel-base.c | 2 ++
>  src/channel-cursor.c   | 2 ++
>  src/channel-display-mjpeg.c| 2 ++
>  src/channel-display.c  | 2 ++
>  src/channel-inputs.c   | 2 ++
>  src/channel-main.c | 2 ++
>  src/channel-playback.c | 2 ++
>  src/channel-port.c | 2 ++
>  src/channel-record.c   | 2 ++
>  src/channel-smartcard.c| 2 ++
>  src/channel-usbredir.c | 2 ++
>  src/channel-webdav.c   | 2 ++
>  src/coroutine_gthread.c| 2 ++
>  src/coroutine_ucontext.c   | 3 +++
>  src/coroutine_winfibers.c  | 3 +++
>  src/decode-glz.c   | 2 ++
>  src/decode-jpeg.c  | 2 ++
>  src/decode-zlib.c  | 2 ++
>  src/desktop-integration.c  | 2 ++
>  src/giopipe.c  | 3 +++
>  src/map-file   | 1 +
>  src/smartcard-manager.c| 2 ++
>  src/spice-audio.c  | 2 ++
>  src/spice-channel.c| 2 ++
>  src/spice-client-glib-usb-acl-helper.c | 3 +++
>  src/spice-common.h | 1 -
>  src/spice-grabsequence.c   | 1 +
>  src/spice-gstaudio.c   | 2 ++
>  src/spice-gtk-session.c| 2 ++
>  src/spice-option.c | 2 ++
>  src/spice-pulse.c  | 2 ++
>  src/spice-session.c| 2 ++
>  src/spice-uri.c| 2 ++
>  src/spice-util.c   | 2 ++
>  src/spice-util.h   | 1 -
>  src/spice-widget-egl.c | 2 ++
>  src/spice-widget.c | 2 ++
>  src/usb-device-manager.c   | 2 ++
>  src/usb-device-widget.c| 3 +++
>  src/usbutil.c  | 2 ++
>  src/vmcstream.c| 2 ++
>  src/vncdisplaykeymap.c | 2 ++
>  src/win-usb-dev.c  | 2 ++
>  src/win-usb-driver-install.c   | 2 ++
>  46 files changed, 92 insertions(+), 2 deletions(-)
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 68884e6..81eed02 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -420,6 +420,8 @@ spice_client_glib_usb_acl_helper_SOURCES =\
>   $(NULL)
>  
>  spice_client_glib_usb_acl_helper_LDADD = \
> + $(top_builddir)/spice-common/common/libspice-common.la  \
> + $(top_builddir)/spice-common/common/libspice-common-client.la   \
>   $(GLIB2_LIBS)   \
>   $(GIO_LIBS) \
>   $(POLKIT_LIBS)  \
> @@ -428,6 +430,7 @@ spice_client_glib_usb_acl_helper_LDADD =  \
>   $(NULL)
>  
>  spice_client_glib_usb_acl_helper_CPPFLAGS =  \
> + $(SPICE_COMMON_CPPFLAGS)\
>   $(SPICE_CFLAGS) \
>   $(GLIB2_CFLAGS) \
>   $(GIO_CFLAGS)   \
> diff --git a/src/bio-gio.c b/src/bio-gio.c
> index 04d6613..c8d2a89 100644
> --- a/src/bio-gio.c
> +++ b/src/bio-gio.c
> @@ -16,6 +16,8 @@
> License along with this library; if not, see 
> .
>  */
>  #include "config.h"
> +#include "common/log.h"
> +SPICE_LOG_DOMAIN_STATIC("log");
>  
>  #include 
>  #include 
> diff --git a/src/channel-base.c b/src/channel-base.c
> index 93609d4..67dc311 100644
> --- 

Re: [Spice-devel] spice udp support

[David Jaša]

On Út, 2016-02-02 at 10:24 +0100, Christophe Fergeau wrote:
> Hey,
> 
> On Tue, Feb 02, 2016 at 06:10:28PM +0900, Sunny Shin wrote:
> > I have a few questions about udp version of spice protocol.
> > 
> > Is there a plan to support udp in spice protocol?
> > 
> > If we support udp, what do we need to implement?
> > Is it enough to change tcp channels to udp ones?
> 
> Maybe that would be enough, maybe more changes would be needed, I cannot
> exactly tell you. My main worries with UDP would be packet drops as
> there is nothing guaranteeing you that the packets you send will arrive
> at all to the other end of the connexion.
> 
> > Would there be any benefits over tcp version? possibly better performance?
> 
> There would most likely be less overhead, but at the cost of not having
> guarantees of packet delivery, so I'm not sure how good this tradeoff
> would be..
> Experimenting with this sounds interesting though!

Yonit did some experiments with video streaming over UDP and there was
no performance gain IIRC.

David

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


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

[Spice-devel] Adaptive compression choice? [was: Re: [PATCH spice 1/3] dcc_compress_image: Handle NULL drawable]

[David Jaša]

Hi Frediano,

On Čt, 2016-01-14 at 12:52 -0500, Frediano Ziglio wrote:

> > 
> > On Thu, 2016-01-14 at 12:07 -0500, Frediano Ziglio wrote:
> > > > 
> > > > On Thu, Jan 14, 2016 at 10:27:02AM -0500, Frediano Ziglio wrote:
> > > > > Had a small discussion with Pavel.
> > > > > We agree that original code is quite complicated and is hard to
> > > > > understand
> > > > > the final compression format used.
> > > > > 
> > > > > So we would like to have some public discussion about the topic.
> > > > > 
> > > > > I personally agree we should have a single code deciding the
> > > > > compression
> > > > > to use.
> > > > 
> > > > I definitely agree here. For one, having different compression being
> > > > used depending on whether the qxl driver is used or not is unexpected
> > > > (eg if you set image compression to glz, lz will still be used during
> > > > initial bootup, and then will 'switch' to glz later on. I haven't looked
> > > > at the code, so there might be good reasons for that).
> > > > 
> > > > > 
> > > > > This is the list of actual compressions:
> > > > > - AUTO_GLZ;
> > > > > - AUTO_LZ;
> > > > > - QUIC;
> > > > > - GLZ;
> > > > > - LZ;
> > > > > - LZ4.
> > > > > A client can also decide to disable compression.
> > > > > 
> > > > > The AUTO_XXX looks like they should use QUIC as a fallback if XXX is
> > > > > not
> > > > > possible or if an image with high graduality is detected.
> > > > 
> > > > (side question, do we have numbers on compression ratio and cpu usage
> > > > for quic/lz/glz/lz4?)
> > > > 
> > > 
> > > Brief and raw of a Windows replay capture
> > > 
> > > Images  MB before   MB after  Ratio CPU time
> > > LZ4 193 24.21   2.43  10.04%0.04
> > > QUIC204 23.11   1.66   7.18%0.44
> > > GLZ 190 20.05   1.25.99%0.14
> > > LZ  202 20.42   2.04   9.99%0.15
> > > 
> > > So why use Quic ?
> > 
> > Interesting data. Indeed, QUIC seems to be the worst choice. from this data,
> > it
> > seems that you'd want GLZ if you were optimizing for network bandwidth, and
> > LZ4
> > if you're optimizing for CPU usage. Might be nice to see data for a slightly
> > larger sample as well.
> > 
> > Out of curiosity, did you write a little utility for doing this benchmark, 
> > or
> > did you just modify the code in-place?? Having a little benchmark utility
> > that
> > you could run on different replay captures might be a useful thing to have 
> > in
> > the repository...
> > 
> > Jonathon
> > 
> > 
> 
> No code modification at all. Compile with COMPRESS_STAT enabled, run replay
> utility with SPICE_DEBUG_LEVEL=3 set at the end you see a similar table
> (I added just ratio with LibreOffice calc).
> Oh... you just need to use -C replay option with
> - 4 quic
> - 5 glz
> - 6 lz
> - 7 lz4
> (not sure about 5/6, maybe swapped).


would you mind running with no compression so that we can get CPU
baseline? FWIW I've put inverted numbers to a chart (1/cpu time,
orig_size/compressed_size, so that greater number is better) and the
result is here:

You can imagine the numbers as a number of VMs you can squeeze into a
single host given a cpu/network constraint.

I was wondering, if the current code is indeed messy if it couldn't be
replaced with an adaptive algorithm e.g. starting with some "middle
ground" algorithm (LZ4 looks like the candidate) and move up if server
detects packet loss or move right if server can't compress images fast
enough...


> I think would be really helpful to collect different replay captures of
> normal day job.


IIRC VDI benchmark could be the tool to get such a capture.

David


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


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

Re: [Spice-devel] Clients, Nagle and net test

[David Jaša]

On Út, 2015-12-22 at 11:03 -0500, Frediano Ziglio wrote:
> Hi,
>   today I was trying to do some (quick) tests for the Glib code trying to 
> play with
> bandwidth and latency.
> 
> I noted that the net test was giving very strange results. With a delay of 
> 1ms and a
> bandwidth of 400kb/s was returning 325ms as roundtrip and a very high 
> bandwidth :(
> 
> After a bit of digging I realized that net test is done sending 3 pings 
> (using spice
> protocol)
> - 1 ping (warmup) of 0 byte data
> - 1 ping (latency) of 0 bytes
> - 1 ping (bandwidth) or 250 kb
> Ping messages contains a timestamp (usec) returned verbatim from the client.
> Doing a strace I noted that all ping replies were returned at the same time.
> Taking into account that items are queued in the stream quite fast and that
> roundtrip is compiled using current time - timestamp from ping reply this make
> basically the roundtrip computation equal to the total roundtrip of all pings
> so code thinks that latency is high and bandwidth (computed as data per extra 
> time
> after roundtrip) too.
> More strace, involving remote-viewer (Fedora 22 one) reveals that Nagle 
> algorithm
> on the client is not disabled to client queue replies to socket but kernel 
> send
> after all replies are queued giving the huge roundtrip!
> So at least while sending the ping replies Nagle algorithm should be disabled.
> I'm trying to mitigate this issue using Linux tcp information (see TCP_INFO on
> tcp(7) man page), the tcpi_rtt field. If a bit higher (133ms instead of 1ms)
> but better than 325ms.
> 
> Now, I'm not that used to client code and just enabling this flag could lead
> to excessive network packets sent to the server (potentially every byte).
> Somebody skilled with client code?
> 
> Frediano

IIRC Yonit was working at this very area before she left the project so
it might be useful to go through archives to gain some past thoughts
about the matter.

David

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

Re: [Spice-devel] [spice-common v2 1/7] log: Use glib for logging

[David Jaša]

On Po, 2015-11-30 at 12:56 +0100, Christophe Fergeau wrote:
> spice-common has been duplicating glib logging methods for a long while.
> Now that spice-common is depending on glib, it's more consistent to use
> glib logging too. However, the code base is still using spice logging
> functions.
> This commit aims to make spice logging go through glib logging system,
> while keeping the same behaviour for the SPICE_ABORT_LEVEL and
> SPICE_DEBUG_LEVEL environment variables. They are deprecated however in
> favour of the glib alternatives (G_DEBUG and G_MESSAGES_DEBUG).

What will be glib logging facility name, Spice like in spice-gtk?

> 
> Reviewed-by: Jonathon Jongsma 
> ---
> 
> Changes since v1:
> - fix glib fatal mask
> - use g_log_set_fatal_mask() rather g_log_set_always_fatal()
> 
>  common/log.c | 119 
> +--
>  common/log.h |   7 
>  2 files changed, 67 insertions(+), 59 deletions(-)
> 
> diff --git a/common/log.c b/common/log.c
> index fc5c129..aee6cc7 100644
> --- a/common/log.c
> +++ b/common/log.c
> @@ -1,5 +1,5 @@
>  /*
> -   Copyright (C) 2012 Red Hat, Inc.
> +   Copyright (C) 2012-2015 Red Hat, Inc.
>  
> This library is free software; you can redistribute it and/or
> modify it under the terms of the GNU Lesser General Public
> @@ -19,6 +19,7 @@
>  #include 
>  #endif
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,34 +33,6 @@
>  static int debug_level = -1;
>  static int abort_level = -1;
>  
> -static const char * spice_log_level_to_string(SpiceLogLevel level)
> -{
> -#ifdef _MSC_VER
> -/* MSVC++ does not implement C99 */
> -static const char *to_string[] = {
> - "ERROR",
> - "CRITICAL",
> - "Warning",
> - "Info",
> - "Debug"};
> -#else
> -static const char *to_string[] = {
> -[ SPICE_LOG_LEVEL_ERROR ] = "ERROR",
> -[ SPICE_LOG_LEVEL_CRITICAL ] = "CRITICAL",
> -[ SPICE_LOG_LEVEL_WARNING ] = "Warning",
> -[ SPICE_LOG_LEVEL_INFO ] = "Info",
> -[ SPICE_LOG_LEVEL_DEBUG ] = "Debug",
> -};
> -#endif
> -const char *str = NULL;
> - 
> -if (level < SPICE_N_ELEMENTS(to_string)) {
> -str = to_string[level];
> -}
> -
> -return str;
> -}
> -
>  #ifndef SPICE_ABORT_LEVEL_DEFAULT
>  #ifdef SPICE_DISABLE_ABORT
>  #define SPICE_ABORT_LEVEL_DEFAULT -1
> @@ -68,41 +41,83 @@ static const char * 
> spice_log_level_to_string(SpiceLogLevel level)
>  #endif
>  #endif
>  
> -void spice_logv(const char *log_domain,
> -SpiceLogLevel log_level,
> -const char *strloc,
> -const char *function,
> -const char *format,
> -va_list args)
> +static GLogLevelFlags spice_log_level_to_glib(SpiceLogLevel level)
> +{
> +static GLogLevelFlags glib_levels[] = {
> +[ SPICE_LOG_LEVEL_ERROR ] = G_LOG_LEVEL_ERROR,
> +[ SPICE_LOG_LEVEL_CRITICAL ] = G_LOG_LEVEL_CRITICAL,
> +[ SPICE_LOG_LEVEL_WARNING ] = G_LOG_LEVEL_WARNING,
> +[ SPICE_LOG_LEVEL_INFO ] = G_LOG_LEVEL_INFO,
> +[ SPICE_LOG_LEVEL_DEBUG ] = G_LOG_LEVEL_DEBUG,
> +};
> +g_return_val_if_fail ((level >= 0) || (level < 
> G_N_ELEMENTS(glib_levels)), 0);
> +
> +return glib_levels[level];
> +}
> +
> +static void spice_log_set_debug_level(void)
>  {
> -const char *level = spice_log_level_to_string(log_level);
> -
>  if (debug_level == -1) {
> -debug_level = getenv("SPICE_DEBUG_LEVEL") ? 
> atoi(getenv("SPICE_DEBUG_LEVEL")) : SPICE_LOG_LEVEL_WARNING;
> +char *debug_str = getenv("SPICE_DEBUG_LEVEL");
> +if (debug_str != NULL) {
> +g_warning("Setting SPICE_DEBUG_LEVEL is deprecated, use 
> G_MESSAGES_DEBUG instead");
> +debug_level = atoi(getenv("SPICE_DEBUG_LEVEL"));
> +g_setenv("G_MESSAGES_DEBUG", "all", FALSE);

So SPICE_DEBUG_LEVEL=1 will be effectively the same as SPICE_LOG_LEVEL=5
and in addition, everything else in qemu that uses glib logging will log
at most verbose level as well? (no idea if there are actual users but if
there is some verbose one...) That sounds like a fire hose...

David

> +} else {
> +debug_level = SPICE_LOG_LEVEL_WARNING;
> +}
>  }
> +}
> +
> +static void spice_log_set_abort_level(void)
> +{
>  if (abort_level == -1) {
> -abort_level = getenv("SPICE_ABORT_LEVEL") ? 
> atoi(getenv("SPICE_ABORT_LEVEL")) : SPICE_ABORT_LEVEL_DEFAULT;
> +char *abort_str = getenv("SPICE_ABORT_LEVEL");
> +if (abort_str != NULL) {
> +GLogLevelFlags glib_abort_level;
> +g_warning("Setting SPICE_ABORT_LEVEL is deprecated, use G_DEBUG 
> instead");
> +abort_level = atoi(getenv("SPICE_ABORT_LEVEL"));
> +glib_abort_level = spice_log_level_to_glib(abort_level);
> +if (glib_abort_level != 0) {
> +unsigned int fatal_mask = 

Re: [Spice-devel] [PATCH 1/1] channel: add optional tcp keepalive timeout to channels

[David Jaša]

Hi,

On Pá, 2015-11-27 at 14:45 +0900, Sunny Shin wrote:
> 
> 
> Hi,
> 
> 
> With firewall running between spice server and client, if idle time is
> larger than firewall session timeout, spice sessions freeze and users
> lose their keyboard and mouse control.
> 
> 
> To workaround this issue, I made a patch to add tcp keepalive timeout
> to spice server. 

cool!

However, I think that your configuration approach won't be accepted, the
proper way to set such a value would be addition of another option=value
pair to -spice parameter of qemu CLI (and associated element under
 element in libvirt - but I'd leave that to libvirt people
once qemu option gets in).

David

> The timeout can be added to qemu config like below.
>  xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
>   
> 
>   
> 
> 
> I wanted to add this option to spice client, but there was no
> setsockopt() option of TCP_KEEPIDLE for windows platform, So, I ended
> up adding it to spice server. Please review the patch and let me know
> what you think. Thank you.
> 
> 
> ---
> [PATCH 1/1] channel: add optional tcp keepalive timeout to channels
> 
> 
> Signed-off-by: Sunny Shin 
> ---
>  server/reds.c | 28 
>  1 file changed, 28 insertions(+)
> 
> 
> diff --git a/server/reds.c b/server/reds.c
> index 8b3c3cb..05d0b1d 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -2254,6 +2254,9 @@ static RedLinkInfo
> *reds_init_client_connection(int socket)
>  RedLinkInfo *link;
>  int delay_val = 1;
>  int flags;
> +char *keepalive_timeout_str;
> +int keepalive_timeout;
> +int keepalive = 1;
> 
> 
>  if ((flags = fcntl(socket, F_GETFL)) == -1) {
>  spice_warning("accept failed, %s", strerror(errno));
> @@ -2271,6 +2274,31 @@ static RedLinkInfo
> *reds_init_client_connection(int socket)
>  }
>  }
> 
> 
> +keepalive_timeout_str = getenv("SPICE_KEEPALIVE_TIMEOUT");
> +if (keepalive_timeout_str != NULL) {
> +errno = 0;
> +keepalive_timeout = strtol(keepalive_timeout_str, NULL, 10);
> +if (errno != 0) {
> +spice_warning("error parsing SPICE_KEEPALIVE_TIMEOUT: %
> s", strerror(errno));
> +goto error;
> +}
> +
> +spice_debug("keepalive timeout %ds", keepalive_timeout);
> +if (setsockopt(socket, SOL_SOCKET, SO_KEEPALIVE, ,
> sizeof(keepalive)) == -1) {
> +if (errno != ENOTSUP) {
> +spice_printerr("setsockopt for keepalive failed, %s",
> strerror(errno));
> +goto error;
> +}
> +}
> +if (setsockopt(socket, SOL_TCP, TCP_KEEPIDLE,
> +   _timeout, sizeof(keepalive_timeout))
> == -1) {
> +if (errno != ENOTSUP) {
> +spice_printerr("setsockopt for keepalive timeout
> failed, %s", strerror(errno));
> +goto error;
> +}
> +}
> +}
> +
>  link = spice_new0(RedLinkInfo, 1);
>  link->stream = reds_stream_new(socket);
> 
> 
> --
> 1.8.3.1
> 
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] [PATCH] canvas_utils: Remove trailing whitespace

[David Jaša]

On Čt, 2015-11-26 at 08:15 +0100, Pavel Grunt wrote:
> Hi Lukas,
> 
> can you get all of them?
> 
> Thanks,
> Pavel
> 
> On Wed, 2015-11-25 at 16:25 +0100, Lukas Venhoda wrote:
> > ---
> >  common/canvas_utils.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/common/canvas_utils.c b/common/canvas_utils.c
> > index 0d1591a..789cd76 100644
> > --- a/common/canvas_utils.c
> > +++ b/common/canvas_utils.c
> > @@ -293,7 +293,7 @@ pixman_image_t *alloc_lz_image_surface(LzDecodeUsrData
> > *canvas_data,
> >  
> >  /* pixman requires strides to be 4-byte aligned */
> >  stride = SPICE_ALIGN(stride, 4);
> > -
> > +
> >  if (!top_down) {
> >  stride = -stride;
> >  }
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

FWIW git grep helps here:

spice-common:
$ git grep -n '[[:space:]]\+$'
COPYING:58:^L
COPYING:114:^L
COPYING:161:^L
COPYING:219:^L
COPYING:270:^L
COPYING:332:^L
COPYING:373:^L
COPYING:425:^L
COPYING:459:^L
common/canvas_utils.c:296:
common/lines.c:930:^L
common/lines.c:978:^L
common/lines.c:1024:^L
common/lines.c:1069:^L
common/lines.c:1114:^L
common/log.c:55: 
common/log.c:79:
common/sw_canvas.c:98:

spice-gtk, spice: good (just those ^L's in COPYING)

libcacard: 
COPYING:149:  

usbredir:
$ git grep -In '[[:space:]]\+$' 
COPYING.LIB:58:^L
COPYING.LIB:114:^L
COPYING.LIB:161:^L
COPYING.LIB:219:^L
COPYING.LIB:270:^L
COPYING.LIB:332:^L
COPYING.LIB:373:^L
COPYING.LIB:425:^L
COPYING.LIB:459:^L
ChangeLog:79:-Windows support 
usb-redirection-protocol.txt:264:usb_redir_cap_bulk_streams, 
usb-redirection-protocol.txt:732:uint8_t endpoint;  
usbredirhost/usbredirhost.c:309:case LIBUSB_ERROR_INVALID_PARAM: 
usbredirhost/usbredirhost.c:1345:}  
usbredirparser/usbredirparser.c:95:
usbredirparser/usbredirparser.c:305:
usbredirparser/usbredirparser.c:1060:for (;;) {
usbredirparser/usbredirparser.c:1728:if (type_header_len < 0 || 
usbredirparser/usbredirparser.c:1729:type_header_len > 
sizeof(parser->type_header) || 
usbredirparser/usbredirproto.h:119:usb_redir_cap_bulk_streams, 
usbredirparser/usbredirproto.h:141:uint64_t id;  
usbredirparser/usbredirproto.h:267:uint16_t length; 
usbredirserver/usbredirserver.1:36:.br 
usbredirserver/usbredirserver.c:285:
  
usbredirtestclient/usbredirtestclient.c:381:if (!(control_packet.endpoint & 
0x80)) {

cheers,

David

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

Re: [Spice-devel] missing spicec client

[David Jaša]

Zdravím,

On Po, 2015-11-23 at 15:15 +0100, Fabiano Fidêncio wrote:
> On Sun, Nov 22, 2015 at 5:48 PM, Martin Filo
>  wrote:
> > Hello,
> >
> > Spicec has been best spice client. It has nice user interface, no
> > annoying toolbar or icons, it has hotkeys for ungrab mouse and
> > fullscreen. Everything needed can be configured via command line. And it
> > hasn't much dependencies.
> > But Spicec has been removed as obsolete in spice 0.12.6. What is a
> > replacement for it?
> >
> > I tried spice-gtk, but for these reasons it's a worse client:
> > - My virtualization host has installed minimal needed set of programs. I
> > need install gtk libraries only for this one program there (which is a
> > small minus for spicy).
> > - It has (for me) a useless toolbar which only consumes space on my
> > screen. Hotkey for showing/hiding it will be nice.
> > - But much worse is that I can't ungrab mouse when I click on its
> > window. I tried google for finding hotkey to ungrab mouse but I didn't
> > find anything. Only way to ungrab mouse is to halt guest, which makes
> > this client absolutely useless.
> >
> > I tried virt-viewer too
> > - It depends on spice-gtk, gtk2, gtk3 and many other libraries
> > - It can't run because I am not using libvirt.
> 
> Please, try remote-viewer (part of virt-viewer package).
> 
> >
> > So spicec has been obsolete without replacement. I need simple spice
> > client which can connect to address and port specified via command line,

remote-viewer spice://host:port/

> > with hotkeys for ungrab mouse and fullscreen. 

ctrl+alt and F11 (when you have focus out of canvas). You can get
shift-F1[12] as you're used to if you launch the client using .vv file
(hm, it would make sense to mirror the .vv file configuration options in
--spice-* CLI options 1:1 ...)

> It would be nice if it
> > didn't have too many dependencies similar to spicec.

I you're fine building yourself, you should be able to get remote-viewer
without libvirt dependencies. You won't be able to get rid of gtk
dependencies however, achieving that would mean writing a new client on
top of spice-glib (which did Iordan Iordanov in hist aSpice Android
client) or just spice-protocol (which some KDE people tried to to create
qtspice library but left project after short time).

David

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


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

Re: [Spice-devel] [PATCH] log: add not fatal spice_return function

[David Jaša]

On Pá, 2015-11-20 at 16:26 +0100, Francois Gouget wrote:
> On Thu, 19 Nov 2015, Frediano Ziglio wrote:
> [...]
> > > What do you mean by "100% compatible with the current code"? (why is
> > > g_return_if-fail() not "100% compatible with the current code" ?)
> > 
> > well... implementation is quite different. I didn't get all differences but
> > - spice_logv use some environment SPICE_* specific (I doubt Glib does!);
> > - Glib output on standard error or output based on level;
> > - surely something I forgot!
> 
> Does it matter?
> The client uses the g_return_xxx() functions already. Would it be a 
> problem if the server did too instead of going its separate way?
> 

Without accompanying modification, yes. Users are taught that
spice-server logging is controlled by SPICE_DEBUG_LEVEL environment
variable. Glib debugging is controlled differently so if you just start
mixing spice_* and g_* logging functions, users will start silently
losing some debugging information...

So from users' perspective, switch to glib logging style should either
be atomic & properly announced, or gradual with something that would
turn on glib logging according to SPICE_DEBUG_LEVEL setting.

Note that client logging is not relevant here as spice-gtk follows glib
style since its inception, unlike spice-server.

David

> 
> > Didn't investigate so deep to be able to tell all list but surely just 
> > with these I'm not comfortable to do a sed and release tomorrow...
> 
> Let me summarize. Currently we have:
> 
> 1. Plain old and trustworthy assert().
>Used by server/dispatcher.c.
> 
> 2. g_return_if_fail() which does not log the way spice functions do.
>Used by server/reds_stream.c and most of the client code.
> 
> 3. spice_assert() which crashes the application.
>Used by most of the server code but not by the client.
> 
> 4. spice_return_if_fail() which claims to return but instead crashes the 
>application, exactly like spice_assert().
>Also used in most of the server code but not by the client.
> 
> 5. And you propose adding spice_return_if_fail_warning() to fix this mess.
> 
> I really don't see how adding more functions is going to make this less 
> confusing and error prone! Particularly if there is not a concerted 
> and swift effort to clean up the old code.
> 
> Not fixing spice_return_if_fail() does not make any sense either (yes, a 
> functions that crashes the application under the guise of returning to 
> the caller is *totally* buggy).
> 
> The code calling spice_return_if_fail() was written under the assumption 
> that it would return. So just switch the default 
> SPICE_ABORT_LEVEL_DEFAULT to SPICE_LOG_LEVEL_ERROR.
> 
> But it would also really help if the different Spice pieces like the 
> server and client could agree on whether to use glib functions or not.
> 
> 
> Note that spice_error() needs to be fixed too. That name implies the 
> function logs an error just like spice_warning() logs a warning, not 
> that it crashes the application. spice_error() should be renamed to 
> spice_fatal(). For consistency it might make sense to rename 
> SPICE_LOG_LEVEL_ERROR to SPICE_LOG_LEVEL_FATAL.
> 
> 
> 
> Then there's memory handling where we see the same issues yet again:
> 
> 1. malloc() & co.
>Used in server/red_replay_qxl.c and some lz encoders.
> 
> 2. spice_malloc() & co.
>Used by most of the server code but not by the client.
> 
> 3. g_malloc() & co.
>Use by most of spice-gtk and but only a test file on the server!
> 
> 
> This duplication of basic functionality needs to stop. It's confusing 
> and can only lead to bugs. Nobody wants to track for each pointer 
> whether it should be freed with free(), g_free() or the nonexistent 
> spice_free()!
> 
>  
> > Calling spice_* functions instead of spice_* functions looks like 100% 
> > compatible :)
> 
> I'm not very impressed by this argument. Do you mean that, just because 
> they both start with 'spice_', spice_assert() and spice_strndup() are 
> interchangeable?
> 
> 


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

[Spice-devel] mention use of g_slice in server release notes

[David Jaša]

Hi,

I noticed in patches that g_slice* is being introduced to spice-server
code. Please mention it in release notes because it has implications for
debugging (namely need to set G_SLICE=(debug_blocks|always_malloc)
depending on problem type in code that uses g_slice).

David

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

Re: [Spice-devel] [ovirt-users] console viewing failure after moving engine from CO6 to CO7

[David Jaša]

Hi,

On Pá, 2015-11-06 at 19:53 +, Weber, Charles (NIH/NIA/IRP) [E]
wrote:
> Hi everyone, 
> I have been moving production Ovirt cluster 4 host+1 engine+FC storage
> from CentOS 6 to CentOS 7.
> I created new cluster with CO7 nodes and did the usual transition
> without any major issues.
> This took care of nodes and worked very well.
> I then used the engine backup/restore utility to move engine from old
> server running CO6 to new server running CO7.
> There were the some issues but fairly easily fixed. Mostly CO6 to CO7
> stuff like NFS, firewalld etc. To be expected.
> 
> 
> However, my web proxy did work with the engine on CO6 and now does
> not. Local engine console viewer did work on CO6 and now does not. 
> 1.  Hostname is the same
> 2. errors are different that cert errors
> 3. restore util should have moved the certs
> 4. firewall rules are the same as before running iptables
> 
> Here are the errors when console is set for novice or spice html5. In
> both cases web page opens up with black screen and then the error
> occurs.
> novnc
> ReferenceError: can’t find variable:WebUtil
> spice
> Error: Unexpected protocol mismatch
> 

Just trying luck as I have next to none hands-on experience: Could it be
spice/vnc protocol mismatch as opposed to websockets protocol mismatch?
What do websocket proxy logs say?

Adding spice-devel list to the loop as well.

David

> 
> I tried older websockify, no change.
> 
> 
> Overt Versions before and after engine move were 3.5.5-1
> Current CentOS 7.1.1503
> 
> 
> python-websockify.noarch   0.6.0-2.el7  @epel
> novnc.noarch 0.5.1-2.el7@epel
> spice-glib.x86_64  0.22-2.el7   @base
> spice-gtk3.x86_640.22-2.el7 @base
> spice-html5.noarch0.1.6-1.el7   @epel
> spice-server.x86_64  0.12.4-9.el7_1.3@updates 
> spice-vdagent.x86_64 0.14.0-9.el7  @base 
> ovirt-engine.noarch  3.5.5-1.el7.centos   @ovirt-3.5
> ovirt-engine-backend.noarch 3.5.5-1.el7.centos   @ovirt-3.5
> ovirt-engine-cli.noarch 3.5.0.6-1.el7.centos
> @ovirt-3.5
> ovirt-engine-dbscripts.noarch  3.5.5-1.el7.centos @ovirt-3.5
> ovirt-engine-extensions-api-impl.noarch  3.5.5-1.el7.centos
>  @ovirt-3.5
> ovirt-engine-jboss-as.x86_64 7.1.1-1.el7 @ovirt-3.5
> ovirt-engine-lib.noarch   3.5.5-1.el7.centos @ovirt-3.5
> ovirt-engine-restapi.noarch  3.5.5-1.el7.centos   @ovirt-3.5
> ovirt-engine-sdk-python.noarch3.5.5.0-1.el7.centos
>  @ovirt-3.5
> ovirt-engine-setup.noarch 3.5.5-1.el7.centos   @ovirt-3.5
> ovirt-engine-setup-base.noarch 3.5.5-1.el7.centos@ovirt-3.5
> ovirt-engine-setup-plugin-ovirt-engine.noarch3.5.5-1.el7.centos
>   @ovirt-3.5
> ovirt-engine-setup-plugin-ovirt-engine-common.noarch
>   3.5.5-1.el7.centos @ovirt-3.5
> ovirt-engine-setup-plugin-websocket-proxy.noarch
>  3.5.5-1.el7.centos@ovirt-3.5
> ovirt-engine-tools.noarch3.5.5-1.el7.centos@ovirt-3.5
> ovirt-engine-userportal.noarch3.5.5-1.el7.centos@ovirt-3.5
> ovirt-engine-webadmin-portal.noarch3.5.5-1.el7.centos
>   @ovirt-3.5
> ovirt-engine-websocket-proxy.noarch3.5.5-1.el7.centos
> @ovirt-3.5
> 
> 
> 
> 
> ## IP address below in socket proxy status (XXX…) is the workstation I
> am testing from. ##
> 
> 
> [root@ovirtman yum.repos.d]# systemctl status ovirt-websocket-proxy -l
> ovirt-websocket-proxy.service - oVirt Engine websockets proxy
>Loaded: loaded
> (/usr/lib/systemd/system/ovirt-websocket-proxy.service; enabled)
>Active: active (running) since Tue 2015-11-03 13:10:07 EST; 22h ago
>  Main PID: 1178 (ovirt-websocket)
>CGroup: /system.slice/ovirt-websocket-proxy.service
> 
> └─1178 /usr/bin/python 
> /usr/share/ovirt-engine/services/ovirt-websocket-proxy/ovirt-websocket-proxy.py
>  --systemd=notify start
> 
> 
> Nov 03 13:10:06 ovirtman.irp.nia.nih.gov systemd[1]: Starting oVirt
> Engine websockets proxy...
> Nov 03 13:10:07 ovirtman.irp.nia.nih.gov systemd[1]: Started oVirt
> Engine websockets proxy.
> Nov 04
> 11:13:39 ovirtman.irp.nia.nih.gov ovirt-websocket-proxy.py[1178]:
> XXX.XXX.XXX.XXX - - [04/Nov/2015 11:13:39] XXX.XXX.XXX.XXX: SSL/TLS
> (wss://) WebSocket connection
> Nov 04
> 11:13:39 ovirtman.irp.nia.nih.gov ovirt-websocket-proxy.py[1178]: 
> XXX.XXX.XXX.XXX - - [04/Nov/2015 11:13:39] XXX.XXX.XXX.XXX  Version hybi-13, 
> base64: 'False'
> Nov 04
> 11:13:39 ovirtman.irp.nia.nih.gov ovirt-websocket-proxy.py[1178]: 
> XXX.XXX.XXX.XXX - - [04/Nov/2015 11:13:39] XXX.XXX.XXX.XXX  Path: 
> 

Re: [Spice-devel] [RFC PATCH] [linux-vdagent] Lock screen on disconnect

[David Jaša]

On Pá, 2015-09-25 at 10:13 +0200, Victor Toso wrote:
> Hi David,
> 
> On Thu, Sep 24, 2015 at 01:21:53PM -0400, David Mansfield wrote:
> > On 09/24/2015 12:46 PM, Victor Toso wrote:
> > >Not sure if I agree with the idea for vdagent... But it would need to be
> > >configurable by client-side IMHO. As Michal point out, the _security_
> > >when accesing remote VMs should be in the connection not _after_.
> > >
> > >Meaning: If one person can connect to the VM without permission, that's
> > >bad already, right?
> >
> > I think there's a misunderstanding here - relevant users DO have to have
> > permission to connect to the machine. It's possible (but far from easy BTW)
> > to restrict them from being able to access when another user is connected.
> > So far so good.
> >
> > However, if a user disconnects (or is unexpectedly disconnected forcefully
> > which can happen for a myriad of reasons beyond his/her control) and forgets
> > to logout or lock screen, then there is no way to prevent the next user of
> > the machine from connecting and seeing the other user's session.
> >
> > Let's flip this around. Can anyone justify why a session should remain
> > unlocked when no-one is connected to the VM? It seems like a pretty big
> > security hole unless there's some way of forcing one-user-per-machine.
> >
> 
> Understanding how RHEVM/ovirt does it would probably be a better
> solution.
> 

This.

The very functionality David requests is implemented in oVirt guest
agent. If the functionality is desired from other KVM users
(openstack, ...), maybe this is a good opportunity to move the lock
screen functionality to qemu guest agent (qemu-ga).

CCing Vinzenz who maintains ovirt-guest-agent for insight...

Regards,

David

> I'm not against your request (I'm happy with patches actually). I'm not
> sure you will achieve the security you seek by tyring to lock the screen
> with vdagent.
> 
> > If the view of the spice team (or perhaps the RHEL and Fedora teams) is "any
> > use of a VM by more than one user is inherently insecure but out of the box
> > that's how we configure it" then I think there are other issues that need to
> > be addressed. I personally don't think that use of a VM by more than one
> > user is inherently insecure, provided the sessions get locked when the
> > disconnect occurs (and yes, this SHOULD apply to consoles as well, but first
> > things first).
> >
> 
> This is just my opinion, really.
> 
> >
> > >
> > >>3) Is there any point checking the exit status of the lock command? (me: 
> > >>NO)
> > >
> > >why not?
> >
> > The user has disconnected so we can't show a message to the user, we can't
> > "fail the disconnect". What can actually be done here?  It could be logged I
> > suppose.  Can you suggest any steps that should be taken?
> >
> 
> Yeah, the problem is that if it fails for some reason you still would
> have the issues you want to address... Logging at least is a must.
> 
> > >
> > >>4) Should the lock command be configurable? (me: grumble)
> > >
> > >yes, preferable client-side
> >
> > Ok.  That sounds somewhat reasonable: remote-viewer
> > --lock-session-on-disconnect --lock-session-command="xdg-screensaver lock"
> > spice://blah
> >
> > (Or from the .ini file read by the remote-viewer).
> >
> > How do we negotiate arbitrary or new options between the remote-viewer and
> > the running agent? Any pointers?
> 
> Sure. The last protocol change + vdagent was due volume synchronization
> 
> linux-vdagent:
> http://cgit.freedesktop.org/spice/linux/vd_agent/commit/?id=9b0eb8b1246ccb422ccecc3679b0bb6b477ba6cb
> spice-gtk:
> http://cgit.freedesktop.org/spice/spice-gtk/commit/?id=8c50e1a2b9f243a7da9b538cc1438b6a9d8e5671
> spice-protocol:
> http://cgit.freedesktop.org/spice/spice-protocol/commit/?id=9acfaa66df90cb1475db7c09da09b6e9b5f5dd00
> 
> >
> > >
> > >>diff -ur spice-vdagent-0.15.0.orig/src/vdagent-x11.c 
> > >>spice-vdagent-0.15.0/src/vdagent-x11.c
> > >>--- spice-vdagent-0.15.0.orig/src/vdagent-x11.c   2013-10-14 
> > >>08:52:01.0 -0400
> > >>+++ spice-vdagent-0.15.0/src/vdagent-x11.c2015-09-23 
> > >>09:46:00.166210785 -0400
> > >>@@ -1308,11 +1308,17 @@
> > >>  void vdagent_x11_client_disconnected(struct vdagent_x11 *x11)
> > >>  {
> > >>  int sel;
> > >>+int status;
> > >>
> > >>  for (sel = 0; sel < VD_AGENT_CLIPBOARD_SELECTION_SECONDARY; sel++) {
> > >>  if (x11->clipboard_owner[sel] == owner_client)
> > >>  vdagent_x11_clipboard_release(x11, sel);
> > >>  }
> > >>+
> > >>+status = system("xdg-screensaver lock");
> > >>+if (status != 0) {
> > >>+/* exit status is not checked */
> > >>+}
> > >>  }
> > >>
> > >>  /* Function used to determine the default location to save file-xfers,
> >
> > Thanks,
> > David
> 
> cheers,
>   Victor Toso
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] keypress-delay issue

[David Jaša]

On Čt, 2015-06-25 at 00:28 -0700, Jared Kwek wrote:
 On Tue, Jun 23, 2015 at 4:14 PM, Marc-André Lureau mlur...@redhat.com wrote:
 
 
  It's interesting that I can barely notice the lag, and possibly most
  people, judging by the amount of people complaining.
 
 While true that the lag is barely noticeable, the fact is that it is
 there and more noticeable to some people than others.
 
 
 
  This was introduced to solve a real problem though, to avoid spurious
  software key repeat on guest side. This is particularly annoying with
  remote guest with a lag of several 100's of ms, but could also happen
  locally if the VM get stuck due to scheduling.
 
 
 I also understand the problem you were trying to solve, as it is a
 common issue in remote desktop situations.  But instead of a
 one-size-fits-all solution, I'm advocating for a configurable value
 since different values make sense in different situations.  If my
 desktop is on a VM on my local machine, it would be a better user
 experience for me to turn down compression, keypress delays, etc.
 rather than use the same settings as if my desktop were streaming
 across a slow network connection.
 
 
  I am not sure more tweaking should be advertised, as this is fairly
  obscure and could reopen the issue I was trying to solve. Instead I
  wish we would have a better/more clever solution to this issue.
  Unfortunately, I don't have good one, adjusting the latency
  based on local vs remote measurements would still let spurious
  key repeats on slow scheduling, is this a better tradeoff?
 
 
 I don't think adjusting the latency based on measurements would be a
 good alternative unless it could be done with confidence in those
 measurements.  I think an easier method would be to set the
 keypress-delay to a sane value by default and allow it as a
 configuration item in case a person wants to tweak it.  Similar to how
 compression works now with the SPICE protocol...

IIRC the compression is set on connection initialization based on b/w
measurement so this analogy supports Marc-André's approach more. (I can
see that latency measurement is trickier than b/w).

David

 most people don't
 change the defaults but those that want to have the option to do so.
 
 With the risk of generalizing too much, I value the fact that most
 open source software packages are more configurable than their
 commercial counterparts.  Having more options to tweak if I desire
 allows me to tailor the software to my specific use case.
 
 Thanks for considering my suggestions.
 
 Regards,
 Jared Kwek
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] spice opengl

[David Jaša]

On Čt, 2015-05-21 at 12:00 +0800, 395459...@qq.com wrote:
 hi
 My arm board cpu is HI3716v200,and acoording to the datesheet:
 
   Hi3716CV200/Hi3719CV100/Hi3718CV100/Hi3719MV100/Hi3718MV100/Hi3716MV400 集成高
 性能 Mali GPU，完成 3D 图形和视频处理功能。
 Hi3716CV200/Hi3719CV100/Hi3718CV100 集成高性能 4 核 Mali GPU；
 Hi3719MV100/Hi3718MV100 只集成高性能双核 Mali GPU。
 Hi3716MV400 只集成高性能单核 Mali GPU。
 1600Pixels/s 处理能力
 支持 OpenGL ES 2.0/1.1/1.0
 支持 OpenVG 1.1
 When i use spice, how to use opengl to impove the preformance,can or
 can not ,can you tell me?thank you!!!

Spice does not use OpenGL in any way.

David

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


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

Re: [Spice-devel] Cac redirection through spice client

[David Jaša]

On Út, 2015-05-19 at 15:59 +0200, David Jaša wrote:
 On Út, 2015-05-19 at 09:00 -0400, Thomas Foster wrote:
  David,
  
  While using the spice client have you put your cac into your local
  reader?  If so, we're you able to use it?  I ask because if you look
  at my screenshots from my last email I get the same usb device
  (usbccid), but I also get an extra device that is a problem.
  
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 Hm, I think I start understanding your situation: you're using linux
 client (CentOS 7?), Windows 7 guest and the smart card doesn't work
 for you. When you write drivers in spice client you actually mean
 drivers for client OS. That's card-dependent. You need to have a
 smart card middleware installed in the system and registered in nss,
 e.g.:
 
 $ modutil -dbdir /etc/pki/nssdb -list
 
 Listing of PKCS #11 Modules
 ---
   1. NSS Internal PKCS #11 Module
slots: 2 slots attached
   status: loaded
 
slot: NSS Internal Cryptographic Services
   token: NSS Generic Crypto Services
 
slot: NSS User Private Key and Certificate Services
   token: NSS Certificate DB
 
   2. CoolKey PKCS #11 Module
   library name: libcoolkeypk11.so
slots: 1 slot attached
   status: loaded
 
slot: Gemalto PC Twin Reader 00 00
   token: spice qe
 
   3. p11-kit
   library name: /usr/lib64/pkcs11/p11-kit-trust.so
slots: 2 slots attached
   status: loaded
 
slot: /etc/pki/ca-trust/source
   token: System Trust
 
slot: /usr/share/pki/ca-trust-source
   token: Default Trust
 ---
 
 Module 2. is the one that provides my smartcard, slot: Gemalto PC
 Twin Reader 00 00 is my physical card reader, . Coolkey is not
 however officially sanctioned in windows (although unofficial builds
 exist) 

So official builds exist as well but you'd need a Red Hat Certificate
System subscription in order to access them:
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Managing_Smart_Cards_with_the_Enterprise_Security_Client/install-windows.html

David

 so if you intend to use the card in Windows, you'll need a different
 middleware for it and possibly, you'll need to register it to nss by
 hand:
 
 # modutil -dbdir /etc/pki/nssdb -add some name for your pkcs#11 module 
 -libfile /usr/lib64/pkcs11/your_fancy_p11_library.so
 
 once done, the spice client will pick up the card automatically and
 it will show up in the working card reader in Windows with no further
 configuration.
 Alternatively, if your card doesn't have linux drivers (or it needs to
 be formatted by some Windows tool to a format specific for that
 tool...), the option for you is to use USB redirection of the whole
 card reader:
 
 Then the card won't be obviously available in the client OS but that's
 kind of irrelevant if it's format need to be incompatible with the
 client OS anyway.
 Please note also that I had to stop and mask pcscd in the client
 system in order to make the reader redirect. Note also that you'll
 need the driver for the physical reader in the guest OS in this
 scenario (the Gemalto driver for my card reader was also available
 through Windows update). The card was not recognized in my case
 beacause it's CoolKey/RHCS-formatted which would need the driver
 linked above in Windows:
 
 
 HTH,
 
 David 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] Cac redirection through spice client

[David Jaša]

Thomas,

I don't understand your issue/question. I'll write a few notes about
smart card sharing architecture in spice so that we're at the same page
regarding terminology:

  * in Client system, remote-viewer accesses the smart card using
pkcs#11 module (library) that has to be registered in NSS
library database
  * the data is transferred over the network to spice-server which
transfers them to qemu which shares them via emulated smart card
reader. The emulated card reader needs the drivers (in the
Windows guest) and the card itself may require drivers as well
  * if your client OS and guest OS are of the same kind, the
configuration required in guest OS to make card accessible for
programs is the same as in your client OS

What I don't understand are your mentions of spice client complaining
about incorrect drivers - I'd expect such messages being produced by
Windows running in the guest. Would you mind sharing a screenshot, or
describing your setup in greater detail (or the steps you did so far)?

David

On Čt, 2015-05-14 at 05:42 -0400, Thomas Foster wrote:

 Can somebody help me understand where to put the driver for Cac
 redirection for the spice client?
 
 The problem:  When placing cac in card reader, spice client recognizes
 the card but states the drivers were not installed correctly.  In
 windows there is the usbccid cac reader (which works with rdp) and the
 spice redirected cac reader (which shows up as a device without the
 drivers).  I have attempted to install the drivers on the windows 7 vm
 to no avail.  So, I was wondering does the driver have to be installed
 on the system I am running the spice client?
 
 Thanks in advance!
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] about mouse on multi monitor for you help

[David Jaša]

On Po, 2015-05-11 at 15:51 +0300, Uri Lublin wrote:
 On 05/08/2015 09:05 AM, 张阳 wrote:
  hi spice admin:
  I am a spice user form china.
  Now I have a problem ,when we set multi monitor for windows xp VM by
  spice, the mouse on the VM's second monitor cann't be ctrl or moving or
  click.all operation on the second monitor will be  take effect  on the
  first moitor.
  what should i do about this problem?
  thank you for your help~
 
 Hi,
 
 Is spice vdagent installed on your guest ?
 
 Uri.

I see this behaviour for quite some time already. Ctrl modifier isn't
passed on to the guest when the mouse cursor is outside of spice canvas.
You won't notice in single-monitor fullscreen guest but in 张阳's case
or just when using plain windowed guest, it's pretty noticeable...

David

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


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

Re: [Spice-devel] vdagent service is not running

[David Jaša]

Zdravím,

Please have a look at Device manager if virtio-serial driver is
installed and working. vdservice exits when it can't open the spice
virtio port.

David


On St, 2015-05-06 at 12:03 +0200, Michal Suchanek wrote:
 Hello,
 
 I installed the spice guest tools on Windows 7 - the exe installer from
 spice-space.org.
 
 The vdagent service is not running. When I start it it stops.
 
 How do I debug this?
 
 Thanks
 
 Michal
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] USB redirection

[David Jaša]

On Ne, 2015-05-03 at 21:33 +, Klaus Hochlehnert wrote:
 Hi,
 
  
 
 is it actually possible to connect the spice USB redirection to an
 USB3.0 controller instead of the ICH9 USB2.0?

It is. I didn't see any problem with spice usage, I however noticed
smartcard not working with nec-xhci controller:
https://bugzilla.redhat.com/show_bug.cgi?id=1211970

 
 Not sure, but I would assume less CPU usage?
 

I didn't focus on CPU so I can't really tell.

David

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


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

Re: [Spice-devel] [virt-tools] Feature Request - Secure clipboard

[David Jaša]

Wouldn't it be possible to achieve something very close with lazy
transfer of CP data only after paste event? In that case, when you'd
copy something in source VM, it would be available in there and in
client but it would get copied to guest's clipboard only if you switch
to there and paste there using ctrl+V.

David

On Ne, 2015-04-26 at 17:52 +0200, gra...@ruggedinbox.com wrote:
 A secure clipboard is nice to have becuase there's no tradeoff between
 convenience and safety. A vm can read the global clipboard only when you
 want it. The Xen based Qubes has it and I don't see why KVM's spice and
 libvirt can't. Here is how they did it:
 
 
 slide 10 from
 
 https://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_2014_Qubes_Tutorial.pdf
 
 Challenge: copy clipboard from VM “Alice” to VM “Bob”, don’t let VM
 “Mallory” to learn
 its content in the meantime
 
 Solved by introducing Qubes “global clipboard” to/from which copy/paste is
 explicitly
 controlled by the user (Ctrl-Shift-C, Ctrl-Shift-V)
 
 Requires 4 stages:
 Ctrl-C (in the source VM)
 Ctrl-Shift-C (tells Qubes: copy this VM buffer into global clipboard)
 Ctrl-Shift-V (in the destination VM: tells Qubes: make global clipboard
 available to this VM)
 Ctrl-V (in the destination VM)
 Ctrl-Shift-C/V cannot be injected by VMs (unspoofable key combo).
 
 In practice almost as fast as traditional 2-stage copy-paste (don’t freak
 out! ;)
 
 
 More technical explanation
 
 https://www.qubes-os.org/doc/CopyPaste/
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] [ovirt-users] I have a question about the spice client.

[David Jaša]

Hi,

What is hangul key? Do I understand correctly that linux client works OK
but windows client behaves incorrectly?

David

On Po, 2015-01-12 at 15:51 +0900, jaemin baek wrote:
 hi, 
 
 i'm korean
 
 
 I have a question about the spice client.
 
 
 
 My spice client connect to VDI  Windows 7 VDI
 
 
 input key --- Korea keyboard(103/106 key) + hangul key   --- windows
 7 IME
 
 
 but...
 
 
 input key --- Korea keyboard(103/106 key) + hangul key -- hangul key
 exchanged --- Alt key
 
 
 Why??
 
 
 linux spice client Hangul key OK.
 
 
 but windows spice client Hangul key --- Alt key...
 
 
 
 
 Hangul key scancode = 0x38
 Alt key scancode = 0x38
 
 
 WHY?? 
 
 
 Help me Thank you.
 
 
 
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users


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

Re: [Spice-devel] Floating windows?

[David Jaša]

On Ne, 2014-11-16 at 16:25 +0100, Fabiano Fidêncio wrote:
 Hey Todd,
 
 On Sun, Nov 16, 2014 at 5:48 AM, ToddAndMargo toddandma...@zoho.com wrote:
  Hi,
 
  Please excuse if this is dumb question.  I have seen the way
  Parallels operates on Mac.  Instead of opening up a window
  with the whole of Windows inside, Parallels will float just
  the application in the host's desktop.  Makes for a lot
  less clutter.
 
  Is there anything like this in our future?  (I know
  you can do this with X11 and SSH on Linux VM's,
  but it is slow and Windows doesn't support it.)
 
 
 It's something that I'd love to see implemented. Although, for now
 (talking about short-term future), I don't see myself work on this
 (but I cannot speak for the others working on Spice).
 

IIRC what virtualbox uses to achieve this feature is to draw all windows
in the one big desktop and cut them out of it - quite a hack if indeed
true.

I think that solving this problem well would need cooperation with
window manager and composition manager and it would also allow host of
optimizations in normal mode with guest root windows: way less traffic
on WM animations, no redraws on window movement, no discard  re-send of
graphics on pop-up  dismiss, scaling down of windows server-side for
windows previes (gnome-shell's overview and windows aero alt-tab) and so
on...

David

  Many thanks,
  -T
 
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 
 Best Regards,


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

Re: [Spice-devel] spice ssl live migration

[David Jaša]

On St, 2014-11-26 at 15:02 +0800, yao xu wrote:
 Thanks David .
 
 
I use ovirt to manage my vms , version is about 3.1, my workmates
 added some code .
 

So the issue you see is most likely ovirt bug. The easiest way should be
to put host into maintenance, delete spice certificates and keys
from /etc/pki/vdsm/libvirt-spice (IIRC, the exact directory may be
different) and reinstall host again in ovirt webadmin. During
reinstallation, the new valid certificates should be created.

BTW why are you staying on ovirt 3.1? That version is long obsolete, two
years and 4 releases passed since then...

 
In our environment , we can't migrate vm continuosly. Is libvirt or
 qemu should do some configuration ? 

ovirt should configure both for you. The migration should work with no
client disconnection no matter how many times you migrated before.

David


my libvirt version is 1.2.8 , qemu's version is 1.7.1
 
 
 I do appreciate your help! guys.

 
 
 
 2014-10-22 21:05 GMT+08:00 David Jaša dj...@redhat.com:
 Hi,
 
 On St, 2014-10-22 at 12:03 +0800, yao xu wrote:
  Hi all!
 
 
  I am using spice and ovirt(a old version).
 
 
  when  I use remote-viewer with correct ssl certifacate to
 connect the
  vm , and then live migrate the vm to another host ,
 
 The certificates for both hosts have to be issued by the same
 CA.
 
 
 
  remote-viewer is dead .I must reconnect the vm .
 
 
  Can I use remote-viewer continuous when the vm is migrating?
 How to
  configure the ssl certificate ?
 
 Yes, you can. Configuration may be different based on the way
 you launch
 the VMs: e.g. when you use oVirt/RHEV, it will take care of
 correct TLS
 setup automatically. Libvirt can do most of the tasks for you
 but you
 still have to set up certificates correctly yourself and when
 you use
 plain qemu, you have to feed correct configuration even to
 qemu monitor.
 
 So: how do you manage your VMs?
 
 David
 
 
 
  Thank you .
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] snooping on usb passthrough

[David Jaša]

On Po, 2014-11-17 at 10:19 -0500, David Mansfield wrote:
 Hi All,
 
 Can anyone point me in the right direction for snooping on USB messages 
 going to a windows VM either from host device passthrough or spice usb 
 passthrough?
 
 I'd like to reverse engineer some USB speakerphone HID stuff.
 

CCing Hans

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

Re: [Spice-devel] spice ssl live migration

[David Jaša]

Hi,

On St, 2014-10-22 at 12:03 +0800, yao xu wrote:
 Hi all!
 
 
 I am using spice and ovirt(a old version). 
 
 
 when  I use remote-viewer with correct ssl certifacate to connect the
 vm , and then live migrate the vm to another host ,

The certificates for both hosts have to be issued by the same CA.

 
 
 remote-viewer is dead .I must reconnect the vm .
 
 
 Can I use remote-viewer continuous when the vm is migrating?  How to
 configure the ssl certificate ?

Yes, you can. Configuration may be different based on the way you launch
the VMs: e.g. when you use oVirt/RHEV, it will take care of correct TLS
setup automatically. Libvirt can do most of the tasks for you but you
still have to set up certificates correctly yourself and when you use
plain qemu, you have to feed correct configuration even to qemu monitor.

So: how do you manage your VMs?

David

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


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

Re: [Spice-devel] [spice-gtk PATCH v2] Ability to release the cursor with a keyboard shortcut

[David Jaša]

On Čt, 2014-10-09 at 05:54 -0400, Marc-André Lureau wrote:
 Hi,
 
 - Original Message -
  The cursor is grabbed/ungrabbed automatically by spice-gtk,
  this patch allows releasing the cursor in the client mouse mode
  with a keyboard shortcut.
 
 Could you describe the issue you have with the current behaviour, or the use 
 case?

Keyboard navigation. Work in guest - release cursor - alt-tab to a
different client window.

David

 
 thanks
  
  ---
  v2:
   - fix crash on vm shutdown
  
   gtk/spice-widget-priv.h |  1 +
   gtk/spice-widget.c  | 68
   +
   2 files changed, 42 insertions(+), 27 deletions(-)
  
  diff --git a/gtk/spice-widget-priv.h b/gtk/spice-widget-priv.h
  index 597ce10..c5960bd 100644
  --- a/gtk/spice-widget-priv.h
  +++ b/gtk/spice-widget-priv.h
  @@ -92,6 +92,7 @@ struct _SpiceDisplayPrivate {
   enum SpiceMouseMode mouse_mode;
   int mouse_grab_active;
   boolmouse_have_pointer;
  +gbooleancursor_released;
   GdkCursor   *mouse_cursor;
   GdkPixbuf   *mouse_pixbuf;
   GdkPointmouse_hotspot;
  diff --git a/gtk/spice-widget.c b/gtk/spice-widget.c
  index 1220030..5a14236 100644
  --- a/gtk/spice-widget.c
  +++ b/gtk/spice-widget.c
  @@ -916,8 +916,11 @@ static void update_mouse_pointer(SpiceDisplay *display)
   
   switch (d-mouse_mode) {
   case SPICE_MOUSE_MODE_CLIENT:
  -if (gdk_window_get_cursor(window) != d-mouse_cursor)
  +if (d-cursor_released) {
  +gdk_window_set_cursor(window, NULL);
  +} else if (gdk_window_get_cursor(window) != d-mouse_cursor) {
   gdk_window_set_cursor(window, d-mouse_cursor);
  +}
   break;
   case SPICE_MOUSE_MODE_SERVER:
   if (gdk_window_get_cursor(window) != NULL)
  @@ -940,19 +943,21 @@ static void try_mouse_grab(SpiceDisplay *display)
   
   if (!d-mouse_have_pointer)
   return;
  -if (!d-keyboard_have_focus)
  -return;
   
   if (!d-mouse_grab_enable)
   return;
  -if (d-mouse_mode != SPICE_MOUSE_MODE_SERVER)
  -return;
   if (d-mouse_grab_active)
   return;
   
  -if (do_pointer_grab(display) != GDK_GRAB_SUCCESS)
  -return;
  -
  +if (d-mouse_mode == SPICE_MOUSE_MODE_SERVER) {
  +if (do_pointer_grab(display) != GDK_GRAB_SUCCESS)
  +return;
  +} else {
  +try_keyboard_grab(display);
  +d-mouse_grab_active = true;
  +g_signal_emit(display, signals[SPICE_DISPLAY_MOUSE_GRAB], 0, true);
  +}
  +d-cursor_released = false;
   d-mouse_last_x = -1;
   d-mouse_last_y = -1;
   }
  @@ -996,13 +1001,14 @@ static void try_mouse_ungrab(SpiceDisplay *display)
   if (!d-mouse_grab_active)
   return;
   
  -gdk_pointer_ungrab(GDK_CURRENT_TIME);
   gtk_grab_remove(GTK_WIDGET(display));
  +if (d-mouse_mode == SPICE_MOUSE_MODE_SERVER 
  gdk_pointer_is_grabbed()) {
  +gdk_pointer_ungrab(GDK_CURRENT_TIME);
   #ifdef G_OS_WIN32
  -ClipCursor(NULL);
  +ClipCursor(NULL);
   #endif
  -set_mouse_accel(display, TRUE);
  -
  +set_mouse_accel(display, TRUE);
  +}
   d-mouse_grab_active = false;
   
   g_signal_emit(display, signals[SPICE_DISPLAY_MOUSE_GRAB], 0, false);
  @@ -1308,11 +1314,11 @@ static gboolean key_event(GtkWidget *widget,
  GdkEventKey *key)
   if (check_for_grab_key(display, key-type, key-keyval)) {
   g_signal_emit(widget, signals[SPICE_DISPLAY_GRAB_KEY_PRESSED], 0);
   
  -if (d-mouse_mode == SPICE_MOUSE_MODE_SERVER) {
  -if (d-mouse_grab_active)
  -try_mouse_ungrab(display);
  -else
  -try_mouse_grab(display);
  +if (d-mouse_grab_active) {
  +spice_display_mouse_ungrab(display);
  +try_keyboard_ungrab(display);
  +} else {
  +try_mouse_grab(display);
   }
   }
   
  @@ -1402,7 +1408,10 @@ static gboolean enter_event(GtkWidget *widget,
  GdkEventCrossing *crossing G_GNUC
   SPICE_DEBUG(%s, __FUNCTION__);
   
   d-mouse_have_pointer = true;
  +if (d-cursor_released)
  +return true;
   try_keyboard_grab(display);
  +try_mouse_grab(display);
   update_display(display);
   
   return true;
  @@ -1415,11 +1424,9 @@ static gboolean leave_event(GtkWidget *widget,
  GdkEventCrossing *crossing G_GNUC
   
   SPICE_DEBUG(%s, __FUNCTION__);
   
  -if (d-mouse_grab_active)
  -return true;
  -
   d-mouse_have_pointer = false;
   try_keyboard_ungrab(display);
  +try_mouse_ungrab(display);
   
   return true;
   }
  @@ -1442,6 +1449,8 @@ static gboolean focus_in_event(GtkWidget *widget,
  GdkEventFocus *focus G_GNUC_UN
   if (!d-disable_inputs)
   

Re: [Spice-devel] W8.0 video drivers

[David Jaša]

On Út, 2014-09-16 at 20:46 -0700, ToddAndMargo wrote:
 On 09/15/2014 11:51 PM, David Jaša wrote:
  Hi,
 
  there is no QXL driver for Windows 8 available yet. The QXL driver is
  built on top of XPDM API that is not available in Windows 8 anymore. The
  new QXL driver based on more recent WDDM API is not available yet
  unfortunately so you're stuck with vga driver on Windows 8 guests.
 
  David
 
  On Po, 2014-09-15 at 14:14 -0700, ToddAndMargo wrote:
  Hi All,
 
  Is there a way to get the guest additions (spice-guest-tools-0.74.exe)
  to work with the original Windows 8.0 (no service packs, just
  Frankenstein himself off the OEM CD).  I am trying to get the
  video driver to install and it keeps telling me I have the wrong
  version of Windows.
 
  Many thanks,
  -T
 
 
 Hi David,
 
 Do you know if we will have video drivers for Son-of-Frankenstein
 (Windows 9)?

no but qxl device should work there in vga mode just fine IMO.

David

 
 -T
 
 


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

Re: [Spice-devel] USB drier in w7 problems

[David Jaša]

Hi,

you're not using spice usb redirection, you're using host usb device
assignment. For spice usb redirection, you'd have to add USB
Controller and a bunch of Redirected USB devices in virt-manager or
controller and redirdev elements to domain xml (with correct PCI slot!):
http://hansdegoede.livejournal.com/11084.html

I have next to none experience with host device assignment (it didn't
work for me) but usbredir should work just fine.

David


On Út, 2014-09-16 at 10:45 -0700, ToddAndMargo wrote:
 
  On Po, 2014-09-15 at 14:30 -0700, ToddAndMargo wrote:
  Hi All,
 
  I can see my (FAT 32) USB sticks to in XP.  They are really,
  really slow, but I can read them.
 
  In Windows 7, I get This device cannot start. (Code 10) from
  the device manager.
 
  When I go to reinstall the driver from
 
C:\Program Files (x86)\SPICE Guest Tools\drivers\win7\amd64
  or
C:\Drivers\Spice-Guest-Tools\virtio-win-0.1.81\WIN7\AMD64
 
  I get
 
Windows has determined the driver software for your device
is up to date.
 
  I also get told that the location doesn't contain any compatible
  drivers (both locations).
 
  Driver details from Device description says USB Mass Storage
  Device
 
  In the Device Manager, if I hit View Hidden Devices, the
  above is the only one with a bang mark.
 
  What gives?
 
  Many thanks,
  -T
 
 
 On 09/15/2014 11:54 PM, David Jaša wrote: Hi,
 
  when using usbredir, guest OS driver versions don't matter, the whole
  redirection is done by client and spice-server + qemu. So could you
  please post OS and versions of client (spice-gtk or such) and host
  system (qemu and spice-server), and your libvirt xml (or qemu
  commandline)?
 
  David
 
 
 $ cat /etc/redhat-release
 Scientific Linux release 6.5 (Carbon)
 
 $ uname -r
 2.6.32-431.29.2.el6.x86_64
 
 $ rpm -qa \*spice\*
 spice-client-0.8.2-15.el6.x86_64
 spice-gtk-python-0.20-11.el6.x86_64
 spice-glib-0.20-11.el6.x86_64
 spice-protocol-0.12.6-1.el6.noarch
 spice-vdagent-0.14.0-2.el6.x86_64
 spice-gtk-0.20-11.el6.x86_64
 spice-server-0.12.4-6.el6.x86_64
 
 $ rpm -qa \*qemu\*
 qemu-img-0.12.1.2-2.415.el6_5.14.x86_64
 qemu-kvm-0.12.1.2-2.415.el6_5.14.x86_64
 gpxe-roms-qemu-0.9.7-6.10.el6.noarch
 
 $ rpm -qa \*libvirt\*
 libvirt-python-0.10.2-29.el6_5.8.x86_64
 libvirt-client-0.10.2-29.el6_5.8.x86_64
 libvirt-0.10.2-29.el6_5.8.x86_64
 
 $ ps ax | grep KVM-W7
 
   8636 ?Sl 0:09 /usr/libexec/qemu-kvm -name KVM-W7 -S -M 
 rhel6.3.0 -enable-kvm -m 4096 -realtime mlock=off -smp 
 4,sockets=4,cores=1,threads=1 -uuid bc6e5dde-e15f-cadb-3aa3-1e4f4087bf3c 
 -nodefconfig -nodefaults -chardev 
 socket,id=charmonitor,path=/var/lib/libvirt/qemu/KVM-W7.monitor,server,nowait 
 -mon chardev=charmonitor,id=monitor,mode=control -rtc 
 base=localtime,driftfix=slew -no-shutdown -device 
 piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
 virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive 
 file=/home/kvm/KVM-W7.qcow,if=none,id=drive-ide0-0-0,format=qcow2,cache=none,aio=threads
  
 -device 
 ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 
 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw 
 -device 
 ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 
 -netdev tap,fd=23,id=hostnet0 -device 
 rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:2e:63:d5,bus=pci.0,addr=0x3 
 -chardev pty,id=charserial0 -device 
 isa-serial,chardev=charserial0,id=serial0 -chardev 
 spicevmc,id=charchannel0,name=vdagent -device 
 virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
  
 -device usb-tablet,id=input0 -spice 
 port=5903,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga 
 qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 
 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device 
 hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device 
 usb-host,hostbus=10,hostaddr=3,id=hostdev0 -device 
 virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
 
   8697 pts/0S+ 0:00 grep KVM-W7
 
  From my XML file:
  hostdev mode='subsystem' type='usb' managed='yes'
source
  vendor id='0x1e1d'/
  product id='0x1103'/
/source
  /hostdev
 
 virt-manager calls the above USB Flash drive:
  Physical USB Device
  Device: 010:003 KANGURU SS3
 
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] W8.0 video drivers

[David Jaša]

Hi,

there is no QXL driver for Windows 8 available yet. The QXL driver is
built on top of XPDM API that is not available in Windows 8 anymore. The
new QXL driver based on more recent WDDM API is not available yet
unfortunately so you're stuck with vga driver on Windows 8 guests.

David

On Po, 2014-09-15 at 14:14 -0700, ToddAndMargo wrote:
 Hi All,
 
 Is there a way to get the guest additions (spice-guest-tools-0.74.exe)
 to work with the original Windows 8.0 (no service packs, just
 Frankenstein himself off the OEM CD).  I am trying to get the
 video driver to install and it keeps telling me I have the wrong
 version of Windows.
 
 Many thanks,
 -T
 



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

Re: [Spice-devel] USB drier in w7 problems

[David Jaša]

Hi,

when using usbredir, guest OS driver versions don't matter, the whole
redirection is done by client and spice-server + qemu. So could you
please post OS and versions of client (spice-gtk or such) and host
system (qemu and spice-server), and your libvirt xml (or qemu
commandline)?

David

On Po, 2014-09-15 at 14:30 -0700, ToddAndMargo wrote:
 Hi All,
 
 I can see my (FAT 32) USB sticks to in XP.  They are really,
 really slow, but I can read them.
 
 In Windows 7, I get This device cannot start. (Code 10) from
 the device manager.
 
 When I go to reinstall the driver from
 
  C:\Program Files (x86)\SPICE Guest Tools\drivers\win7\amd64
 or
  C:\Drivers\Spice-Guest-Tools\virtio-win-0.1.81\WIN7\AMD64
 
 I get
 
  Windows has determined the driver software for your device
  is up to date.
 
 I also get told that the location doesn't contain any compatible
 drivers (both locations).
 
 Driver details from Device description says USB Mass Storage
 Device
 
 In the Device Manager, if I hit View Hidden Devices, the
 above is the only one with a bang mark.
 
 What gives?
 
 Many thanks,
 -T
 


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

Re: [Spice-devel] [vdagent-linux] data: remove rsyslog config files

[David Jaša]

On Pá, 2014-09-05 at 15:18 +0200, Marc-André Lureau wrote:
 Many systems don't use rsyslog, others don't need seperate syslog files
 for vdagent.  Instead, /var/log/messages can be grep for spice-vdagent,
 or system with the journal can call journalctl
 SYSLOG_IDENTIFIER=spice-vdagent.

Well, with application-level logging in systemd, it would make sense to
use spice-vdagentd for daemon and spice-vdagent for per-session process,
wouldn't it?

David

 
 This simplify spice-vdagent packaging and updates, since there are no
 config files to deal with.
 
 Related:
 https://bugzilla.redhat.com/show_bug.cgi?id=1136881
 ---
  Makefile.am| 4 
  data/rsyslog.d/spice-vdagentd.conf | 4 
  2 files changed, 8 deletions(-)
  delete mode 100644 data/rsyslog.d/spice-vdagentd.conf
 
 diff --git a/Makefile.am b/Makefile.am
 index 7fae742..510f460 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -51,9 +51,6 @@ gdmautostart2_DATA = 
 $(top_srcdir)/data/spice-vdagent.desktop
  install-data-local:
   $(mkdir_p) $(DESTDIR)$(localstatedir)/run/spice-vdagentd
  
 -rsyslogdir = $(sysconfdir)/rsyslog.d
 -rsyslog_DATA = $(top_srcdir)/data/rsyslog.d/spice-vdagentd.conf
 -
  if INIT_SCRIPT_RED_HAT
  initdir = $(sysconfdir)/rc.d/init.d
  init_SCRIPTS = $(top_srcdir)/data/spice-vdagentd
 @@ -79,7 +76,6 @@ manpage_DATA = data/spice-vdagent.1 \
  EXTRA_DIST = \
   README.RHEL-5   \
   data/70-spice-vdagentd.rules\
 - data/rsyslog.d/spice-vdagentd.conf  \
   data/spice-vdagent.desktop  \
   data/spice-vdagentd \
   data/spice-vdagentd.service \
 diff --git a/data/rsyslog.d/spice-vdagentd.conf 
 b/data/rsyslog.d/spice-vdagentd.conf
 deleted file mode 100644
 index 2437ba0..000
 --- a/data/rsyslog.d/spice-vdagentd.conf
 +++ /dev/null
 @@ -1,4 +0,0 @@
 -# A template to for higher precision timestamps + severity logging
 -$template SpiceTmpl,%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% 
 %syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n
 -
 -:programname, startswith, spice-vdagent
 /var/log/spice-vdagent.log;SpiceTmpl


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

Re: [Spice-devel] problems with intermediate certificates

[David Jaša]

Hi Dietmar,

do the certificate setup works for other TLS apps, such as web
server/browser or just simple openssl s_(server|client)?

Also, do you account for intermediate CA in your setup? You have
basically two options how to handle it:

1) standard: server-cert.pem should contain the whole chain of
certificates under root CA, e.g:
  * Int. CA 1
* Int. CA 2
  * server cert
you just cat them to the file in that order. You then add the root CA to
the .vv file and things should work.

2) custom: treat intermediate CA that actually signed the server cert
as trusted root: use it in ca-cert.pem and pass it to remote-viewer.
Given that you need to supply remote-viewer with a CA, this approach is
less wrong than in different TLS use cases.

HTH,

David


On Pá, 2014-08-22 at 08:22 +, Dietmar Maurer wrote:
 I use the following certificate files:
 
 # openssl verify -CAfile /etc/pve/pve-root-ca.pem /etc/pve/local/pve-ssl.pem
 /etc/pve/local/pve-ssl.pem: OK
 
 I pass the content of /etc/pve/pve-root-ca.pem to virt-viewer:
 [virt-viewer]
 ca=-BEGIN CERTIFICATE-\nXX/Q=\n-END CERTIFICATE-\n
 ...
 
 I also use above cert files when starting qemu, and remote-viewer works 
 perfectly unless
 we use intermediate CAs.
 
 -
 # remote-viewer /tmp/scDvEiLJ 
 (/usr/bin/remote-viewer:363337): Spice-Warning **: 
 ssl_verify.c:428:openssl_verify: openssl verify:num=20:unable to get local 
 issuer certificate:depth=1:/C=IL/O=StartCom Ltd./OU=Secure Digital 
 Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
 
 (remote-viewer:363337): GSpice-WARNING **: main-1:0: SSL_connect: 
 error:0001:lib(0):func(0):reason(1)
 
 
 I tried to append the intermediate cert to /etc/pve/pve-root-ca.pem  and 
 /etc/pve/local/pve-ssl.pem, but always
 get the same error.
 
 Any ideas?
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore

[David Jaša]

Hi,

On Út, 2014-07-08 at 10:13 +0200, Fabio Fantoni wrote:
 On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and client with 
 spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm 
 except for one problem after xl save/restore, when after restore on 
 spice client connect  the domU's screen freezed for 2-3 minutes (and 
 seems also windows), after this time seems that all return to works 
 correctly.
 This problem happen also if spice client connect long time after restore.
 With stdvga not have this problem but stdvga has many missed resolutions 
 and bad refresh performance.
 
 If you need more tests/informations tell me and I'll post them.

Client and server logs would certainly help. Please run:
  * virt-viewer with --spice-debug option
  * spice-server with SPICE_DEBUG_LEVEL environment variable set
to 4 or 5 (if you use qemu+libvirt, use qemu:env element:
http://libvirt.org/drvqemu.html#qemucommand )
and note the location in the logs where the freeze takes place.

Regards,

David

 
 Thanks for any reply and sorry for my bad english.
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] [ovirt-users] transfer files from guest to client

[David Jaša]

Yes, the development took place. The bits for spice-webdav feature are
in git and you can test them as Cody described here:
http://lists.freedesktop.org/archives/spice-devel/2014-April/016582.html
with some twists related to running in oVirt:
  * you don't need to create stuff managed by ovirt/vdsm such as certificates
  * you'll need to add webdav channels XML bits using custom hook

adding spice-devel list to CC for reference.

David


On St, 2014-05-14 at 11:33 -0500, Jeff Clay wrote:
 The only thing I've been able to find on this
 is 
 http://lists.freedesktop.org/archives/spice-devel/2014-February/016063.html. 
 I was wondering if there have been any developments since then and if not, 
 could somebody please provide more details on the guest-side virtual 
 folder/icon that someone described. 
 
 
 Thank you
 
 
 
 
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users


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

Re: [Spice-devel] SPICE client for unmanaged X

[David Jaša]

Hi Brad,

the support for seamless multi-head is in spice for quite some time. In
the guest, qxl driver needs to be used, spice-vdagent must be running
(agent consists of system-wide spice-vdagentd daemon and per-session
spice-vdagent process, all should be up'n'running automatically after
installation and maybe logout). No further X configuration is necessary.

Then connect with:
(remote|virt)-viewer --full-screen=auto-conf ...
or after connection, enable extra monitors in View - Displays.

You may have troubles if you use too old systems (Debian or Ubuntu more
than two years old, RHEL/CentOS gets spice rebases regularly). If you
have problems with recent distros, please attach debug logs:

* virt-viewer: launch it in console with --spice-debug parameter

* spice-vdagent: kill the per-session instance and run it in console:
spice-vdagent -x -d -d

HTH,

David


On Ne, 2014-04-27 at 20:09 +0800, Brad Campbell wrote:
 G'day all,
 
 I'm after some advice on a spice client I could use on unmanaged X.
 
 I have a client machine with 3 heads. What I would like is to be able to 
 do is access a spice server and have the three heads appear on my client 
 like they are native. As an example, this is the way I do it with it on 
 a single head machine and vnc.
 
 xinit /usr/bin/xtightvncviewer -bgr -fullscreen -passwd 
 $HOME/.vnc/passwd xx.vm.home -- :2 -layout Secondary
 
 So this starts a new X server, and sparks up a vncviewer instance that 
 has full use of the monitor. Ideally I'd like to do the same with 
 multi-head machines.
 
 At the moment I'm running Xmonad on Debian as a client, this allows me 
 to auto-map the 3 spice windows to the 3 monitors, but I have issues 
 with the client hotkeys clashing with the server hotkeys for window 
 management. If I could remove the window-manager and have a multi-head 
 spice client just use all three heads fully I'd eliminate this issue.
 
 I currently use spice-gtk as a client. Is there a better client (I don't 
 use USB pass through or audio) that might allow me to do what I want to 
 do? Has anyone got any pointers to examples?
 
 Regards,
 Brad
 -- 


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

Re: [Spice-devel] spice scroll problem

[David Jaša]

Hi,

On Po, 2014-04-28 at 08:31 -0400, Marc-André Lureau wrote:
 
 - Original Message -
  Hi,
  i cannot get scroll events from xev screen. and I guess
  remote-viewer is in client mode:
  
  graphics type='spice' port='5930' autoport='no'
mouse mode='client'/
  /graphics
  
 
 I am not sure what this option really do. 

IIRC, mouse mode='client'/ should be no-op (setting explicitly default
value - use of client mouse if vdagent or vmmouse is available), mouse
mode='server'/ should OTOH force server mouse even if client mouse is
possible.

David

 In any case, being in client or server mouse mode shouldn't change the events 
 being sent, it should work in both mode.
 
 Can you check the mouse events received with evtest in guest?
 Can you verify your client has scrolling events 4/5 with xev too? 
 
 Did you configure X11 input manually?
 
  
  
  2014-04-28 14:50 GMT+03:00 Marc-André Lureau mlur...@redhat.com:
  
   Hi
  
   - Original Message -
Hi,
i use spice client for my kvm virtual environment. Everything is perfect
except mouse scroll.
I use spice-vdagent in my guest.
   
and this is spice related xml script:
   
channel type='spicevmc'
target type='virtio' name='com.redhat.spice.0'/
address type='virtio-serial' controller='0' bus='0' port='1'/
/channel
   
input type='mouse' bus='ps2'/
   
graphics type='spice' port='5930' autoport='no'
mouse mode='client'/
/graphics
   
   
I can get output with scroll event from /dev/input/mice.
   
and this is the kernel output:
grep -i mouse /var/log/dmesg
[ 0.536422] mousedev: PS/2 mouse device common for all mice
[ 29.829300] input: ImExPS/2 Generic Explorer Mouse as
/devices/platform/i8042/serio1/input/input2
   
Guest and host systems are Linux Mint XFCE 16
   
What should i do?
  
   It looks all quite correct. Are you using remote-viewer as client?
  
   Can you check with xev that the guest receives events from button 4/5?
  
   thanks
  
  
  
  
  --
  FIRAT KÜÇÜK
  
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] The USB redirect can not work

[David Jaša]

Hi,

you need a bit more than just virt-viewer to make USB redirection on Windows 
working. It was already summarized on this list in the past:
http://lists.freedesktop.org/archives/spice-devel/2013-April/013214.html
http://lists.freedesktop.org/archives/spice-devel/2013-May/013479.html

HTH,

David


On Čt, 2014-03-27 at 10:12 +0800, 付乐颖 wrote:
 Hello. I have installed the spice server， and after the spice-gtk configure, 
 it shows  the usb redirection is yes. But when i installed the virt-viewer 
 64-bit in my windows8, the virt-viewer still can not support the usb 
 redirect, the option of USB device selection is gray. But virt-viewer in my 
 Ubuntu can support the USB redirection. Should I install some other 
 dependencies in my Windows? And what's that? Could you tell me? Thanks a lot!
 
 
 --
 祝您生活愉快！ 
 此致
 礼
 
 
 中科大软件学院付乐颖
 
 地址：江苏省苏州市工业园区仁爱路188号
 E-mail：fuley...@mail.ustc.edu.cn
   fuley...@gmail.com
 
 手机：18806132356
 邮编：215123
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] spice client using Certificate and ipv6 question

[David Jaša]

On St, 2014-03-26 at 09:05 +0800, bigclouds wrote:
 all the cases you mentioned  have been tested.
  
 spice://[%eth0]?tls-port=5901 , failed
 g_proxy_resolver_lookup_async: assertion uri != NULL failed
 

That's the scope lost bugs I mentioned in spice-gtk:
https://bugzilla.redhat.com/show_bug.cgi?id=827115

and in glib:
https://bugzilla.redhat.com/show_bug.cgi?id=859474
https://bugzilla.gnome.org/show_bug.cgi?id=684404

Workaround: try with global ipv6 address (assigned by autoconfiguration)

David

 
 
 
 
 在 2014-03-25 19:20:12，David Jaša dj...@redhat.com 写道：
 Hi,
 
 On Út, 2014-03-25 at 09:50 +0100, Christophe Fergeau wrote:
  On Tue, Mar 25, 2014 at 09:45:54AM +0800, bigclouds wrote:
   centos6.3
   spice-gtk-0.20-11.el6.x86_64
   spice-server-0.12.2-1.el6.x86_64
   spice-glib-0.20-11.el6.x86_64
   virt-viewer-0.5.6-8.el6.x86_64


   i think the problem is related to spice-glib, g_network_address_new. 
   maybe glib has some problems.
   it is ok if  it is ::1(local lo ipv6), outside  ipv6 and local ipv6 
   failed.it is weird.

   thanks

   (remote-viewer:12972): GSpice-DEBUG: spice-session.c:1813 open host 
   fe80::20c:29ff:fe0a:2351:5901
  
  remote-viewer seems to think 5901 (port name I guess) is part of the
  IP/host. Have you tried spice://[fe80::20c:29ff:fe0a:2351]:5901 or
  spice://fe80::20c:29ff:fe0a:2351?port=5901 ?
 
 Note that:
   * link-local addresses (fe80::something) need interface designation 
  (scope), e.g. fe80::aabb:ccff:fedd:eeff%eth0
   * remote-viewer sticks to uri scheme so ipv6 address needs to be enclosed 
  in brackets (there was a bug clarifying it)
 so the correct url for the example above should be:
 spice://[fe80:20c:29ff:fe0a:2351%eth0]:5901/
 
 There used to be another bug about scope being stripped from the uris in 
 glib, I'm not sure about its status in .el6 though.
 
 David
 
  
  Christophe
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] spice client using Certificate and ipv6 question

[David Jaša]

Hi,

On Út, 2014-03-25 at 09:50 +0100, Christophe Fergeau wrote:
 On Tue, Mar 25, 2014 at 09:45:54AM +0800, bigclouds wrote:
  centos6.3
  spice-gtk-0.20-11.el6.x86_64
  spice-server-0.12.2-1.el6.x86_64
  spice-glib-0.20-11.el6.x86_64
  virt-viewer-0.5.6-8.el6.x86_64
   
   
  i think the problem is related to spice-glib, g_network_address_new. maybe 
  glib has some problems.
  it is ok if  it is ::1(local lo ipv6), outside  ipv6 and local ipv6 failed. 
 it is weird.
   
  thanks
   
  (remote-viewer:12972): GSpice-DEBUG: spice-session.c:1813 open host 
  fe80::20c:29ff:fe0a:2351:5901
 
 remote-viewer seems to think 5901 (port name I guess) is part of the
 IP/host. Have you tried spice://[fe80::20c:29ff:fe0a:2351]:5901 or
 spice://fe80::20c:29ff:fe0a:2351?port=5901 ?

Note that:
  * link-local addresses (fe80::something) need interface designation (scope), 
e.g. fe80::aabb:ccff:fedd:eeff%eth0
  * remote-viewer sticks to uri scheme so ipv6 address needs to be enclosed in 
brackets (there was a bug clarifying it)
so the correct url for the example above should be:
spice://[fe80:20c:29ff:fe0a:2351%eth0]:5901/

There used to be another bug about scope being stripped from the uris in glib, 
I'm not sure about its status in .el6 though.

David

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


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

Re: [Spice-devel] [PATCH spice-common] RFC: spice.proto: add webdav channel

[David Jaša]

On Čt, 2014-02-27 at 18:27 +0100, Marc-André Lureau wrote:
 Hi
 
 On Wed, Feb 26, 2014 at 11:00 PM, Jonathon Jongsma jjong...@redhat.com 
 wrote:
  There's also the option of using a 'temporary' name (e.g.
  DraftWebDAVChannel or something) until we're convinced that it's the
  right approach and then rename it to a more official name and advertise
  it as stable...
 
 
 Imho, we should prefer versioning over unstable APIs when possible.
 
 The fact that channel id X will be named DraftWebDAVChannel or
 WebDAVChannel doesn't change much, but perhaps it makes it clear that
 it could be removed/replaced later.
 
 Tbh, this is all hypothetical, the proposed implementation works well
 with both Linux and Windows remotes (but more exposure would help
 finding shortcomings..)
 

IMO fresh builds in virt-preview repo could bring some extra exposure...

David

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

Re: [Spice-devel] Connect Windows 2003 VM remotely through Spice protocol

[David Jaša]

Hi,

There is no spice server running inside the windows. You can connect to
the windows via spice only when windows runs as a qemu/kvm guest (maybe
also qemu/xen, Fabio would know more).
For linux, Xspice is available for spice connection to the system itself
(as opposed to connection to underlying qemu process) but that's just
linux and it doesn't have full spice feature set implemented.

David


On Pá, 2014-02-21 at 00:37 +0530, Rohit Kakar wrote:
 Hi Team,
 
 I have windows 2003 server virtual machine which is running on ESXi host, i
 want to connect remotely through spice protocol instead of RDP protocol.
 
 is it possible to connect if yes, which software i have to install on
 windows 2003 server and which software require on client side to connect
 this.
 
 Thanks on Advance.
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] spice: connection refused

[David Jaša]

On Ne, 2014-02-16 at 18:25 -0500, Sean Darcy wrote:
 On 02/16/2014 05:11 PM, Marian Krcmarik wrote:
 
 
  - Original Message -
  From: Sean Darcy seandar...@gmail.com
  To: spice-devel@lists.freedesktop.org
  Sent: Sunday, February 16, 2014 8:50:19 PM
  Subject: Re: [Spice-devel] spice: connection refused
 
  On 02/16/2014 12:10 PM, Sean Darcy wrote:
  I'm trying to connect to a windows guest on an Fedora 19 host from a
  Fedora 19 client.
 
  remote-viewer spice://10.10.11.100:5972
 
  (remote-viewer:19994): GSpice-WARNING **: Could not connect to
  10.10.11.100: Connection refused
 
  virt-viewer-0.5.6-1.fc19.x86_64
 
  xml for the guest has:
 
  graphics type='spice' port='5972' autoport='no'/
 
  Not sure how you troubleshoot this. I can ssh into the host, and connect
  to the guest with vnc.
 
  On the F19 host:
 
  qemu-1.6.1-2.fc19.x86_64
  rpm -qa | grep spice | sort
  spice-glib-0.20-6.fc19.x86_64
  spice-glib-devel-0.20-6.fc19.x86_64
  spice-gtk-0.20-6.fc19.x86_64
  spice-gtk3-0.20-6.fc19.x86_64
  spice-gtk3-devel-0.20-6.fc19.x86_64
  spice-gtk-devel-0.20-6.fc19.x86_64
  spice-gtk-python-0.20-6.fc19.x86_64
  spice-gtk-tools-0.20-6.fc19.x86_64
  spice-parent-15-9.fc19.noarch
  spice-protocol-0.12.6-1.fc19.noarch
  spice-server-0.12.4-3.fc19.x86_64
  spice-vdagent-0.14.0-5.fc19.x86_64
  spice-xpi-2.8-3.fc19.x86_64
 
  On the Windows 2008R2 guest:
 
  virtio-win-0.1-74.iso
  spice guest tools 0.74
 
  Any help appreciated.
 
  sean
 
  On F19 host:
  libvirt-1.1.3.2-1.fc19.x86_64
 
 
  And from the log file on the host:
 
  -spice port=5972,addr=127.0.0.1,disable-ticketing,seamless-migration=on
 
  You specified the spice server to be binded only on localhost:5972 (the 
  option addr=127.0.0.1) but you are trying to connect to 10.10.11.100:5972, 
  so If you use only localhost connection (the host and client is the same 
  machine) try - remote-viewer spice://localhost:5972 otherwise specify 
  correct IP address for your spice server to be binded on, try to edit the 
  domain xml to something like:
  graphics type='spice' port='5972' autoport='no'/
 listen type='address' address='10.10.11.100'/
  /graphics
  and then remote-viewer spice://10.10.11.100:5972
  You can use address 0.0.0.0 as wildcard for all interfaces.
 
 
  sean
 
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 
 Hmm. OK, I'll try that. Just to be clear the F19 host is 10.10.11.100. 
 But to connect remotely, I need to specify the ip address of the host in 
 the guest xml file? 

You can specify ipv6+ipv4 wildcard (address=::, spice-server will
listen on all ipv6 and ipv4 interfaces) or ipv4 wildcard
(address=0.0.0.0).

David

 Does this mean I could not connect to the guest from 
 the host? (which probably doesn't matter to us, but seems odd.)
 
 The guest network is bridged, and the guest has an ip address of 
 10.10.11.70. Would it be better to specify the _guest's_ address? That 
 way, I assume, I could connect from the host.
 
 Thanks for the prompt reply.
 
 sean
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] using scan code from hardware keyboards

[David Jaša]

Hi,

On St, 2014-02-12 at 22:03 -0500, i iordanov wrote:
 Hey guys,
 
 When my hardware keyboard is connected/paired with my Android device, key
 events do contain a scan code. I would love to just send that scan code
 through to the VM, however, the Android documentation is really
 discouraging on this matter.
 
 Can you guys take a look at the docs for the method which retrieves the
 scan code, and tell me whether you would rely on the value returned by
 getScanCode() given what's written?
 
 http://developer.android.com/reference/android/view/KeyEvent.html#getScanCode%28%29
 
 In addition, my hardware keyboard has an English layout, and I have no way
 of testing what a hardware keyboard with a non-English layout generates
 when one presses a key which is not in the ASCII table. The reason it's
 interesting is that Android key events may contain a key code, and  scan
 code. The documented key codes for Android are all within the ASCII table.
 When a soft-keyboard KeyEvent carries unicode data outside the ASCII table,
 its key code == 0, and its action is not DOWN or UP, but MULTIPLE. So,
 will (for example) a German hardware keyboard on which u-umlaut is pressed
 generate an event with action == ACTION_MULTIPLE and a key code == 0, or
 will it generate an event with action == DOWN/UP and key code set to
 something inaccurate? Does anybody own an Android and a hardware keyboard
 with a non-English layout to help me test this?

I still have to see a keyboard that would tell the computer what it's
layout is. That being said, I'm now typing on keyboard with german
labels that didn't actaully type a german-specific character in it's
whole lifetime. :)

So what you need to test is to switch the keyboard layout in the OS to
the interesting one (no idea how you do that in android) and press some
key. For example, the key with semicolon ; on english/us layout
produces ů when switched to czech layout.

David

 
 As things stand, if I don't trust the scan code the keyboard generates, I
 cannot use my English layout hardware keyboard to type any language other
 than English because the scan codes are simulated based on the unicode
 character the event contains. On my English keyboard, the event inevitably
 contains unicode characters that fall within the ASCII table, as you can
 imagine :).
 
 Your thoughts and suggestions are welcome.
 
 Thanks!
 iordan
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] [PATCH 00/17] Split RedsStream out of reds.c

[David Jaša]

Hi Christophe,

will it be easier to add possibility to listen on more addresses with
this patch merged? It's still a kind of blocker to proper dual stack
support in oVirt setups... (oVirt doesn't care yet but once they start
to care, it's better to be ready.)

David

On Út, 2014-01-07 at 12:14 +0100, Christophe Fergeau wrote:
 Hey,
 
 This is a series I've had locally for a while. It moves RedsStream related 
 code
 out of reds.c to its own file. This shaves ~1000 lines of code out of reds.c
 The patch series could be split in 2 independent series, first one would be
 patches 1-8 which is code movements from reds.c to redsstream.c.
 Second part would be patch 9-17 were I move some RedsStream fields from being
 public (exposed in a .h file) to being private (only available in 
 redsstream.c).
 
 There are still a few public fields in RedsStream after this series, but I 
 haven't
 addressed them yet. In particular, it would be nice to hide the 'socket' 
 member
 behind accessors so that we have a clear idea of what the rest of 
 spice-server code
 can/cannot do with this socket. At the moment, various part of spice-server
 directly call setsockopt or things like this on it.
 
 Christophe
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] Fw: Re: multiple client connect spice-server

[David Jaša]

No, only one client can connect at the same time.

David

On Út, 2014-01-07 at 10:05 +0800, hhb584520 wrote:
 how to multiple spice clients can connect to spice server at one time?
 
 thank you!
 
 
 
 
 hhb584520
 
 From: Liang Guo
 Date: 2014-01-06 23:31
 To: hhb584520
 Subject: Re: multiple client connect spice-server
 Hi,
 
 AFAIK, only one spice client can connect to spice server at one time.
 
 You'd better ask this problem in spice-devel maillist. other spice
 developer may know how to do this.
 
 Thanks,
 
 On Sun, Dec 29, 2013 at 5:28 PM, hhb584520 hhb584...@163.com wrote:
  when I run the following command:
  spicy-stats --host=12.0.0.58 --port=5900
 
  the remote-viewer is exit, so I can not statistics spice channel
 
  Could you tell how to run remote-viewer when I run spicy-stats
  --host=12.0.0.58 --port=5900
 
  thanks
  
  hhb584520
 
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

Re: [Spice-devel] Windows RHEV Spice Agent service Bugs

[David Jaša]

Can you at least search the bugs?
https://bugzilla.redhat.com/query.cgi?format=advancedproduct=Red%20Hat%20Enterprise%20Virtualization%20Managercomponent=spice-vdagent-wincomponent=Windows%20Guest%20Tools
(works for me in private tab). Any search should give you Report new
bug in %PRODUCT link as well.

David


On Po, 2013-12-16 at 23:11 +1000, Lindsay Mathieson wrote:
 On Mon, 16 Dec 2013 01:50:04 PM Christophe Fergeau wrote:
  Looks like you used a wrapped/truncated URL, try http://tiny.cc/p8q67w
 
 
 Same error I'm afraid.
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel


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

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

[David Jaša]

The slides are very nice and if you already have some prototype
finished, it would be cool to see it in action!

David


Fedor Lyakhov píše v So 30. 11. 2013 v 17:11 +0400:
 Hello Spice developers and users,
 
 I'm going to apply for FOSDEM'14 Virtualization dev room with event
 Media Redirection for Spice remote computing solution (deadline is
 tomorrow...). The event would include a 20-minute lecture, 5-minute
 demo of a prototype and 10-minute QA session.
 
 Before I apply, I'd like to hear your comments on the proposed event
 (and you're the main audience of it!). I'd appreciate any comments
 about title, abstract, outline and the presentation drafts
 (http://www.spice-space.org/wiki/images/b/b9/Fosdem2014-lyakhov-v2.pdf).
 Hope that with your comments I can get this application better and get
 it accepted.
 
 Title: Media redirection for Spice remote computing solution
 Subtitle: Optimizing media stream processing for media players and
 VoIP clients in virtual desktop infrastructures
 
 Abstract:
 Handling of media streams is suboptimal in virtual desktop
 infrastructures if it is done at virtual machines. Consider two main
 use case:
 * Playback of a media stream from remote server e.g. user watches Youtube
 * IP telephony e.g. user makes a video call
 In both cases media streams are not delivered to the user's device
 directly but transcoded at the virtualization server. This results in
 increased network load, server CPU load (less VM density), quality
 loss of media streams. A solution for this problem, Media Redirection
 for Red Hat Spice remote computing system is proposed
 (www.spice-space.org/page/Features/MediaRedirection).
 
 Solution concept introduces following components: Media Engine and
 RPC-like service at user's device, Media Engine stubs and RPC-like
 client at Guest OS. To integrate the solution with Spice, new Spice
 APIs are proposed: API for establishing virtual channels and API for
 overlay rendering.
 
 A working Media Redirection prototype will be demonstrated using a
 demo audio player, Apache Thrift as RPC system, GStreamer as Media
 Engine.
 
 The event will be interesting for remote computing system developers
 and users (in particular, Red Hat Spice), RPC system developers and
 users, media engine developers, media player and IP telephony client
 developers.
 
 Note: the authors are NOT working for Red Hat, this work is being done
 by volunteers in their spare time.
 
 Outline:
 * Common media processing usecases
 * Red Hat Spice overview
 * Description of media stream processing problem in VDI
 * Media redirection concept description
 * Media redirection prototype description and demo
 * Feature evolution plan
 Discussion topics:
 * architecture  design considerations
 * new Spice APIs for virtual channels and overlay rendering
 * fault-tolerance practices (crash, disconnect)
 

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v2] Use TLS version 1.0 or better

[David Jaša]

Christophe Fergeau píše v St 27. 11. 2013 v 17:48 +0100:
 On Wed, Nov 27, 2013 at 05:39:31PM +0100, David Jaša wrote:
  From fe1531dfae23baa6dfc8b88e08f273906196e1c5 Mon Sep 17 00:00:00 2001
  From: =?UTF-8?q?David=20Ja=C5=A1a?= dj...@redhat.com
  Date: Wed, 27 Nov 2013 17:04:41 +0100
  Subject: [PATCH] Use TLS version 1.0 or better
  
  When creating a TLS socket, both spice-server and spice-gtk currently
  call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
  protocol version to TLS 1.0 exclusively. The correct way to support
  multiple protocol versions is to call SSLv23_method() in spite of its
  scary name. This method will enable all protocol versions deemed secure
  by openssl project.
 
 This is not what the manpage says
 
 SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
 
A TLS/SSL connection established with these methods will understand
 the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2 client 
 hello
 messages and will indicate that it also understands SSLv3 and TLSv1. A server
 will understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the 
 best
 choice when compatibility is a concern.
 
 (nothing about protocol versions deemed secure or not secure)

Actually the documentation is outdated and the method name is
misleading. I was pointed to this fact by Tomáš Mráz, an openssl
developer and Fedora/RHEL maintainer. The thing works as described by
comit message and comment, the test results confirm it.

David

 
  ---
   server/reds.c |   10 +-
   1 files changed, 9 insertions(+), 1 deletions(-)
  
  diff --git a/server/reds.c b/server/reds.c
  index 2a0002b..fef666d 100644
  --- a/server/reds.c
  +++ b/server/reds.c
  @@ -3221,6 +3221,14 @@ static int reds_init_ssl(void)
   SSL_METHOD *ssl_method;
   #endif
   int return_code;
  +/* When some other SSL/TLS version becomes obsolete, add it to this
  + * variable.
  + *
  + * Note that SSLv23_method() even with no SSL_OP_NO_* options uses
  + * just protocol versions deemed secure by openssl project so the
  + * SSL_OP_NO_SSLv2 is already redundant
 
 Same comment
 
  + * and SSL_OP_NO_SSLv3 option is
  + * present just in order to allow only currently-availabe version or
 
 s/availabe/available
 
  + * better. */
   long ssl_options = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3;
   
   /* Global system initialization*/
  @@ -3228,7 +3236,7 @@ static int reds_init_ssl(void)
   SSL_load_error_strings();
   
   /* Create our context*/
  -ssl_method = TLSv1_method();
  +ssl_method = SSLv23_method();
   reds-ctx = SSL_CTX_new(ssl_method);
   if (!reds-ctx) {
   spice_warning(Could not allocate new SSL context);
 
 
 
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server] Use TLS version 1.0 or better

[David Jaša]

When creating a TLS socket, both spice-server and spice-gtk currently
call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
protocol version to TLS 1.0 exclusively. The correct way to support
multiple protocol versions is to call SSLv23_method() in spite of its
scary name. This method will enable all protocol versions deemed secure
by openssl project. The protocol suite may be further narrowed down by
setting respective SSL_OP_NO_version_code options of SSL context. This
possibility is used in this patch in order to block use of SSLv3 that is
enabled by default in openssl as of now but spice has never used it.
---
 server/reds.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/server/reds.c b/server/reds.c
index 2a0002b..263843f 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3221,6 +3221,14 @@ static int reds_init_ssl(void)
 SSL_METHOD *ssl_method;
 #endif
 int return_code;
+/* When some other SSL/TLS version becomes obsolete, add it to this
+ * variable.
+ *
+ * Note that SSLv23_method() even with no SSL_OP_NO_* options uses
+ * just protocol versions deemed secure by openssl project so the
+ * SSL_OP_NO_SSLv2 is already redundant and SSL_OP_NO_SSLv3 option is
+ * present just in order to allow only currently-availabe version or
+ * better. */
 long ssl_options = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3;
 
 /* Global system initialization*/
@@ -3228,7 +3236,7 @@ static int reds_init_ssl(void)
 SSL_load_error_strings();
 
 /* Create our context*/
-ssl_method = TLSv1_method();
+ssl_method = ssl_method = SSLv23_method();
 reds-ctx = SSL_CTX_new(ssl_method);
 if (!reds-ctx) {
 spice_warning(Could not allocate new SSL context);



-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Use TLS version 1.0 or better

[David Jaša]

When creating a TLS socket, both spice-server and spice-gtk currently
call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
protocol version to TLS 1.0 exclusively. The correct way to support
multiple protocol versions is to call SSLv23_method() in spite of its
scary name. This method will enable all protocol versions deemed secure
by openssl project. The protocol suite may be further narrowed down by
setting respective SSL_OP_NO_version_code options of SSL context. This
possibility is used in this patch in order to block use of SSLv3 that is
enabled by default in openssl as of now but spice has never used it.
---
 gtk/spice-channel.c |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/gtk/spice-channel.c b/gtk/spice-channel.c
index e4683f8..2e38196 100644
--- a/gtk/spice-channel.c
+++ b/gtk/spice-channel.c
@@ -2215,6 +2215,15 @@ static void *spice_channel_coroutine(void *data)
 int rc, delay_val = 1;
 gboolean switch_tls = FALSE;
 gboolean switch_protocol = FALSE;
+/* When some other SSL/TLS version becomes obsolete, add it to this
+ * variable.
+ *
+ * Note that SSLv23_method() even with no SSL_OP_NO_* options uses
+ * just protocol versions deemed secure by openssl project so the
+ * SSL_OP_NO_SSLv2 is already redundant and SSL_OP_NO_SSLv3 option is
+ * present just in order to allow only currently-availabe version or
+ * better. */
+long ssl_options = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3;
 
 CHANNEL_DEBUG(channel, Started background coroutine %p, c-coroutine);
 
@@ -2254,13 +2263,15 @@ reconnect:
 c-has_error = FALSE;
 
 if (c-tls) {
-c-ctx = SSL_CTX_new(TLSv1_method());
+c-ctx = SSL_CTX_new(SSLv23_method());
 if (c-ctx == NULL) {
 g_critical(SSL_CTX_new failed);
 emit_main_context(channel, SPICE_CHANNEL_EVENT, 
SPICE_CHANNEL_ERROR_TLS);
 goto cleanup;
 }
 
+SSL_CTX_set_options(c-ctx, ssl_options);
+
 verify = spice_session_get_verify(c-session);
 if (verify 
 (SPICE_SESSION_VERIFY_SUBJECT | SPICE_SESSION_VERIFY_HOSTNAME)) {



-- 

David Jaša, RHCE

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



smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server] Use TLS version 1.0 or better

[David Jaša]

Before writing these patches against git, I wrote them as patches to rpm
packages on my system and I performed several tests. When both packages
had the patch included, the TLS version in use was 1.2. When only one of
them had the patch included, the TLS version falled back to 1.0 (same as
status quo). I did also tests using s_client:
openssl s_client -CAfile /path/to/ca.pem -connect hostname:port -VERSION

and the server rightfully accepted TLS 1.0 - TLS 1.2. Without the patch,
only TLS 1.0 was accepted.

David


-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server] Use TLS version 1.0 or better

[David Jaša]

Daniel P. Berrange píše v St 27. 11. 2013 v 16:27 +:
 On Wed, Nov 27, 2013 at 05:23:53PM +0100, David Jaša wrote:
  When creating a TLS socket, both spice-server and spice-gtk currently
  call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
  protocol version to TLS 1.0 exclusively. The correct way to support
  multiple protocol versions is to call SSLv23_method() in spite of its
  scary name. This method will enable all protocol versions deemed secure
  by openssl project. The protocol suite may be further narrowed down by
  setting respective SSL_OP_NO_version_code options of SSL context. This
  possibility is used in this patch in order to block use of SSLv3 that is
  enabled by default in openssl as of now but spice has never used it.
  ---
   server/reds.c |   10 +-
   1 files changed, 9 insertions(+), 1 deletions(-)
  
  diff --git a/server/reds.c b/server/reds.c
  index 2a0002b..263843f 100644
  --- a/server/reds.c
  +++ b/server/reds.c
  @@ -3221,6 +3221,14 @@ static int reds_init_ssl(void)
   SSL_METHOD *ssl_method;
   #endif
   int return_code;
  +/* When some other SSL/TLS version becomes obsolete, add it to this
  + * variable.
  + *
  + * Note that SSLv23_method() even with no SSL_OP_NO_* options uses
  + * just protocol versions deemed secure by openssl project so the
  + * SSL_OP_NO_SSLv2 is already redundant and SSL_OP_NO_SSLv3 option is
  + * present just in order to allow only currently-availabe version or
  + * better. */
   long ssl_options = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3;
   
   /* Global system initialization*/
  @@ -3228,7 +3236,7 @@ static int reds_init_ssl(void)
   SSL_load_error_strings();
   
   /* Create our context*/
  -ssl_method = TLSv1_method();
  +ssl_method = ssl_method = SSLv23_method();
 
 You're setting the same variable twice.
 
 Daniel

Thanks, I've sent v2 with this error fixed.

David

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v2] Use TLS version 1.0 or better

[David Jaša]

From fe1531dfae23baa6dfc8b88e08f273906196e1c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?David=20Ja=C5=A1a?= dj...@redhat.com
Date: Wed, 27 Nov 2013 17:04:41 +0100
Subject: [PATCH] Use TLS version 1.0 or better

When creating a TLS socket, both spice-server and spice-gtk currently
call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
protocol version to TLS 1.0 exclusively. The correct way to support
multiple protocol versions is to call SSLv23_method() in spite of its
scary name. This method will enable all protocol versions deemed secure
by openssl project. The protocol suite may be further narrowed down by
setting respective SSL_OP_NO_version_code options of SSL context. This
possibility is used in this patch in order to block use of SSLv3 that is
enabled by default in openssl as of now but spice has never used it.
---
 server/reds.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/server/reds.c b/server/reds.c
index 2a0002b..fef666d 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3221,6 +3221,14 @@ static int reds_init_ssl(void)
 SSL_METHOD *ssl_method;
 #endif
 int return_code;
+/* When some other SSL/TLS version becomes obsolete, add it to this
+ * variable.
+ *
+ * Note that SSLv23_method() even with no SSL_OP_NO_* options uses
+ * just protocol versions deemed secure by openssl project so the
+ * SSL_OP_NO_SSLv2 is already redundant and SSL_OP_NO_SSLv3 option is
+ * present just in order to allow only currently-availabe version or
+ * better. */
 long ssl_options = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3;
 
 /* Global system initialization*/
@@ -3228,7 +3236,7 @@ static int reds_init_ssl(void)
 SSL_load_error_strings();
 
 /* Create our context*/
-ssl_method = TLSv1_method();
+ssl_method = SSLv23_method();
 reds-ctx = SSL_CTX_new(ssl_method);
 if (!reds-ctx) {
 spice_warning(Could not allocate new SSL context);


smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v2] Use TLS version 1.0 or better

[David Jaša]

discard this misformatted message please.

David Jaša píše v St 27. 11. 2013 v 17:39 +0100:
 From fe1531dfae23baa6dfc8b88e08f273906196e1c5 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?David=20Ja=C5=A1a?= dj...@redhat.com
 Date: Wed, 27 Nov 2013 17:04:41 +0100
 Subject: [PATCH] Use TLS version 1.0 or better
 
 When creating a TLS socket, both spice-server and spice-gtk currently
 call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
 protocol version to TLS 1.0 exclusively. The correct way to support
 multiple protocol versions is to call SSLv23_method() in spite of its
 scary name. This method will enable all protocol versions deemed secure
 by openssl project. The protocol suite may be further narrowed down by
 setting respective SSL_OP_NO_version_code options of SSL context. This
 possibility is used in this patch in order to block use of SSLv3 that is
 enabled by default in openssl as of now but spice has never used it.
 ---
  server/reds.c |   10 +-
  1 files changed, 9 insertions(+), 1 deletions(-)
 
 diff --git a/server/reds.c b/server/reds.c
 index 2a0002b..fef666d 100644
 --- a/server/reds.c
 +++ b/server/reds.c
 @@ -3221,6 +3221,14 @@ static int reds_init_ssl(void)
  SSL_METHOD *ssl_method;
  #endif
  int return_code;
 +/* When some other SSL/TLS version becomes obsolete, add it to this
 + * variable.
 + *
 + * Note that SSLv23_method() even with no SSL_OP_NO_* options uses
 + * just protocol versions deemed secure by openssl project so the
 + * SSL_OP_NO_SSLv2 is already redundant and SSL_OP_NO_SSLv3 option is
 + * present just in order to allow only currently-availabe version or
 + * better. */
  long ssl_options = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3;
  
  /* Global system initialization*/
 @@ -3228,7 +3236,7 @@ static int reds_init_ssl(void)
  SSL_load_error_strings();
  
  /* Create our context*/
 -ssl_method = TLSv1_method();
 +ssl_method = SSLv23_method();
  reds-ctx = SSL_CTX_new(ssl_method);
  if (!reds-ctx) {
  spice_warning(Could not allocate new SSL context);
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v5 2/2] Use system-wide trust certificate store

[David Jaša]

Hi Iordan,

I'm a mere Android user so this question of mine may be dumb: 

On Android, there is a system store for CAs and a user store for
certificates (not just CAs but also personal and maybe self-signed). Is
there some good way (API, fs location, ...) how can apps use these
essentially system certs?

David


i iordanov píše v Út 12. 11. 2013 v 10:55 -0500:
 Hi Christophe,
 
 I know I may be opening a can of worms with this question, but it'll
 help with supporting mobile devices, and maybe improve portability.
 
 Typically we cross-compile binaries for mobile devices, so detecting
 the location of anything automatically will yield inappropriate
 results. In addition, we cannot rely that on a mobile device the
 system-wide store is in /etc/pki, /etc/ssl or that it's accessible.
 
 Hence, would it be possible to provide an option along the lines of
 what librest provides (--with-ca-certificates=[path]), which specifies
 where to look for the system-wide CA bundle?
 
 This way, I can create a CA bundle file, add it to mobile applications
 as a resource, and then specify its location to librest and spice-gtk
 at compile time.
 
 If such an option cannot be provided, it would be nice if I can simply
 change one location in the source of spice-gtk to tell it where to
 look for the bundle. Where is that location?
 
 Thanks!
 iordan
 
 On Tue, Nov 12, 2013 at 10:23 AM, Christophe Fergeau
 cferg...@redhat.com wrote:
  On Tue, Nov 12, 2013 at 04:20:03PM +0100, Christophe Fergeau wrote:
  Currently, spice-gtk will look in $HOME/.spicec/spice_truststore.pem
  by default for its trust certificate store (to verify the certificates
  used during SPICE TLS connections). However, these days a system-wide
  trust store can be found in /etc/pki or /etc/ssl.
  This commit checks at compile time where the trust store is located,
  and then loads it before loading the user-specified trust store.
  This can be disabled at compile time using --without-ca-certificates.
 
  I forgot to amend this ;)
 
  Christophe
 
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 
 
 

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Users] desktop virtualization and GPU support

[David Jaša]

Hi,

I'm afraid that none of these cards will work. IIRC it was explained for
nVidia approach that it would be necessary to add their closed-source
code to qemu which is not going to happen.
You might have better luck with AMD card passthrough approach but I'm
not sure if GPUs can be passed through qemu/kvm and if so, how the
GPU-rendered image then gets displayed. So YMMV and don't expect much.

There is a WIP effort for qemu though that is hardware vendor agnostic -
it's based on creation of virtual GPU in qemu called Virgil that passes
3D drawing commands to GPU on host. The project is in initial stage
though so it won't be ready even for testing for quite some time. FWIW,
there has been discussion about it on spice-devel in recent days and it
will be presented on upcoming KVM forum so you can get pretty clear
picture about its status from these sources.

HTH,

David


Jorick Astrego píše v St 16. 10. 2013 v 11:58 +0200:
 We were looking at this card:
 
 It's just for a couple of users that need GPU, the rest we can arrange
 with terminal server without GPU.
 
 http://hothardware.com/News/AMD-Sets-Its-Eyes-On-New-GPU-Virtualization-Markets-Launches-S9000--S7000-Family/
 
 AMD's Citrix and VMWare support uses a mode called GPU Passthrough. In
 both cases, the software allows a virtual machine to directly access a
 GPU. In this use-case, GPUs and users are mapped in a 1:1 model, with
 one card dedicated to each client. It's also possible for Xenserver to
 create virtualized GPUs, with up to four users per card. The implication
 from AMD's presentation is that Citrix is a bit farther along than
 VMWare as far as supporting various GPU configurations, and that Remote
 FX is the most mature solution overall.
 
 Kind regards,
 
 Jorick Astrego
 Netbulae B.V.
 
 On Tue, 2013-10-15 at 20:04 -0400, Itamar Heim wrote: 
 
  On 10/14/2013 07:22 AM, Jorick Astrego wrote:
   Hi,
  
   Currently we have a customer who would like to migrate to a thin-client
   virtual desktop environment.
  
   What is the status for GPU support in ovirt? Is 1:1 or 1:4 possible,
   where we'd attach a single GPU to each VM or one GPU to 4 VM's like in
   Citrix of VMWare?
  
   If we don't add GPU's will the desktops be usable at all?
  
   Thanks in advance,
  
   Jorick Astrego
   Netbulae B.V.
  
  
   ___
   Users mailing list
   us...@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/users
  
  
  adding spice-devel.
  1:4 gpu's or monitors?
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk] Use system-wide trust certificate store

[David Jaša]

On St, 2013-09-18 at 15:24 +0200, Christophe Fergeau wrote:
 On Wed, Sep 18, 2013 at 02:11:20PM +0100, Daniel P. Berrange wrote:
  For SPICE though, users are pretty unlikely to be purchasing certs
  from the commercial CA (protection racket) vendors. They'll almost
  certainly be using their own internal CA. 
  
  The question is, would they be likely to append their own private
  CA onto the list of the global certs ?  I'm somewhat sceptical.
 
 I wrote this patch while fixing certificate handling in remote-viewer
 ovirt code. When using oVirt, the same CA is used for the web
 portal/REST API and for the SPICE TLS connections. 

This is common configuration but not a rule. For ovirt:// connections,
CA certificate should be used for connection to REST API but from there,
you should download /ca.crt and use that as a CA for spice connection
(together with actual host subject that should always be digged out of
REST API).

The scenario for such setup is to use some widely-recognized CA for API
but internal RHEV CA for stuff that is managed by RHEV (such as vdsm 
libvirt  qemu certificates).

David

 In such a setup, I don't
 think it's unlikely that the private CA will get added to the global certs
 so that the web portals work without warning screens.
 When this happens, this means that remote-viewer will be able to use
 the oVirt REST API without needing to specify any CA, but the SPICE
 connection will fail because no CA will have been set (--spice-ca-file).
 With this patch, REST and SPICE certificate checks will work/fail for the
 same hosts.
 
  Personally I'm not convinced SPICE should use the global CA list
  by default.
 
 For what it's worth, I'm not entirely convinced either that this patch is a
 good idea ;)
 
 Christophe
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] multi monitor setup ?

[David Jaša]

Hi Alexandre,

Alexandre DERUMIER píše v Pá 30. 08. 2013 v 15:36 +0200:
 Hi,
 
 I'm looking for documentation about multi monitor setup, and I can't find it.
 
 How do it work ?

For Windows VMs, up to four qxl devices can be specified on the command
line. Linux VMs will see 4 heads on the single qxl device.

 
 Do we need special qemu command line options ? (I don't use libvirt)

You need to specify multiple devices for Windows VMs. This is what
libvirt gives me (via 'virsh domxml-to-native qemu argv DOMAIN_XML'):
... -vga qxl -global qxl-vga.ram_size=67108864 -global 
qxl-vga.vram_size=33554432 -device 
qxl,id=video1,ram_size=67108864,vram_size=33554432 -device 
qxl,id=video2,ram_size=67108864,vram_size=33554432 -device 
qxl,id=video3,ram_size=67108864,vram_size=33554432 

For Linux VM, just one qxl device is OK but then it's advisable to
increase the available RAM:
...  -vga qxl -global qxl-vga.ram_size=134217728 -global 
qxl-vga.vram_size=33554432 

If you don't turn off surfaces, then you should increase vram size to
say 64 MB from current default of 32 MB.

David

 Or is it only a client side option ?
 
 Regards,
 
 Alexandre
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Feature requests for virt-viewer windows port

[David Jaša]

Fernando Lozano píše v St 28. 08. 2013 v 12:36 -0300:
 Hi Uri,
  I am also worried about authentication using spice+tls. Any user, from
  any machine, can connect to the spice+tl port. But using an ssh tunnel
  means each user needs his own ssh password or key.
 
  One can use passwords (aka tickets), to limit the access to the remote 
  machine.
  It is set on the server side (via qemu-kvm monitor or via libvirt), 
  and is asked for
  on the client side.
  Tickets have expiration time.
 
 AFAIK those tickets are fixed, shared passworlds like plain old VNC.

no and yes. The passwords can be changed at qemu command line and that's
what oVirt/RHEV does - each time a user wants to connect, a new password
is generated and set at qemu and given to the user (silently under the
hood).

 I found no docs about something smarter / more secure. Can you point me in 
 the right direction?

Spice also supports SASL for client authentication. I didn't try that
personally so I can't you tell further instructions.

 
  The problem is, virt-manager and virsh allways configure an insecure
  port. Either it is fixed, or it is auto, but never disabled. I had to
  block the insecure ports on the host using iptables, else virt-viewer
  and virt-manager never use the tls port. Looks like this is a libvirt
  fault, not qemu.
 
  I'm sure it's possible to configure the VM for your needs with libvirt.
 
  Maybe try virsh edit domain for the VM and in the
  graphics type='spice' section, remove  the port=number
  part, leaving only the tls-port=number part.
 
 Tried that, edited my kvm domain to this:
 
 graphics type='spice' tlsPort='5901' autoport='no'/
 
 After saving, if I list the config virsh shows:
 
 graphics type='spice' port='5900' tlsPort='5901' autoport='no'/
 
 Looks like it re-inserts the port attribute with a default value if 
 omited. It doesn't matter if the VM is running or not, I cannot make 
 virsh accept a graphics element without a port attribute.
 
 My libvirt release is 0.9.10, maybe you're talking about something fixed 
 on a newer release.

That sounds like old libvirt release indeed. FTR, I filed
https://bugzilla.redhat.com/show_bug.cgi?id=875729 to track the issue in
RHEL and developers indicated in comments that the issue should be fixed
in current upstream versions.

David

 
 
 PS: My fault, found that --spice-ca-file indeed works fine with 
 remote-viewer for Windows, using normal, non-escaped, Windows file 
 paths. My previous attempts failed because of typos. But I stll cannot 
 make virsh and virt-viewer for windows connect using TLS, and I won't 
 open access to libvirtd without it. The path 
 '/usr/i686-w64-mingw32/sys-root/mingw/etc/pki/CA/cacert.pem' is supposed 
 to point to where on the Windows workstations?
 
 
 []s, Fernando Lozano
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] configure: error: At least one of spice or vnc must be used on Ubuntu Desktop 12.04 x64

[David Jaša]

Hi,

Yannis Milios píše v Po 29. 07. 2013 v 17:52 +0300:
 Hello and thank you for this great software!
 
 I have Ubuntu 12.04 (x32  x64bit) and I'm trying to make spice-client to
 work by using a gui tool like virt-viewer.
 
 What I have already done:
 
 1. sudo apt-get install spice-client
 2. sudo apt-get install spice-client-gtk
 3. made a temp folder and then:
 
 wget
 http://virt-manager.et.redhat.com/download/sources/virt-viewer/virt-viewer-0.5.6.tar.gz
 
 4. tar xzvf virt-viewer-0.5.6.tar.gz and cd /virt-viewer-0.5.6
 5. sudo 

why on earth as root?

 ./configure and immediatelly after that I get the following message:

just guessing - shouldn't you also install appropriate -dev packages for
spice-gtk and gtk-vnc and invoke ./configure with appropriate
--enable-SOMETHING/--with-SOMETHING options? --help option to
configure is your friend...

If you're just after more recent virt-viewer build, why don't you take
source package from debian (with fix for
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667565 ) and why don't
you just rebuild that? Purging manually-built packages from the system
once they get obsolete is big PITA in my experience...

David

 
 configure: error: At least one of spice or vnc must be used
 
 I'm stuck at this point and don't know what to do.
 Is this the correct procedure? Is there another way to have a gui front end
 for spice-client?
 
 Thank you for your time,
 
 Yannis
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] seamless spice migration : question about password/ticket for target vm

[David Jaša]

Alexandre DERUMIER píše v Út 23. 07. 2013 v 06:55 +0200:
 So upon migration, libvirt/ovirt will set the dest VM with the same old 
 password? That sounds sane to me in general, but looks kinda against an 
 expiry-based ticket. 
 
 Yes, that's why I think is strange too. When a ticked is expired, it 
 shouldn't be reused and stored.
 
 I don't known too much the spice procotol, but I see 3 workaround:
 
 1) extend client_info_migrate to send a new ticket/password.

That IMO makes most sense.

David

 
 2) when we use qmp set_password, change the spice server password and send 
 this password to clients currently connected. (So we can renew the ticket 
 like this)
 
 3) In the case of seamless migration, why does the client need to resend the 
 password, if the session state is restored ? Maybe use some kind of session 
 cookie ?
 
 
 
 (Note, I'm working on this for Proxmox integration, I don't known if I can 
 easily implement something like this, without changing spice client ? I can 
 hack qemu or spice server).
 
 
 
 - Mail original - 
 
 De: Marc-André Lureau mlur...@redhat.com 
 À: Yonit Halperin yhalp...@redhat.com 
 Cc: Alexandre DERUMIER aderum...@odiso.com, spice-devel 
 spice-devel@lists.freedesktop.org 
 Envoyé: Lundi 22 Juillet 2013 18:50:43 
 Objet: Re: [Spice-devel] seamless spice migration : question about 
 password/ticket for target vm 
 
 Hi 
 
 - Mensaje original - 
  Hi, 
  On 07/22/2013 08:04 AM, Alexandre DERUMIER wrote: 
   Hi, 
   
   I'm trying to do migration, and I have a question about password on 
   target 
   vm. 
   
   
   If I understand, client try to connect to target vm with same password 
   (temporary ticket) used to connect to source vm. 
   
   
   But, we need to configure this password to target vm, as I think that 
   qemu 
   migration process don't copy the password between both spice server right 
   ? 
   So we need to store this password somewhere on the host, which seem to be 
   bad for security. (Seem that libvirt store it in guest config xml) 
  ovirt's vdsm sets to the destination host the same ticket that was set 
  upon the original connection. 
   
   Is it possible to generate a new ticket for target vm, and send it to the 
   client ? (I don't see any option in qmp client_migrate_info ) 
   
  I don't think there is a way to do it without changing 
  client_migrate_info and the protocol. Even if we would have a password 
  option in client_migrate_info, I don't know if libvirt can retrieve this 
  information. 
  
 
 So upon migration, libvirt/ovirt will set the dest VM with the same old 
 password? That sounds sane to me in general, but looks kinda against an 
 expiry-based ticket. It would be worth asking the ovirt folks. 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice/LTSP combo

[David Jaša]

Hi Ivan

Ivan Krutskikh píše v Čt 13. 06. 2013 v 21:19 +0400:
 Hi
 
 I like spice protocol a lot and want to integrate it into Kiwi/LTSP project
 in order to have hybrid terminal server/ VDI solution with diskless client
 machines. But there are some things, that I need to clear out first:
 
 1) In order to create an LTSP screen session, I need to start spice client
 (spicec or spicy) in full screen mode with security creditials, spice
 adress and auto usb redirection on. I can do most of it with spicec command
 line options, but it seams to lack support for usb redirection. How can I
 do the same with spicy?

dump spicec and never mind spicy, use remote-viewer (from virt-viewer
package). Note that debian (and its derivatives) builds lacked spice
support until very recently. [1]

virt-viewer supports feeding connection details via a .vv file since
0.5.5 [2] so I'd go with that (it's reasonably simple  secure; no need
for password to be exposed in process listing and the file can be
deleted after connection by virt-viewer itself if you specify
delete-this-file=1 in the file).

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667565
[2] https://www.redhat.com/archives/virt-tools-list/2013-February/msg00108.html

 
 2) Excuse me if f.a.q, but I need to make usb devices redirection possible
 for non-root users. I suppose, that should be done with udev rule, but no
 expert in hardware security issues.
 

A PolicyKit rule is shipped with usbredir (or spice-gtk?) that allows
redirection for any logged-in active local user. It's enabled by default
at least in recent Fedoras.

 3) Sometime I get video artefacts from when viewing IP cameras on a virtual
 machine. Example image attached.

What spice server and client and qxl driver versions are you using?
Similar artifacts were fixed about a year ago and didn't see anything
like this since then.

David

 I believe, this happens due to the video
 detection and mjpeg compression in spice ( h264 ip cam -- player decoding
 -- raw video -- spice stream detection and mjpeg encoding -- client
 video decoding -- raw video with artefacts). So the reasonable step would
 be to disable video stream compression for local network in libvirt xml
 file. But there are 4 parameters: image compression, jpeg compression, zlib
 compression, playback compression- I don't know which one to disable and
 how. Setting all to off and never seams to resolv the issue, but leads
 to crappy wan performance.
 
 Thanks in advance!
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Users] Cannot connect to VM via browser if engine was not in /etc/hosts

[David Jaša]

Hi,

So you're connecting via User Portal but then it doesn't work? If it
doesn't, either you hit a bug or you've tweaked some value that affects
things...

In general, TLS shouldn't pose a problem because:
1) ovirt sets up its own CA that issues certificates for the hosts
2) the CA certificate and respective host certificate subject are passed to the 
client
3) the client can verify the host using these information even in cases when 
connection IP/FQDN doesn't match CN in subject of server certificate

The only condition that indeed breaks it should be display network
address override _when migrating the VM_ (because then the connection
data are passed via the host and libvirt doesn't allow to pass the
arbitrary IP/FQDN yet)

David

PS: Itamar, advice to disable SSL/TLS is IMO bad, bad thing. ;)


Itamar Heim píše v Po 24. 06. 2013 v 08:55 +0300:
 On 06/24/2013 03:10 AM, lofyer wrote:
  于 2013/6/24 1:47, Itamar Heim 写道:
  On 06/06/2013 11:51 AM, lof yer wrote:
  I connect https://192.168.1.111 and connect to the VM, then the
  remote-viewer shows up, but failed to show the VM desktop.
  Is it the https problem?
  Can I connect to the VM without modify /etc/hosts?
 
 
  ___
  Users mailing list
  us...@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/users
 
 
 
  was this resolved? sounds like a certificate/dns issue?
  Yes, it's certificate/dns problem.
  But how can I connect via IP instead of FQDN without https?
 
 i guess it depends if you can tell spice client to not validate the ssl 
 certificate.
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

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

[David Jaša]

Hi Fedor,

I'd personally prefer to:
1) monitor bandwidth and latency continuously - there's a long-standing RFE for 
it and IIRC Yonit has posted some proof-of-concept patches in recent months (as 
a part of her streamlining of video streams)
2) set the options on-the fly as the conditions allow to get at the right 
position in b/w-saving --- cpu saving scale

The reason for this preference of mine is two-fold:
* idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN 
behaviour, especially with decreasing stream resolution
* such behaviour would be consistent with the rest of the spice protocol

I'm also not sure if I follow what you want to do with an agent:
1) the agent runs in the guest OS and communicates already with the client 
through using spice means - i.e. agent - virtio-serial/qemu - spice-server - 
spice client. You shouldn't need to invent any other client -- agent 
connection, and I can't get how such thing should help you...
2) agent has no connection of what happens with display, and it has a limited 
knowledge of network conditions as it handles just a subset of all the traffic. 
spice-server and spice client actually do have complete picture of what happens 
on the wire

David


Fedor Lyakhov píše v Ne 23. 06. 2013 v 02:26 +0400:
 Hello Zeeshan, Marc-André and other Spice developers,
 
 I think about implementing a solution for this bug 62033 (
 https://bugs.freedesktop.org/show_bug.cgi?id=62033).
 
 First of all, need to clarify what is requested and what is really needed
 in this request. Zeeshan suggests as a simple yet acceptable solution for
 vdagent to report 'local-only' connection non-dynamically.. as I understand
 this means reporting only once, at startup (?). I think it isn't enough
 because this connection state may change easily during X session lifetime -
 in general user is free to connect locally and then re-connect from remote
 host, and vise versa. So I propose more generic approach, when vdagent
 reports current connection state dynamically when state is changed. It will
 be up to gnome-settings-daemon to act on this signal and toggle animations
 accordingly.
 
 If this is acceptable, we need to decide on the interface. I think there
 are 2 appropriate technologies:
 1. raw socket [or something like this]
 2. D-Bus
 
 I'm not an expert in D-Bus and freedesktop in general (good opportunity for
 me to learn!) but looks like it is appropriate to use it here. 2 questions
 arise:
 1. vdagentd and vdagent daemons already communicate via socket using simple
 homebrew protocol (at least afaik). Probably this was done on purpose. So
 is it true vdagent wants to avoid dependency on D-Bus?
 2. It seems to better use some higher-level D-Bus bindings (GLib, Qt...)
 instead of its low-level API. So is it acceptable to add a dependency of
 GLib to vdagent? Or are you aware of some other D-Bus bindings to be used
 in vdagent to avoid this extra dependency?
 
 BTW, reporting of connection state can be implemented independently of the
 actual transport (socket/D-Bus):
 1. Client app (e.g. gnome-settings-daemon) establishes connection to
 vdagent being a server (e.g. listening at the socket, or providing D-Bus
 interface method RegisterConnectionStateObserver or w/e we name it)
 2. vdagent sends the state to registered clients (e.g. D-Bus signal); and
 continues to do so each time the state is changed.
 So we can even have 2 back-ends for this (additional work, unfortunately).
 
 And last question: while this isn't needed on Windows version of vdagent
 right now, additional use cases of this vdagent interface in guest
 userspace may arise [e.g. I'm thinking about remote media engine provided
 by spice client]. So I think we should target for similar extendable
 interface at both Windows and Linux guests (as much as possible). I haven't
 looked in vdagent for Windows code yet but guess D-Bus won't be the best
 choice there (while D-Bus reportedly works on Windows as well...).
 Something like socket and D-Bus and native DCOM would be the best and
 future-proof.. What do you think?
 
 [Note: I haven't talked about implementation of new messages between
 vdagent and vdagentd, and spice-server, and the actual local/remote
 detection code - will ask questions later]
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] USB redirected wacom tablet

[David Jaša]

Hans, Arnon, Marc-André et al.,

how difficult would be for spice-gtk to capture wacom-specific events
[1] and for spice-vdagent to pass them to the guest? Would that need
changes to spice-server  spice-protocol too?

[1] 
http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=How_Wacom_tablets_work#USB_Tablets


Tomáši,

I'm afraid that you can't get rid of the cursor lag when using
redirected device as the client has no knowledge about it so it can't
display it right away so you're stuck with server cursor mode -that
means that the cursor position has to reach the VM, spice-server has to
render it and then it must be transmitted over the networks. So it takes
whole roundtrip from pointer position change to visual feedback and I
can't see any way around that but the spice components awareness of
wacom devices as above...

David


Tomáš Chaloupka píše v Ne 16. 06. 2013 v 22:22 +0200:
 Hi Uri,
 thaks for your help.
 
 I tried this today. It takes some time to find how to set this option in
 libvirt as it is needed to set in domain XML.
 
 To make it work I had to remove the virtual tablet device. After that
 server mode works and I can see the cursor from the mouse and from the
 redirected tablet as well.
 Problem is, that in the server mode cursor response is far from smooth
 (even right on the host) which make it pretty unusable to draw something.
 
 Is there any other chance to solve it better way?
 
 Thanks,
 Tom
 
 
 
 2013/6/16 Uri Lublin u...@redhat.com
 
  On 06/15/2013 12:07 AM, Tomáš Chaloupka wrote:
 
  Hello,
  I'm trying to use my wacom tablet on virtualized W7 over spice usb redir.
  Tried it on Fedora18 (virt-viewer-0.5.4), usb redirection worked fine,
  driver was installed and device is working well.
 
  Only problem with this setup is that the tablet pointer is not visible,
  so when I try to control guest OS or just draw something with pen I can't
  see the actual position. Only mouse pointer is visible on it's last
  position.
 
 
  Hi Tomáš,
 
  Does it help if you stop running the vdagent on the guest (net stop
  vdservice) ?
 
  If it does, you can try adding to qemu-kvm command line option -spice
  the following: agent-mouse=off
 
  Uri.
 
  __**_
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.**org Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/**mailman/listinfo/spice-develhttp://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] New SPICE client for Android

[David Jaša]

Hi Iordan,

On Ne, 2013-06-09 at 19:11 -0400, iiorda...@gmail.com wrote:
 Hello everyone!
 
 I put together my multi-touch UI from bVNC with spice-gtk to create a
 SPICE client for Android called aSPICE. It has integrated SSH
 tunneling functionality. The entire project is open source, 

would you mind adding your projects to f-droid repository? The more
open-source apps are there, the better. :)

I also noticed no SSL/TLS connection options, did you have problems
building it, or is it just omitted from the GUI?

Anyway, I've tried it and it works really nice!

David


 and is currently based on spice-gtk v.0.19. The source is available
 here:
 https://github.com/iiordanov/bVNC
 
 There are a free and a donation version of aSPICE:
 
 https://play.google.com/store/apps/details?id=com.iiordanov.freeaSPICE
 https://play.google.com/store/apps/details?id=com.iiordanov.aSPICE
 
 
 For reference, this project stems from a VNC client called bVNC:
 
 https://play.google.com/store/apps/details?id=com.iiordanov.freebVNC
 https://play.google.com/store/apps/details?id=com.iiordanov.bVNC
 
 
 And a RDP client called aRDP:
 
 https://play.google.com/store/apps/details?id=com.iiordanov.freeaRDP
 https://play.google.com/store/apps/details?id=com.iiordanov.aRDP
 
 
 I hope my contribution will be of use to everyone here and will
 encourage more people to adopt the SPICE protocol with this increased
 client availability.
 
 
 Your suggestions and contributions are highly appreciated!
 
 
 
 Sincerely,
 iordan iordanov
 
 
 -- 
 The conscious mind has only one thread of execution.
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] Spice test day Review

[David Jaša]

Hi all,

This is the wrap-up of the Spice Test Day for in Fedora 19 that took
place on May 28, 2013. Few stats first:

Bugs filed - Red Hat bugzilla:
968929 NEW  - [abrt] gnome-boxes-3.8.2-5.fc19: rest_proxy_call_cancel: Process 
/usr/bin/gnome-boxes was killed by signal 11 (SIGSEGV)
968931 NEW  - Crash in Xspice after closing tab with spice-html5
969069 NEW  - VM crashes when connecting from F19 client
969084 NEW  - crash in qemu after adding spice vdagent channel
969109 ASSIGNED  - guest crashes after transferring a large file using 
drag'n'drop
969118 NEW  - cdrom is disconnected after first reboot

Bugs filed - Freedesktop:
65185 NEW  - Xspice: failure to bind to port should be an error, not a warning

People involved:
logged in the wiki: 5 (4 from RH)
attending just on IRC: 3 (1 from RH)
people actively looking after the Test Day on IRC: 4 (3 from RH)

Given pretty late announcement, the response to test day was pretty good, 
people tested both the new and existing stuff in good number on test setups, 
producing lots of relevant feedback.

Thank you everybody who was involved!

I'd also like to give special credits here to:
  * Dunrong Huang, who single-handedly contributed whole file-transfer feature
  * folks at Codeweavers for contributions to Xspice and creation of 
spice-html5 projects
  * Jeremy White in particular for his part in organizing this Test Day

David

-- 

David Jaša, RHCE

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







smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk 2/5] session: Lookup URI query part before path part

[David Jaša]

Just for the record: path is part of hierarchical part of the uri that
begins with double slash //. Query part of the URI starts with
question mark ? and it is followed by Fragment part that starts with
hash #. So this is perfectly legal URI:

spice://fqdn?param=value

that contain just scheme (spice), hostname (fqdn) and query
(param=value) sections.

BTW the password could be conveyed via uri in the more
standards-following way:

spice://:password@fqdn[port][path][query][fragment]

IIRC there used to be a generic parser for URIs in glib that was removed
at some point of time, didn't you think about making this code more
generic so that each and every URI-parsing glib app doesn't have to go
through these hoops over and over again?

David


Christophe Fergeau píše v St 05. 06. 2013 v 14:21 +0200:
 On Wed, Jun 05, 2013 at 01:07:16PM +0300, Uri Lublin wrote:
  In your example, query is my_param=/some/path and path points
  to /some/path within query. Some may find it confusing, and it does not
  follow URI syntax where path comes before query (IIUC).
 
 This is not meant to move the 'path' part of the URI in the params, but to
 allow the params to contain '/' without confusing SPICE URI parser.
 You can change the example to
 scheme://foo.example.com?mimetype=text/plain
 if that makes things less confusing.
 
 Christophe
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Users] [Test-announce] Thursday is Spice Test Day for Fedora 19!

[David Jaša]

Fixed.


David Jaša píše v Čt 30. 05. 2013 v 09:53 +0200:
 Ahoj Jakube,
 
 thanks for notification. I'll reach out to people who have powers to fix
 it...
 
 David
 
 Jakub Bittner píše v Čt 30. 05. 2013 v 09:30 +0200:
  Dne 30.5.2013 00:40, David Jas(a napsal(a):
   Hi All,
  
   The day has come to test Spice! Several cool new features have landed in
   Fedora 19 builds of spice:
  * drag'n'drop file transfer support from client system to guest system
  * Xspice spice server running inside the remote OS
  * spice-html5 pure Javascript client
   There are test cases for the respective features described on the Test
   Day page on Fedora Wiki:
   https://fedoraproject.org/wiki/Test_Day:2013-05-30_Spice
  
  
   if you have any questions, ask on IRC channels (#fedora-test-day @
   Freenode, #spice @ gimpnet)
  
   Happy testing!
  
   David
  
  
  
   ___
   Users mailing list
   us...@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/users
  
  Hi David,
  
  I can not download 
  http://fedorapeople.org/groups/qa/testday-20130530-x86_64.iso as 
  described on wiki ( 
  https://fedoraproject.org/wiki/Test_Day:2013-05-30_Spice#Live_CDs), I 
  got Forbidden. i686 version is fine.
  
  Thanks.
  ___
  Users mailing list
  us...@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/users
 
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [Test-announce] Thursday is Spice Test Day for Fedora 19!

[David Jaša]

Hi All,

The day has come to test Spice! Several cool new features have landed in
Fedora 19 builds of spice:
  * drag'n'drop file transfer support from client system to guest system
  * Xspice spice server running inside the remote OS
  * spice-html5 pure Javascript client
There are test cases for the respective features described on the Test
Day page on Fedora Wiki:
https://fedoraproject.org/wiki/Test_Day:2013-05-30_Spice


if you have any questions, ask on IRC channels (#fedora-test-day @
Freenode, #spice @ gimpnet)

Happy testing!

David

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] how to recognise usb device

[David Jaša]

Hi,

bigclouds píše v Čt 23. 05. 2013 v 16:56 +0800:
 hi,all
 i know that usb can be catgoryed by class.

It's based on USB standards. Quick check with google gave me this link
that seems authoritative:
http://www.usb.org/developers/defined_class

David


 i want to know how spice  to recignize and categroy usb devices?
 storage,mouse,keyboard
 and where is the code.
  
 thanks.
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] which chennel whose value is 2 or 5?

[David Jaša]

Hi,

bigclouds píše v Pá 17. 05. 2013 v 10:51 +0800:
 hi, please tell me   what is the channel type  whose value is 2 ,5?

as defined in this enum of spice-protocol:
http://cgit.freedesktop.org/spice/spice-protocol/tree/spice/enums.h#n368

2 is display channel and 5 is playback channel

David

 any other channels and its value.
 thanks.
 reds_handle_link: YY client connection 192.168.5.188, 5901
 reds_handle_link: YY client connection 192.168.5.129, 38167
 reds_handle_link: YY client channeltype 2
 reds_handle_link: YY client connection 192.168.5.188, 5901
 reds_handle_link: YY client connection 192.168.5.129, 38165
 reds_handle_link: YY client channeltype 5
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] resolution

[David Jaša]

Why don't you use remote-viewer? It's available precompiled for download
at downloads page and it will work better for you if you want just to
use spice.

On topic - the client resolution change is the way of old spicec to get
remote guest monitor displayed fullscreen as it made almost no harm on
CRTs and CPU power for software scaling was way more scarce. The
opposite is true these days so remote-viewer won't touch your client
resolution at all but it will try to adjust remote system resolution to
best match current view and if that won't be possible, it will scale the
remote guest monitor to fit the widget viewport.

David


天外银龙 píše v Ne 12. 05. 2013 v 11:17 +0800:
 When I have compiled spicy.exe on fodera14,run it on windows,the
 resolution(DPI) and colour will change both local and remote
 desktop.Can you help me?Thank you~
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] why spice server is not aware of client-disconnection.

[David Jaša]

This is because spice relies on default tcp behaviour. IMO the only
alternative is to have some heartbeat in main channel that would
initiate client disconnection if the connection is interrupted.

Spice behaviour is analogous to e.g. IRC behaviour while the latter is
similar to e.g. XMPP/Jabber (or other non-archaic IM) protocols that
detect disconnections almost instantly.

David


bigclouds píše v Út 14. 05. 2013 v 17:38 +0800:
 hi,all
 look at the output of  netstat, it is after at least 30minutes i
 un-plug cable.
 how to make server know client's disconnect and disconnect
 channels(clean channels).
 
 
 tcp0  0 192.168.5.240:5903  192.168.5.163:60029
 ESTABLISHED 31315/qemu-kvm  
 tcp0  0 192.168.5.240:5903  192.168.5.163:60033
 ESTABLISHED 31315/qemu-kvm  
 tcp0  0 192.168.5.240:5903  192.168.5.163:60028
 ESTABLISHED 31315/qemu-kvm  
 tcp0  24815 192.168.5.240:5903  192.168.5.163:60030
 ESTABLISHED 31315/qemu-kvm  
 tcp0  0 192.168.5.240:5903  192.168.5.163:60019
 ESTABLISHED 31315/qemu-kvm  
 tcp0  0 192.168.5.240:5903  192.168.5.163:60027
 ESTABLISHED 31315/qemu-kvm  
 tcp0  0 192.168.5.240:5903  192.168.5.163:60032
 ESTABLISHED 31315/qemu-kvm  
 tcp0  0 192.168.5.240:5903  192.168.5.163:60031
 ESTABLISHED 31315/qemu-kvm nbsp ;
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] network down lead vm been shutdown

[David Jaša]

Hi,

bigclouds píše v Pá 03. 05. 2013 v 10:02 +0800:
 hi, Hans de Goede
 please first have a look at
 https://bugzilla.redhat.com/show_bug.cgi?id=852897 ,

Then you should update your host to Centos 6.4, as per
https://bugzilla.redhat.com/show_bug.cgi?id=852897#c4 , the bug should
be fixed in RHEL 6.4 (spice-server-0.12-something).

David

   this link does not give a final result
 my problem look like same .
 system:spice-server-0.10.1-10.el6.x86_64  centos6.3.  guest is
 winxp-32B
 what should i do, update spice-server  or  guest agent tool(qxl
 driver)?
 and please explain to me  the root cause of this bug.
  
 thanks very much.
 
 
 
 
 
 
 
 
 At 2013-05-02 22:38:16,David Jaša dj...@redhat.com wrote:
 What's interesting is that !worker-surfaces[surface_id].context.canvas 
 string in RH bugzilla returns bug 674055 that is duplicate of bug 678208 (in 
 qemu-kvm) that should have been fixed in RHEL 6.3.
 
 Could you retest on centos 6.4, please? There were similar bugs fixed in 6.4 
 cycle.
 
 David
 
 
 bigclouds píše v Čt 02. 05. 2013 v 18:17 +0800:
  infos:
  spice-server-0.10.1-10.el6.x86_64,centos 6.3
  
  
  
  
  
  
  
  At 2013-05-02 17:49:02,bigclouds bigclo...@163.com wrote:
  hi,all 
  the connection between  remote-viewer and  guest is good, now 
  unplug Network Cable, wait several minutes, then kill virt-viewer.
  now guest will be shutdwn.
  ---winxp.log of libvirt--
  handle_dev_display_connect: connect
  handle_new_display_channel: add display channel client
  handle_new_display_channel: New display (client 0x7f1cbf9f6ed0) 
  dcc 0x7f1c584db2b0 stream 0x7f1cbfd61560
  handle_new_display_channel: jpeg disabled
  handle_new_display_channel: zlib-over-glz disabled
  listen_to_new_client_channel: NEW ID = 0
  display_channel_client_wait_for_init: creating encoder with id == 0
  reds_handle_read_link_done: spice channels 3 should be encrypted
  reds_handle_auth_mechanism: Auth method: 1
  reds_show_new_channel: channel 3:0, connected successfully, over 
  Secure link
  inputs_connect: inputs channel client create
  flush_display_commands: update timeout
  red_channel_client_disconnect: 0x7f1c584db2b0 (channel 
  0x7f1c580458d0 type 2 id 0)
  display_channel_client_on_disconnect:
  validate_surface: failed on 13
  validate_surface: panic 
  !worker-surfaces[surface_id].context.canvas
  2013-05-02 09:00:16.717+: shutting down
   
   
   
  
  
  
  
  ___
  Spice-devel mailing list
  Spice-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/spice-devel
 
 -- 
 
 David Jaša, RHCE
 
 SPICE QE based in Brno
 GPG Key: 22C33E24 
 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
 
 
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice backend for Weston

[David Jaša]

[resending to the list, Юрий, please reply to this message]

Hi,

Shvedov Yury píše v Po 29. 04. 2013 v 16:37 +0400:
 Hello.
 
 As part of my course work, I've developed spice backend for Weston (the 
 reference implementation of Wayland compositor). 

Nice!

 Currently this uses
 Wayland's pixman-based renderer, and shares rendered frames over spice
 protocol. 

Have you looked into possibility of rendering  sending of each buffer
(is it the correct term?) and sending them to the client independently
so that final compositing could be deferred to the client?

IMO that approach has the biggest potential of b/w saving for use cases
such as window move or pop-up window appears and it's dismissed.

 With my backend, it is possible to communicate with wayland
 desktop using spice client.
 
 Current implementation is proof-of-concept only. Only shm buffers are 
 supported, and no attempt is made to optimize bandwidth. Performance is 
 expectedly bad. The first goal was just to make it working, and now it 
 works - at least if client and server are on the same physical host.
 
 In future, I plan to utilize GL both for rendering and calculating 
 difference between frames. With this approach I hope to get both 
 full-functional desktop and minimize server and bandwidth requirements.
 

That sounds like something that John A. Sullivan III would
appreciate. :)

David

 My code is available at
 https://github.com/ein-shved/compositor-spice.git
 
 Comments and/or bugfixes are greatly appreciated.
 
 P.S.
 I know that recently RDP backend was added to Weston.
 I was not aware of that while working on my backend.
 I hope it will be possible to share effort with that project to build 
 better remote wayland solutions.
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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





smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] network down lead vm been shutdown

[David Jaša]

What's interesting is that !worker-surfaces[surface_id].context.canvas 
string in RH bugzilla returns bug 674055 that is duplicate of bug 678208 (in 
qemu-kvm) that should have been fixed in RHEL 6.3.

Could you retest on centos 6.4, please? There were similar bugs fixed in 6.4 
cycle.

David


bigclouds píše v Čt 02. 05. 2013 v 18:17 +0800:
 infos:
 spice-server-0.10.1-10.el6.x86_64,centos 6.3
 
 
 
 
 
 
 
 At 2013-05-02 17:49:02,bigclouds bigclo...@163.com wrote:
 hi,all 
 the connection between  remote-viewer and  guest is good, now unplug 
 Network Cable, wait several minutes, then kill virt-viewer.
 now guest will be shutdwn.
 ---winxp.log of libvirt--
 handle_dev_display_connect: connect
 handle_new_display_channel: add display channel client
 handle_new_display_channel: New display (client 0x7f1cbf9f6ed0) dcc 
 0x7f1c584db2b0 stream 0x7f1cbfd61560
 handle_new_display_channel: jpeg disabled
 handle_new_display_channel: zlib-over-glz disabled
 listen_to_new_client_channel: NEW ID = 0
 display_channel_client_wait_for_init: creating encoder with id == 0
 reds_handle_read_link_done: spice channels 3 should be encrypted
 reds_handle_auth_mechanism: Auth method: 1
 reds_show_new_channel: channel 3:0, connected successfully, over 
 Secure link
 inputs_connect: inputs channel client create
 flush_display_commands: update timeout
 red_channel_client_disconnect: 0x7f1c584db2b0 (channel 0x7f1c580458d0 
 type 2 id 0)
 display_channel_client_on_disconnect:
 validate_surface: failed on 13
 validate_surface: panic !worker-surfaces[surface_id].context.canvas
 2013-05-02 09:00:16.717+: shutting down
  
  
  
 
 
 
 
 ___
 Spice-devel mailing list
 Spice-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] how to limit redirected usb show in guestVM

[David Jaša]

bigclouds píše v Čt 25. 04. 2013 v 09:41 +0800:
 hi,all
 if user has several usb, and plug them at the same time when using
 spice-client. all usb devices will be present in guestVM.
 i want to know   if i can control which usb device can be present in
 guestVM?

Yes, you can, using filter string. There is actually a default filter
string in the client that prevents auto-redirection of USB HID devices
(keyboard and mouse).

Filter string can be set on client side (this one controls
auto-redirection) or on server-side (this enforces that disabled devices
can not be redirected to the guest). The basic format is
class,vendor,device,revision,enable with -1 as a wildcard, so when
you launch client with:
--spice-usbredir-auto-redirect-filter=-1,-1,-1,-1,0
no USB device will be auto-redirected. If you specifiy -1,-1,-1,-1,0|
8,-1,-1,-1,1, only USB mass storage devices will be auto-redirected.

The full documentation of filter string used to be on Hans's site:
http://people.fedoraproject.org/~jwrdegoede/spice-reference/SpiceUsbDeviceManager.html#SpiceUsbDeviceManager--auto-connect-filter
but it seems to be gone now. Hans, where does it reside now, please?

oVirt also had some knobs in engine-config that control filter string
sent to the client but I don't remember what was its name.

David

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

-- 

David Jaša, RHCE

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




smime.p7s
Description: S/MIME cryptographic signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel