Re: err in dockerfile (for xspice)

2024-02-15 Thread Uri Lublin
Hi Ali,

On Thu, Feb 15, 2024 at 11:05 AM Ali Dehghan 
wrote:

> Hey,
>
> I followed your instructions in the page Demo of your website (
> https://www.spice-space.org/demos.html) and something went wrong.
>
> When I make a dockerfile and put your text into it
>
> FROM fedora:latestRUN dnf install -y xorg-x11-server-XspiceEXPOSE 5900/tcpENV 
> DISPLAY=:1.0
>
> CMD Xspice --port 5900 --disable-ticketing $DISPLAY  > /dev/null 2>&1 &  
> /usr/bin/bash
>
>
> , it doesn't start X server but if I run your docker image
> quay.io/spice/xspice:latest, everything is ok.
>

> I wanted to use xspice for browser isolation. When I install chrome on
> your docker-image it is okay and xspice works well (but your image fedora
> is outdated). When I use your suggested content in dockerfile, it fails.
>
> Would you please check and correct dockerfile suggested, or send me the
> content of quay.io/spice/xspice:latest?
>

The instructions are available with the demo.
It seems there is a problem running X server with fedora:latest (currently
f39).
The demo is running Fedora 31 - replacing "fedora:latest" with "fedora:31"
works for me.

Regards,
Uri.


Re: [Spice-devel] [PATCH spice-common] build: Avoid Meson warning

2023-11-05 Thread Uri Lublin
Hi Frediano,

On Fri, Nov 3, 2023 at 10:59 AM Frediano Ziglio  wrote:

> Avoids:
>
> WARNING: You should add the boolean check kwarg to the run_command call.
>  It currently defaults to false,
>  but it will default to true in future releases of meson.
>  See also: https://github.com/mesonbuild/meson/issues/9300
>
> Signed-off-by: Frediano Ziglio 
>

Acked-by: Uri Lublin 

>From a quick scan of the git repositories, there is a 'check' missing in
usbredir too.

Thanks,
Uri.



> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 1018769..33f8f8a 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -132,7 +132,7 @@ if spice_common_generate_client_code or
> spice_common_generate_server_code
>if get_option('python-checks')
>  foreach module : ['six', 'pyparsing']
>message('Checking for python module @0@'.format(module))
> -  cmd = run_command(python, '-c', 'import @0@'.format(module))
> +  cmd = run_command(python, '-c', 'import @0@'.format(module), check
> : false)
>if cmd.returncode() != 0
>  error('Python module @0@ not found'.format(module))
>endif
> --
> 2.41.0
>
>


Re: [Spice-devel] spice protocal connection issue

2023-10-15 Thread Uri Lublin
Hi,

On Thu, Oct 12, 2023 at 9:43 PM Victor Toso  wrote:

> On Wed, Oct 11, 2023 at 04:31:56PM +0800, 王雪松 wrote:
> > Hi:
> > I have a question. Within the same local area network, I can
> > freely access the virtual machine using Spice, but other
> > machines often fail to connect.
>
> This should be a matter of can or cannot. You either have access
> to the host:port from where spice server is running, or you
> don't.
>
> > It takes dozens of attempts sometimes to successfully establish
> > a connection. I'd like to know the reason behind this.
>
> Me too. Do you run behind a proxy? Any other devices in between
> that might be doing something with the network?
>

Additionally, the network may be too slow and timeouts occur.


>
> > Could it be due to a caching mechanism or some restrictions
> > that limit other people's login access? Thank you.
> Regards
> Not really. If a user is logged in and a second one tries to log,
> the second one gets access while the first one is disconnected.
>
> I don't remember any settings that would change that behavior.
>

Probably does not count as "settings", but the monitor-command
set_password has an option to fail if a client is already connected.

Regards,
Uri


Re: [Spice-devel] 0.42: build fails

2023-09-06 Thread Uri Lublin
On Wed, Sep 6, 2023 at 11:17 AM Tomasz Kłoczko 
wrote:

> HI,
>

Hi,


>
> Looks like it is some issue with 0.42.
> Build fails on linking libspice-client-glib with missing vevent_*  symbols.
>
I'm configuring source code with:
>
> %meson \
> -D alignment-checks=false \
> -D builtin-mjpeg=false \
> -D gtk=enabled \
> -D introspection=enabled \
> -D lz4=enabled \
> -D polkit=enabled \
> -D usb-acl-helper-dir=%{_libexecdir}/spice-gtk-%{_arch}/ \
> -D usb-ids-path=%{_datadir}/hwdata/usb.ids \
> -D usbredir=enabled \
> -D vapi=enabled \
> -D webdav=enabled \
> %{nil}
>


What distribution are you building this on ?
Seems like there is a problem with the libcacard-devel package.
Meson seems to find it but libcacard.so is not found by the gcc command.

I can build spice-gtk on a Fedora38 with this meson command.

Regards,
Uri.




>
> Here is meso output
>
> + /usr/bin/meson setup --buildtype=plain --prefix=/usr --libdir=/usr/lib64
> --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin
> --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man
> --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc
> --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload
> --auto-features=enabled . x86_64-redhat-linux-gnu -D alignment-checks=false
> -D builtin-mjpeg=false -D gtk=enabled -D introspection=enabled -D
> lz4=enabled -D polkit=enabled -D
> usb-acl-helper-dir=/usr/libexec/spice-gtk-x86_64/ -D
> usb-ids-path=/usr/share/hwdata/usb.ids -D usbredir=enabled -D vapi=enabled
> -D webdav=enabled
> The Meson build system
> Version: 1.2.1
> Source dir: /home/tkloczko/rpmbuild/BUILD/spice-gtk-0.42
> Build dir:
> /home/tkloczko/rpmbuild/BUILD/spice-gtk-0.42/x86_64-redhat-linux-gnu
> Build type: native build
> Project name: spice-gtk
> Project version: 0.42
> C compiler for the host machine: /usr/bin/gcc (gcc 13.2.1 "gcc (GCC)
> 13.2.1 20230728 (Red Hat 13.2.1-1)")
> C linker for the host machine: /usr/bin/gcc ld.bfd 2.41-5
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Library m found: YES
>
> Executing subproject spice-common
>
> spice-common| Project name: spice-common
> spice-common| Project version: undefined
> spice-common| C compiler for the host machine: /usr/bin/gcc (gcc 13.2.1
> "gcc (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1)")
> spice-common| C linker for the host machine: /usr/bin/gcc ld.bfd 2.41-5
> spice-common| Has header "alloca.h" : YES
> spice-common| Has header "arpa/inet.h" : YES
> spice-common| Has header "dlfcn.h" : YES
> spice-common| Has header "inttypes.h" : YES
> spice-common| Has header "netinet/in.h" : YES
> spice-common| Has header "stdlib.h" : YES
> spice-common| Has header "sys/socket.h" : YES
> spice-common| Has header "sys/stat.h" : YES
> spice-common| Has header "sys/types.h" : YES
> spice-common| Has header "unistd.h" : YES
> spice-common| Has header "regex.h" : YES
> spice-common| Has header "sys/mman.h" : YES
> spice-common| Checking for function "alloca" : YES
> spice-common| Checking for function "sigaction" : YES
> spice-common| Checking for function "drand48" : YES
> spice-common| Checking for function "setlinebuf" : YES
> spice-common| Library m found: YES
> spice-common| Found pkg-config: /usr/bin/pkg-config (1.9.5)
> spice-common| Run-time dependency spice-protocol found: YES 0.14.4
> spice-common| Run-time dependency glib-2.0 found: YES 2.77.3
> spice-common| Run-time dependency pixman-1 found: YES 0.42.2
> spice-common| Run-time dependency openssl found: YES 3.0.9-dev
> spice-common| Run-time dependency gio-2.0 found: YES 2.77.3
> spice-common| Run-time dependency opus found: YES 1.4
> spice-common| Program python3 found: YES (/usr/bin/python3)
> spice-common| Message: Checking for python module six
> spice-common| WARNING: You should add the boolean check kwarg to the
> run_command call.
> spice-common| It currently defaults to false,
> spice-common| but it will default to true in future releases of meson.
> spice-common| See also: https://github.com/mesonbuild/meson/issues/9300
> spice-common| Message: Checking for python module pyparsing
> spice-common| Run-time dependency libcacard found: YES 2.8.1
> spice-common| Compiler for C supports arguments -DG_LOG_DOMAIN="Spice": YES
> spice-common| Compiler for C supports arguments -Wno-unused-parameter: YES
> spice-common| Compiler for C supports arguments
> -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_38: YES
> spice-common| Compiler for C supports arguments
> -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_38: YES
> spice-common| Run-time dependency gdk-pixbuf-2.0 found: YES 2.42.10
> spice-common| Program asciidoc found: NO
> spice-common| Configuring config.h using configuration
> spice-common| Build targets in project: 14
> spice-common| Subproject spice-common finished.
>
>
> Executing subproject keycodemapdb
>
> keycodemapdb| Project name: keycodemapdb
> keycodemapdb| 

Re: [Spice-devel] spice-streaming-agent display problem

2023-07-30 Thread Uri Lublin
Hi,

On Thu, Jul 27, 2023 at 10:52 AM 霍金鹏 <32217...@mail.dlut.edu.cn> wrote:

> Hello dear devs,
>
> I installed VMware Workstation Pro on my laptop , and I installed a
> CentOS8 virtual machine . Then in CentOS8 , another Ubuntu18.04 virtual
> machine was installed via virt manager . So CentOs8 is host , Ubuntu18.04
> is guest , and there is another windows7 virtual machine in VMware
> Workstation Pro , windows7 is client .
>
> Now I'm using spice-streaming-agent, I built it in Ubuntu18.04 , and I had
> added the "org.spice-space.stream.0" channel .
>
> Then when I want to access this Ubuntu18.04 in another  windows system via
> remote-viewer , old spice display works well and the
> spice-streaming-agent creates a new window in remote-viewer , but the new
> display window has no picture , just black . And in Ubuntu18.04's terminal
> , there is a warning : spice-streaming-agent[9710]: Warning: the Frame
> Capture plugin returned device display info for more than one display
> device, but we currently only support a single device. Sending information
> for first device to the server.
>
>
> What should I do to solve this problem ?
>

You can try to run in debug-mode and look at logs on the guest.

What are you trying to do ?  Why do you want to use spice-streaming-agent
when "regular" spice works ?

Regards,
Uri.




> Thanks in advance !
>


Re: [Spice-devel] Help with image encoding

2023-07-20 Thread Uri Lublin
On Wed, Jul 19, 2023 at 10:55 AM Frediano Ziglio  wrote:

> Il giorno dom 16 lug 2023 alle ore 07:58 Néfix Estrada
>  ha scritto:
> >
> > Hello! I'm currently writting a Spice client in Typescript that makes
> > use of modern browser features (such as WebGPU, WebUSB, Web workers,
> etc).
> >
> >
> > However, I'm struggling with the Image image encoding. I've checked the
> > whole documentation site, but I wasn't able to find how each one of the
> > encoding works. My knowledge in both audio and video encoding is very
> > limited. Specifically:
> >
> > - QUIC
> >
> > - LZ (and all its variants)
> >
> >
> > I've been trying to understand them from the spice-common project, but
> > it's just the implementation without any type of docs :(
> >
> > Another question I had is if there's another way of comunication or a
> > place where I can shoot questions about the implementation
> >
> >
> > Also, I'm planning on gifting the client to the spice project, if you
> > would be interested in! (given that you already have a JS project)
> >
> >
> > Thanks in advance!
> >
> >
> > Néfix Estrada
> >
>
> Hi,
>why not look at SPICE html client instead? It's already JS code so
> it  shouldn't be that different.
> For QUIC you can see Uri's link if you need some notes, LZ is more or
> less standard on decoding, you have uncompressed sections and
> references to previous chunks, so it's just a matter of understanding
> these encodings.
>

There is also a link in spice-common/common/lz.h:
" dictionary compression for images based on fastlz (http://www.fastlz.org/)
"

Uri.



>
> Regards,
>Frediano
>
>


Re: [Spice-devel] Help with image encoding

2023-07-17 Thread Uri Lublin
Hello,

On Sun, Jul 16, 2023 at 9:58 AM Néfix Estrada 
wrote:

> Hello! I'm currently writting a Spice client in Typescript that makes
> use of modern browser features (such as WebGPU, WebUSB, Web workers, etc).
>
>
> However, I'm struggling with the Image image encoding. I've checked the
> whole documentation site, but I wasn't able to find how each one of the
> encoding works. My knowledge in both audio and video encoding is very
> limited. Specifically:
>

There is not much documentation about image encoding.



>
> - QUIC
>

At the top of common/quic.c there are these two lines:
// Red Hat image compression based on SFALIC by Roman Starosolski
// http://sun.iinf.polsl.gliwice.pl/~rstaros/sfalic/index.html




>
> - LZ (and all its variants)
>
>
> I've been trying to understand them from the spice-common project, but
> it's just the implementation without any type of docs :(
>
> Another question I had is if there's another way of comunication or a
> place where I can shoot questions about the implementation
>

I think sending an email to this mailing list is fine.
There is also an IRC channel.

Kind Regards,
Uri.



>
> Also, I'm planning on gifting the client to the spice project, if you
> would be interested in! (given that you already have a JS project)
>
>
> Thanks in advance!
>
>
> Néfix Estrada
>
>


Re: [Spice-devel] 回复: How does SPICE display the desktop data processed by Nvidia vGPU?

2023-07-17 Thread Uri Lublin
Hello,

On Mon, Jul 17, 2023 at 1:10 PM 人宗道首 <928003...@qq.com> wrote:

> Hello,
> The attachment shows the effect of installing spice-streaming-agent on the
> spice official website. There are two screens, one displaying normal and
> the other displaying black.
> (1)Should the black screen be caused by spice-streaming-agent? What is the
> reason for the black screen? Is there a solution?
>

Are both screens enabled by the OS ?


>
> (2)Is there a way to only display the desktop generated by spice streaming
> agent and run it normally like a remote desktop, allowing for keyboard and
> mouse interaction?
>

Perhaps you can configure your OS to only enable the NVIDIA card.

Uri


>
> I hope you can help me, thank you!
>
>
> -- 原始邮件 --
> *发件人:* "Frediano Ziglio";
> *发送时间:* 2023年7月12日(星期三) 晚上7:26
> *收件人:* "人宗道首"<928003...@qq.com>;
> *抄送:* "spice-devel";
> *主题:* Re: [Spice-devel] How does SPICE display the desktop data processed
> by Nvidia vGPU?
>
> Il giorno mer 12 lug 2023 alle ore 09:37 人宗道首 <928003...@qq.com> ha
> scritto:
> >
> > Hello,
> > The link you provided is also available on the official website, and I
> have also found it. However, there are few comments and it is still
> difficult to understand. Is there any technical manual or document other
> than those provided on the official website that can help me make coding
> modifications to SPICE?
> >
>
> Not much updated but you can find some base overall at
> https://www.spice-space.org/developers.html, probably you have already
> seen them.
>
> Frediano


Re: [Spice-devel] In spicy, how to change shft-F12 to ungrab the mouse ?

2023-01-04 Thread Uri Lublin
Hi Pierre,

On Tue, Jan 3, 2023 at 8:30 PM Pierre Couderc  wrote:

>
> Le 1/3/23 à 14:38, Uri Lublin a écrit :
>
> Hi,
>
> Happy new year everybody.
>
> On Wed, Dec 28, 2022 at 11:11 AM Pierre Couderc  wrote:
>
>> Is is possible ? how ?
>>
>
> You can try adding the following to spicy configuration file
> (e.g. in $HOME/.config/spicy/settings on my Fedora), under [general]:
> grab-sequence=Alt_L+Control_L
>
> Hope that helps,
> Uri.
>
> Thnk you, it helps very much...
>
> It works. But I amsurprised that if I try to change Alt_L+Control_L for
> exmple Alt_G+Control_G it does not work...
>
> Aniway, Alt_L+Control_L is enogh for my needs...
>

Alt_L is the left Alt key and Alt_R is the right one.
If you want you can try with Alt_L+Control_L+g or even just ALT_L+g

I agree with Victor, spicy is a testing tool.

Cheers,
Uri.


Re: [Spice-devel] In spicy, how to change shft-F12 to ungrab the mouse ?

2023-01-03 Thread Uri Lublin
Hi,

Happy new year everybody.

On Wed, Dec 28, 2022 at 11:11 AM Pierre Couderc  wrote:

> Is is possible ? how ?
>

You can try adding the following to spicy configuration file
(e.g. in $HOME/.config/spicy/settings on my Fedora), under [general]:
grab-sequence=Alt_L+Control_L

Hope that helps,
Uri.


> Thanks for any help.
>
> PC
>
>


Re: [Spice-devel] Trying to turn on gstreamer vaapi {en,de}coding

2022-11-28 Thread Uri Lublin
Hi,

On Sun, Nov 27, 2022 at 4:04 PM Victor Toso  wrote:

> Hi,
> On Fri, Nov 25, 2022 at 12:32:57PM +, Lévai, Dániel wrote:
> > Hi all!
> >
> > First time here, and was a bit hesitant to post tbh, as this is
> > not a "-devel" sort of thing, but reading through the posts
> > here it seamed there have been some technical questions
> > already, so I'm trying my luck. The post is a bit longwinded,
> > it has a bunch of debug outputs and parameters in-line, please
> > let me know if you prefer sharing these in another way.
>
> It is fine to post it here.
>
> > I'm using a couple of VMs with libvirt/qemu hosted on an Ubuntu
> > 22.04.1 LTS, accessing them via Spice from an Arch system. The
> > connection between Hypevisor and client are via Internet, so
> > despite 'localhost' being the host in the tests/examples below,
> > they don't actually run on the same system, it's just a tunnel
> > via `stunnel`.
>
> > What I wanted to do is speed up the display (drawing) so it
> > won't lag that much when browsing through spreadsheets and
> > using console (with small fonts, admittedly). The resolution
> > also plays a role in this at 2560x1440 (only one spice
> > display).
>
> Note that host video encoding will lag a bit. This is what you
> are trying. It should be better with spice-streaming-agent by
> setting up a video card to the guest, an example:
>
>
> https://www.spice-space.org/demos.html#accelerated-spice-streaming-with-intel


>
> > What I've tried already is changing the spice section in the domain
> configuration in libvirt:
> > 
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> > 
>
> > Which translates into this -spice qemu parameter:
> > -spice
> port=5912,addr=127.0.0.1,disable-ticketing=on,image-compression=auto_glz,jpeg-wan-compression=never,zlib-glz-wan-compression=never,streaming-video=all,seamless-migration=on
>
> > ... with the complete command as follows:
> > /usr/bin/qemu-system-x86_64 -name guest=arch,debug-threads=on -S -object
> {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-22-arch/master-key.aes"}
> -machine
> pc-q35-4.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram
> -accel kvm -cpu
> Cooperlake,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,sha-ni=on,umip=on,waitpkg=on,gfni=on,vaes=on,vpclmulqdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,md-clear=on,avx-vnni=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,hle=off,rtm=off,avx512f=off,avx512dq=off,avx512cd=off,avx512bw=off,avx512vl=off,avx512vnni=off,avx512-bf16=off,taa-no=off
> -m 16384 -object
> {"qom-type":"memory-backend-ram","id":"pc.ram","size":17179869184}
> -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -no-user-config
> -nodefaults -chardev socket,id=charmonitor,fd=38,server=on,wait=off -mon
> chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew
> -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global
> ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device
> pcie-root-port,port=16,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
> -device pcie-root-port,port=17,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1
> -device pcie-root-port,port=18,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2
> -device pcie-root-port,port=19,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3
> -device pcie-root-port,port=20,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4
> -device pcie-root-port,port=21,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5
> -device pcie-root-port,port=22,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6
> -device pcie-root-port,port=23,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7
> -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device
> virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -blockdev
> {"driver":"file","filename":"/var/lib/libvirt/images/archlinux.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}
> -blockdev
> {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}
> -device
> virtio-blk-pci,bus=pci.4,addr=0x0,drive=libvirt-2-format,id=virtio-disk0,bootindex=1
> -device ide-cd,bus=ide.0,id=sata0-0-0 -netdev
> tap,fd=39,id=hostnet0,vhost=on,vhostfd=41 -device
> virtio-net-pci,netdev=hostnet0,id=net0,bus=pci.1,addr=0x0 -chardev
> pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0
> -chardev socket,id=charchannel0,fd=35,server=on,wait=off -device
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
> -chardev spicevmc,id=charchannel1,name=vdagent -device
> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0
> -device usb-tablet,id=input0,bus=usb.0,port=1 -device
> virtio-keyboard-pci,id=input2,bus=pci.7,addr=0x0 -device
> usb-mouse,id=input3,bus=usb.0,port=4 -audiodev
> {"id":"audio1","driver":"spice"} -spice
> 

Re: [Spice-devel] Vdagent not working on a Debian guest

2022-10-27 Thread Uri Lublin
On Thu, Oct 27, 2022 at 5:52 PM Carlos González 
wrote:

> Something by chance?
>
>
> El mar, 25 oct 2022 a las 18:16, Carlos González ()
> escribió:
>
>> Already did; it did work, thanks (and yes, it's always Virtual-1 for some
>> reason).
>> I couldn't understand it very well from the bug report, why isn't it
>> automatically working on some DEs/WMs?
>>
>
The QXL driver notifies the DE/WM about the new resolution.
Many DEs/WMs do not listen for such a notification.


>> Now, could we focus on the nasty bug with file transferring? As already
>> mentioned, the -f and -o options are serving of absolutely nothing...
>>
>
Does it help if you run spice-vdagent -xd -f $HOME ?
Did you try other directories with -f ?

Uri.



>> Thanks.
>>
>> El lun, 24 oct 2022 a las 9:16, Uri Lublin () escribió:
>>
>>> On Thu, Oct 20, 2022 at 11:52 PM Carlos González 
>>> wrote:
>>>
>>>> So I did more tests.
>>>>
>>>> First, AntiX Linux by default doesn't use "desktop environments" but
>>>> "window managers", being the default IceWM. Also, it doesn't use SystemD at
>>>> all; SysV instead. Regarding Xorg or Wayland, it's Xorg.
>>>>
>>>> > I did some tests and with both Windows and Linux it appears that the
>>>> > agent is needed.
>>>>
>>>> Well, of course it's needed! That's per basic instructions...
>>>>
>>>> Since there's no SystemD here, neither journalctl command. So tried
>>>> running both spice-vdagentd and spice-vdagent with debugging:
>>>> sudo /usr/sbin/spice-vdagentd -x -d -d
>>>> spice-vdagent -f /path/to/folder -x -d -d
>>>>
>>>> When resizing the remote-viewer window, no logs whatsoever, and of
>>>> course neither resolution update. Also, using the -f option served of
>>>> nothing; exact same error mentioned before...
>>>> Neither anything at all related in /var/log/Xorg.0.log
>>>> *Only* clipboard sharing seems to work
>>>>
>>>
>>> Try the workaround mentioned on the bug, run on the guest (after
>>> resizing remote-viewer's window):
>>> xrandr | grep Virtual  # look for the connected one
>>> xrandr --output Virtual-0 --auto # may be Virtual-1 instead of
>>> Virtual-0
>>>
>>> Uri.
>>>
>>>
>>>> By chance, do you think you could give the live ISO a try? It's a live
>>>> system, and the "Base" version is a CD size, not even a DVD...
>>>>
>>>> Thanks again for your attention.
>>>>
>>>> El mié, 19 oct 2022 a las 15:00, Uri Lublin ()
>>>> escribió:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, Oct 18, 2022 at 8:40 PM Frediano Ziglio 
>>>>> wrote:
>>>>>
>>>>>> Il giorno mar 18 ott 2022 alle ore 01:04 Carlos González
>>>>>>  ha scritto:
>>>>>> >
>>>>>> > Were you able to find something by chance? Thanks.
>>>>>> >
>>>>>>
>>>>>> Hi Carlos,
>>>>>>my main curiosity was about the need of the agent for resize.
>>>>>> I did some tests and with both Windows and Linux it appears that the
>>>>>> agent is needed.
>>>>>> At this point I would try looking at the agent logs.
>>>>>> Is your system using Xorg or Wayland ?
>>>>>>
>>>>>> Regards,
>>>>>>Frediano
>>>>>>
>>>>>>
>>>>> I agree with Frediano that (with a recent QXL device) the arbitrary
>>>>> resolution update is done via QXL.
>>>>> Note that it does not work for all Desktop Environments, and I
>>>>> apparently it doesn't work for AntiX Linux (default DE).
>>>>> If you can, try to run with GNOME/X11 and see if that works.
>>>>>
>>>>> Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1290586
>>>>>
>>>>> Regards,
>>>>> Uri.
>>>>>
>>>>>
>>>>> > El sáb, 15 oct 2022 a las 9:22, Frediano Ziglio ()
>>>>>> escribió:
>>>>>> >>
>>>>>> >> Il giorno ven 14 ott 2022 alle ore 16:11 Carlos González
>>>>>> >>  ha scritto:
>>>>>> >> >
>>>>>> >>

Re: [Spice-devel] Vdagent not working on a Debian guest

2022-10-24 Thread Uri Lublin
On Thu, Oct 20, 2022 at 11:52 PM Carlos González 
wrote:

> So I did more tests.
>
> First, AntiX Linux by default doesn't use "desktop environments" but
> "window managers", being the default IceWM. Also, it doesn't use SystemD at
> all; SysV instead. Regarding Xorg or Wayland, it's Xorg.
>
> > I did some tests and with both Windows and Linux it appears that the
> > agent is needed.
>
> Well, of course it's needed! That's per basic instructions...
>
> Since there's no SystemD here, neither journalctl command. So tried
> running both spice-vdagentd and spice-vdagent with debugging:
> sudo /usr/sbin/spice-vdagentd -x -d -d
> spice-vdagent -f /path/to/folder -x -d -d
>
> When resizing the remote-viewer window, no logs whatsoever, and of course
> neither resolution update. Also, using the -f option served of nothing;
> exact same error mentioned before...
> Neither anything at all related in /var/log/Xorg.0.log
> *Only* clipboard sharing seems to work
>

Try the workaround mentioned on the bug, run on the guest (after resizing
remote-viewer's window):
xrandr | grep Virtual  # look for the connected one
xrandr --output Virtual-0 --auto # may be Virtual-1 instead of Virtual-0

Uri.


> By chance, do you think you could give the live ISO a try? It's a live
> system, and the "Base" version is a CD size, not even a DVD...
>
> Thanks again for your attention.
>
> El mié, 19 oct 2022 a las 15:00, Uri Lublin () escribió:
>
>> Hi,
>>
>> On Tue, Oct 18, 2022 at 8:40 PM Frediano Ziglio 
>> wrote:
>>
>>> Il giorno mar 18 ott 2022 alle ore 01:04 Carlos González
>>>  ha scritto:
>>> >
>>> > Were you able to find something by chance? Thanks.
>>> >
>>>
>>> Hi Carlos,
>>>my main curiosity was about the need of the agent for resize.
>>> I did some tests and with both Windows and Linux it appears that the
>>> agent is needed.
>>> At this point I would try looking at the agent logs.
>>> Is your system using Xorg or Wayland ?
>>>
>>> Regards,
>>>Frediano
>>>
>>>
>> I agree with Frediano that (with a recent QXL device) the arbitrary
>> resolution update is done via QXL.
>> Note that it does not work for all Desktop Environments, and I apparently
>> it doesn't work for AntiX Linux (default DE).
>> If you can, try to run with GNOME/X11 and see if that works.
>>
>> Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1290586
>>
>> Regards,
>> Uri.
>>
>>
>> > El sáb, 15 oct 2022 a las 9:22, Frediano Ziglio ()
>>> escribió:
>>> >>
>>> >> Il giorno ven 14 ott 2022 alle ore 16:11 Carlos González
>>> >>  ha scritto:
>>> >> >
>>> >> > As soon as spice-vdagent package is installed, so is the
>>> spice-vdagentd daemon and it also starts running. Yet I always need to
>>> manually run spice-vdagent command...
>>> >> >
>>> >>
>>> >> Maybe you would need to logout and login again from the graphic
>>> >> session. Or manually start it, not sure.
>>> >>
>>> >> > How do I specify an output directory for the agent to file transfer?
>>> >> >
>>> >>
>>> >> See "spice-vdagent --help", specifically -f and -o options.
>>> >>
>>> >> > I don't think it's remote-viewer's fault, because I also tested
>>> with a Windows guest. With all SPICE stuff properly installed, everything
>>> works out of the box: clipboard, resizing, file transfer from host to
>>> guest. With "properly installed" I mean: installed SPICE drivers manually
>>> from virtio-win ISO by loading them since the Windows installation
>>> beforehand, then once booted into Windows downloaded the vdagent ZIP from
>>> spice-space website and manually installed the service according to
>>> instructions.
>>> >> >
>>> >>
>>> >> I'll check, maybe is not handled by driver but agent
>>> >>
>>> >> > As additional detail, in QEMU I use the option "-display
>>> spice-app", which automatically starts remote-viewer; though curiously it
>>> doesn't seem to create a virt-viewer directory inside ~/.config unlike when
>>> running remote-viewer manually...
>>> >> >
>>> >> > Thanks again.
>>> >> >
>>> >> > El vie, 14 oct 2022 a las 12:41, Fre

Re: [Spice-devel] Vdagent not working on a Debian guest

2022-10-19 Thread Uri Lublin
Hi,

On Tue, Oct 18, 2022 at 8:40 PM Frediano Ziglio  wrote:

> Il giorno mar 18 ott 2022 alle ore 01:04 Carlos González
>  ha scritto:
> >
> > Were you able to find something by chance? Thanks.
> >
>
> Hi Carlos,
>my main curiosity was about the need of the agent for resize.
> I did some tests and with both Windows and Linux it appears that the
> agent is needed.
> At this point I would try looking at the agent logs.
> Is your system using Xorg or Wayland ?
>
> Regards,
>Frediano
>
>
I agree with Frediano that (with a recent QXL device) the arbitrary
resolution update is done via QXL.
Note that it does not work for all Desktop Environments, and I apparently
it doesn't work for AntiX Linux (default DE).
If you can, try to run with GNOME/X11 and see if that works.

Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1290586

Regards,
Uri.


> El sáb, 15 oct 2022 a las 9:22, Frediano Ziglio ()
> escribió:
> >>
> >> Il giorno ven 14 ott 2022 alle ore 16:11 Carlos González
> >>  ha scritto:
> >> >
> >> > As soon as spice-vdagent package is installed, so is the
> spice-vdagentd daemon and it also starts running. Yet I always need to
> manually run spice-vdagent command...
> >> >
> >>
> >> Maybe you would need to logout and login again from the graphic
> >> session. Or manually start it, not sure.
> >>
> >> > How do I specify an output directory for the agent to file transfer?
> >> >
> >>
> >> See "spice-vdagent --help", specifically -f and -o options.
> >>
> >> > I don't think it's remote-viewer's fault, because I also tested with
> a Windows guest. With all SPICE stuff properly installed, everything works
> out of the box: clipboard, resizing, file transfer from host to guest. With
> "properly installed" I mean: installed SPICE drivers manually from
> virtio-win ISO by loading them since the Windows installation beforehand,
> then once booted into Windows downloaded the vdagent ZIP from spice-space
> website and manually installed the service according to instructions.
> >> >
> >>
> >> I'll check, maybe is not handled by driver but agent
> >>
> >> > As additional detail, in QEMU I use the option "-display spice-app",
> which automatically starts remote-viewer; though curiously it doesn't seem
> to create a virt-viewer directory inside ~/.config unlike when running
> remote-viewer manually...
> >> >
> >> > Thanks again.
> >> >
> >> > El vie, 14 oct 2022 a las 12:41, Frediano Ziglio ()
> escribió:
> >> >>
> >> >> Il giorno gio 13 ott 2022 alle ore 16:58 Carlos González
> >> >>  ha scritto:
> >> >> >
> >> >> > Hello.
> >> >> >
> >> >> > I'm trying a virtual machine with a live CD distribution called
> AntiX Linux, which is directly based on Debian.
> >> >> >
> >> >> > I'm using direct QEMU commands.
> >> >> > In the VM configuration I have this for SPICE configuration:
> >> >> > "-vga qxl -device virtio-serial-pci -spice
> unix=on,addr=path/to/vm_spice.socket,disable-ticketing=on -chardev
> spicevmc,id=spicechannel0,name=vdagent -device
> virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \"
> >> >> > Then I boot the live ISO, double check that QXL driver is
> installed -which normally always is-, and install spice-vdagent package
> (version 20 here). I'm using remote-viewer (virt-viewer) to visualize the
> VM.
> >> >> >
> >> >> > Up to this point, clipboard sharing with host still doesn't work,
> and trying to drag a file from host to guest results in an error "The agent
> is not connected".
> >> >> >
> >> >>
> >> >> This error is normal if the agent is stopped.
> >> >>
> >> >> > So I manually run "spice-vdagent" command, and clipboard sharing
> now works, but trying to drag file from host to guest gives "File transfer
> is disabled". Also, automatic resolution change with window resizing
> doesn't work either.
> >> >> >
> >> >>
> >> >> The fact that in this way the clipboard is running indicates that the
> >> >> agent is now working. You need to specify an output directory to the
> >> >> agent in order to get file transfer working.
> >> >> About the resolution change that's weird, I think that feature on
> >> >> Linux does not even require the agent running. Is it possible that
> the
> >> >> client (remove-viewer) is not set up to send resize to the guest
> >> >> automatically, there are some options on the menu.
> >> >>
> >> >> > Certainly, this live distro doesn't come with any spice-related
> packages installed by default, except for the QXL package.
> >> >> >
> >> >> > Am I missing something here? Could someone help please?
> >> >> > Thanks beforehand.
> >> >>
> >> >> Frediano
>
>


Re: [Spice-devel] Issues with Clipboard Grab/Release Callbacks

2022-06-21 Thread Uri Lublin
Hi,

On Mon, Jun 20, 2022 at 10:00 PM Nick Couchman  wrote:

> On Mon, Jun 20, 2022 at 2:46 PM Marc-André Lureau <
> marcandre.lur...@gmail.com> wrote:
>
>> Hi
>>
>> On Mon, Jun 20, 2022 at 6:09 PM Nick Couchman  wrote:
>>
>>> Hello, everyone,
>>> I've posted here, before, with some questions during my journey of
>>> trying to add support for the SPICE protocol to the Guacamole project. The
>>> good news is that I've actually made measurable progress in the
>>> implementation - I can now connect to a SPICE server, and the basics work
>>> (mouse and keyboard - mostly anyway), so I'm moving on to the extra stuff -
>>> clipboard, audio, file transfer, etc.
>>>
>>> In working on the clipboard integration, I'm currently running into an
>>> issue with a couple of the callback functions, specifically the clipboard
>>> grab/release functions, where the number of arguments seems to be
>>> mismatched. According to the documentation, these callbacks should be
>>> called with the following arguments:
>>>
>>> gboolean
>>> user_function (SpiceMainChannel *main,
>>>guint selection,
>>>gpointer  types,
>>>guint ntypes,
>>>gpointer  user_data)
>>>
>>>
>> types is actually guint32*, but that's not the problem here.
>>
>
> Okay, I'll update that.
>
>
>>
>>
>>> void
>>> user_function (SpiceMainChannel *main,
>>>guint selection,
>>>gpointer  user_data)
>>>
>>> I've implemented the callbacks with those arguments, as follows:
>>>
>>> void guac_spice_clipboard_selection_grab_handler(SpiceMainChannel
>>> channel,
>>> guint selection, gpointer types, guint ntypes, guac_client*
>>> client)
>>>
>>> void guac_spice_clipboard_selection_release_handler(SpiceMainChannel
>>> channel,
>>> guint selection, guac_client* client)
>>>
>>
>> It looks correct. Can you point to your code connecting the signals with
>> the handlers?
>>
>
> Sure - source code is here:
> https://github.com/necouchman/guacamole-server/tree/working/spice-basic
>
> Here's the section in the src/protocol/spice/client.c file that registers
> the callbacks:
>
> /* Register clipboard handlers. */
> g_signal_connect(channel, SPICE_SIGNAL_MAIN_CLIPBOARD_SELECTION,
> G_CALLBACK(guac_spice_clipboard_selection_handler),
> client);
> g_signal_connect(channel,
> SPICE_SIGNAL_MAIN_CLIPBOARD_SELECTION_GRAB,
> G_CALLBACK(guac_spice_clipboard_selection_grab_handler),
> client);
> g_signal_connect(channel,
> SPICE_SIGNAL_MAIN_CLIPBOARD_SELECTION_RELEASE,
>
> G_CALLBACK(guac_spice_clipboard_selection_release_handler), client);
> g_signal_connect(channel,
> SPICE_SIGNAL_MAIN_CLIPBOARD_SELECTION_REQUEST,
>
> G_CALLBACK(guac_spice_clipboard_selection_request_handler), client);
>
> link to the full function is here:
>
> https://github.com/necouchman/guacamole-server/blob/5e073802a0656e65b1bc8e7e6051831bea0d9508/src/protocols/spice/client.c#L236-L375
>

Try changing the callbacks to accept a pointer, e.g.:
- void guac_spice_clipboard_selection_grab_handler(SpiceMainChannel channel,
+void guac_spice_clipboard_selection_grab_handler(SpiceMainChannel* channel,

 Regards,
Uri.


>
>>
>> and registered them appropriately. However, if I use them as implemented
>> above, when the callbacks are triggered, the application segfaults when I
>> try to access the "guac_client* client" data structure. I used GDB to try
>> to help track this down, and I noticed that the value of "client" was 0x1,
>> which looks less like a pointer to a memory location and more like the
>> number 1.
>>
>> So, I decided to add another argument to the callback functions, just
>> before the client argument:
>>
>> void guac_spice_clipboard_selection_grab_handler(SpiceMainChannel channel,
>> guint selection, gpointer types, guint ntypes, guint extra,
>> guac_client* client)
>>
>> void guac_spice_clipboard_selection_release_handler(SpiceMainChannel
>> channel,
>> guint selection, guint extra, guac_client* client)
>>
>> Strangely, this works - the client data structure can be referenced,
>> there are no segfaults (yet), etc. So, I decided to print the values that
>> are being passed for all of these parameters, and I get the following:
>>
>> guacd[100252]: DEBUG: Notifying client of clipboard grab in the guest.
>> guacd[100252]: DEBUG: Arg: channel: 0x
>> guacd[100252]: DEBUG: Arg: selection: 1275303536
>> guacd[100252]: DEBUG: Arg: types: 0x0001
>> guacd[100252]: DEBUG: Arg: ntypes: 1276022924
>> guacd[100252]: DEBUG: Arg: extra: 1
>>
>>
> Weird
>
>
>> I printed them in the format I thought they should be in based on what
>> the arguments are supposed to be - I probably should have just done all
>> hex. But, it seems like maybe the "extra" parameter being passed is in
>> front of the channel, since the channel is showing up as all zeros?
>>
>> I was trying 

Re: [Spice-devel] centos+kvm+nvidia vgpu+win10(guest) spice remote 4K bad perform.

2022-05-29 Thread Uri Lublin
Hi Leo,

For a guest that has NVIDIA (or Intel/other) vgpu as an mdev device (direct
access to NVIDIA hardware), all guest graphics commands are done on the
NVIDIA device.
In this case, one can run spice-streaming-agent, on the guest, and use
NVIDIA to encode (e.g. using the gstreamer or other plugin) a video stream
(assuming an NVIDIA/other hardware encoder is installed on the guest too).
The spice-streaming-agent sends the video stream to spice-server via a
virtio-serial device. The spice-server needs not re-encode the stream, but
just sends it as is to the client that (decodes it and) displays it to the
user.

Hope that helps,
Uri.


On Sat, May 28, 2022 at 3:05 PM 张伟华 <15529316...@163.com> wrote:

>
> Hi Uri:
> Thanks for your last email and we did some experiment, here are some
> questions remain:
> Whether only use the QXL device as the display device can activate the
> video streaming encode, which treats the video as stream data and encodes
> by MJPEG or other GStreamer supported encoding methods.
> We have above problems is because when a Nvidia vgpu is set as the mdev
> device(the default value “qxl” of the virtual machine is replaced with
> “none”, using the “-vga none” command), we find in logs that spice uses
> image compression instead of the spice video streaming to encode the whole
> display data(include the video window).
> Does spice support a vgpu mdev device to accelerate the rendering and
> using the spice video streaming encode to compress a video at the meantime.
>
>
> pls help us with that
> thanks a lot
> best wishes
> leo zhang
>
>
>
> At 2022-05-27 03:28:20, "Uri Lublin"  wrote:
>
> Hi Leo,
>
> On Thu, May 26, 2022 at 4:28 PM 张伟华 <15529316...@163.com> wrote:
>
>>
>> Hi Uri:
>> Thanks for your advise of our project.We have try it and here is
>> something we find:
>> 1.we have deploy the spice-streaming-agent in the client and set H254 in
>> libvert xml , applice report error and don't work.
>> but vp8/vp9 works.
>>
>
> Note that spice-streaming-agent needs to run on the guest.
>
>
>
>> 2.When we use Nvidia vgpu as a mdev device attach to the virtual mathine, *we
>> find in logs that spice use picture compress (glz) instead of vedio
>> compress h254.*
>> So we have two question to ask:
>> 1.what we need to do in libvert xml to have a better vedio quality witH
>> NVIDIA VGPU attach as a mdev divice?
>>
>
> This is not done in libvirt domxml, but needs to be configured on the
> guest.
> (of course you need to have org.spice-space.stream.0 via libvirt)
>
> Make sure that the guest's gstreamer1 "knows" the codec.
> It works much better when the encoder uses the hardware to encode.
>
> gst-inspect-1.0 | grep 264  | grep -i enc
> gst-inspect-1.0 | grep -i vp  | grep -i enc
>
>
>> 2.We didn't find spice-streaming-agent for windows in Spice office site.
>> Does spice-streaming-agent only support linux and only have linux version?
>>
>
> Yes, currently there is only a linux version.
>
> Regards,
> Uri.
>
> ps: One single display  and 4k video is required as one of the main goals
>> in our project.
>> Pls help us with those questions.
>> Best wishes !
>> leo zhang
>>
>>
>>
>>
>>
>> At 2022-05-20 04:38:55, "Uri Lublin"  wrote:
>>
>> Hi Leo,
>>
>> On Thu, May 19, 2022 at 1:43 PM 张伟华 <15529316...@163.com> wrote:
>>
>>> Hi :
>>> I am a phd student of Xian Jiaotong university in China.
>>> We have a project to accomplish a remote-desk solution with Nvidia vgpu.
>>> We use spice latest version  and have a bad 4K display quality.
>>> Our environment is like:
>>> 1.T4 card with inspure server in nvidia support list
>>>
>> NVIDIA Tesla T4  GPU card
>>
>> 2.redhat 8.2 enterprise  with kvm qemu
>>>
>>
>>
>>> 3.vgpu software package is 13.x
>>>
>> NVIDIA driver + tools (GRID)
>>
>>
>>> 4.vw flavor is 8u 16G. with 40 storage.   vgpu license is vpc ,and vgpu
>>> is B-2b.
>>>
>> "vw" == Virtual Workstation
>> B-2b is the vGPU type? meaning T4-2B ?
>> Does it help if you configure it with T4-2Q (may require a different
>> license)?
>>
>> Only a single Display, right ?
>>
>> Are you running spice-streaming-agent on the guest ?
>> Try to stream with H264, if you do not already do it
>> (may require paying fees for using H264).
>>
>> Is 4k resolution a requirement? If not, try with e.g. 2k.
>>
>> Hope that helps,
>> Uri
>>
>>
>>
>>> And our issue is attached in appendix.
>>> Please give us some help to solve this.
>>>
>>> best wishs;
>>> leo zhang
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>


Re: [Spice-devel] centos+kvm+nvidia vgpu+win10(guest) spice remote 4K bad perform.

2022-05-26 Thread Uri Lublin
Hi Leo,

On Thu, May 26, 2022 at 4:28 PM 张伟华 <15529316...@163.com> wrote:

>
> Hi Uri:
> Thanks for your advise of our project.We have try it and here is something
> we find:
> 1.we have deploy the spice-streaming-agent in the client and set H254 in
> libvert xml , applice report error and don't work.
> but vp8/vp9 works.
>

Note that spice-streaming-agent needs to run on the guest.



> 2.When we use Nvidia vgpu as a mdev device attach to the virtual mathine, *we
> find in logs that spice use picture compress (glz) instead of vedio
> compress h254.*
> So we have two question to ask:
> 1.what we need to do in libvert xml to have a better vedio quality witH
> NVIDIA VGPU attach as a mdev divice?
>

This is not done in libvirt domxml, but needs to be configured on the guest.
(of course you need to have org.spice-space.stream.0 via libvirt)

Make sure that the guest's gstreamer1 "knows" the codec.
It works much better when the encoder uses the hardware to encode.

gst-inspect-1.0 | grep 264  | grep -i enc
gst-inspect-1.0 | grep -i vp  | grep -i enc


> 2.We didn't find spice-streaming-agent for windows in Spice office site.
> Does spice-streaming-agent only support linux and only have linux version?
>

Yes, currently there is only a linux version.

Regards,
Uri.

ps: One single display  and 4k video is required as one of the main goals
> in our project.
> Pls help us with those questions.
> Best wishes !
> leo zhang
>
>
>
>
>
> At 2022-05-20 04:38:55, "Uri Lublin"  wrote:
>
> Hi Leo,
>
> On Thu, May 19, 2022 at 1:43 PM 张伟华 <15529316...@163.com> wrote:
>
>> Hi :
>> I am a phd student of Xian Jiaotong university in China.
>> We have a project to accomplish a remote-desk solution with Nvidia vgpu.
>> We use spice latest version  and have a bad 4K display quality.
>> Our environment is like:
>> 1.T4 card with inspure server in nvidia support list
>>
> NVIDIA Tesla T4  GPU card
>
> 2.redhat 8.2 enterprise  with kvm qemu
>>
>
>
>> 3.vgpu software package is 13.x
>>
> NVIDIA driver + tools (GRID)
>
>
>> 4.vw flavor is 8u 16G. with 40 storage.   vgpu license is vpc ,and vgpu
>> is B-2b.
>>
> "vw" == Virtual Workstation
> B-2b is the vGPU type? meaning T4-2B ?
> Does it help if you configure it with T4-2Q (may require a different
> license)?
>
> Only a single Display, right ?
>
> Are you running spice-streaming-agent on the guest ?
> Try to stream with H264, if you do not already do it
> (may require paying fees for using H264).
>
> Is 4k resolution a requirement? If not, try with e.g. 2k.
>
> Hope that helps,
> Uri
>
>
>
>> And our issue is attached in appendix.
>> Please give us some help to solve this.
>>
>> best wishs;
>> leo zhang
>>
>>
>>
>>
>>
>
>
>
>
>


Re: [Spice-devel] centos+kvm+nvidia vgpu+win10(guest) spice remote 4K bad perform.

2022-05-19 Thread Uri Lublin
Hi Leo,

On Thu, May 19, 2022 at 1:43 PM 张伟华 <15529316...@163.com> wrote:

> Hi :
> I am a phd student of Xian Jiaotong university in China.
> We have a project to accomplish a remote-desk solution with Nvidia vgpu.
> We use spice latest version  and have a bad 4K display quality.
> Our environment is like:
> 1.T4 card with inspure server in nvidia support list
>
NVIDIA Tesla T4  GPU card

2.redhat 8.2 enterprise  with kvm qemu
>


> 3.vgpu software package is 13.x
>
NVIDIA driver + tools (GRID)


> 4.vw flavor is 8u 16G. with 40 storage.   vgpu license is vpc ,and vgpu is
> B-2b.
>
"vw" == Virtual Workstation
B-2b is the vGPU type? meaning T4-2B ?
Does it help if you configure it with T4-2Q (may require a different
license)?

Only a single Display, right ?

Are you running spice-streaming-agent on the guest ?
Try to stream with H264, if you do not already do it
(may require paying fees for using H264).

Is 4k resolution a requirement? If not, try with e.g. 2k.

Hope that helps,
Uri



> And our issue is attached in appendix.
> Please give us some help to solve this.
>
> best wishs;
> leo zhang
>
>
>
>
>


Re: [Spice-devel] [USB redirection] position offset for touch-screen

2022-05-19 Thread Uri Lublin
Hi Walter,

On Wed, May 18, 2022 at 10:52 AM Walter Mitty 
wrote:

> GuestOS: Win10
> Host OS: Ubuntu 20.04
> Client OS: Ubuntu 20.04
>
> I enabled usb redirection on a touch screen. The position VM actually
> rendered has offset from the touching point on screen. I wanna fix it. But
> I don't know where to start. Could anyone give me some advice please?
>

Things to try:
1. Make sure your guest resolution is the same as expected/supported
by the touch-screen device
2. Does it work on the Ubuntu client (before being redirected to the guest)
?
Does it work with a Ubuntu guest ?
Does it work with a physical Windows 10  ?

Hope that helps,
Uri.


Re: [Spice-devel] SPICE support

2022-03-22 Thread Uri Lublin
Hi Michael,

On Sat, Mar 19, 2022 at 11:26 AM Michael Toulson 
wrote:

> Hello Spice team
>
> I been trying to work out what I’m missing
> I have Spice running fine for some time on my main windows pc
> after some time it start having problem
> I did a clean install of windows 10
> I have been trying to trouble shot this for the pass week
> as I have backup and restored backup
> I run a windows 10 VM within Proxmox witch is fine
> but when I try and open the console it download a file when it should of
> had a pop up to open console
>

It seems you are missing a vv-file mime type binding (and possibly
virt-viewer itself).
On what OS does your remote-viewer run (aka, the client machine)?
Try to re/install virt-viewer (uninstall if it's already installed).

Also, you can try the following and see if it works:
- Download the vv file
- Run remote-viewer 

Hope that helps,
Uri.


> could you help me as well show me what I should be downloading to get this
> running i’m so lost at this point on my knows that I did get it running
> last time I had the following
>
>
>
>
> please help me I tried the IRC with is new for me I have no idea what I
> was doing i’m also on Discord @ EQUALITY_CG#2842
> I really enjoy SPICE when it was working because of the speed was so fast
> then VNC but not sure what to do now as I installed the win x86 as well and
> did not work on the clean install of windows
>
>
>
>
>
> Sent from Mail  for
> Windows
>
>
>


Re: [Spice-devel] usbredir doesn't hide/filter specific usb devices

2022-02-16 Thread Uri Lublin
On Tue, Feb 15, 2022 at 5:41 PM lizhij...@fujitsu.com 
wrote:

> > The auto-redirect-filter only works for auto-redirected USB devices.
>
> may i know what "auto-redirected usb devices" mean here.
> what's auto-redirect-filter user case.
>
>
USB devices that are being plugged in while the remote-viewer window is in
focus.
Such USB devices are auto-redirect'ed to the guest, but go through the
filter first.

Uri


>
> > When a user is choosing a device from the menu, the filter does not
> apply.
>
> any idea to hide specific host usb devices from guest by current scheme
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
>
> --
> *发件人:* Uri Lublin 
> *发送时间:* 2022年2月15日星期二 22:50
> *收件人:* Li, Zhijian/李 智坚
> *抄送:* spice-devel
> *主题:* Re: [Spice-devel] usbredir doesn't hide/filter specific usb devices
>
> Hi Zhijian,
>
> On Tue, Feb 15, 2022 at 3:52 PM Li, Zhijian 
> wrote:
>
>> Hi guys
>>
>> I intended to not allow redirecting some of my usb devices(HID) to the
>> guest, i thought https://www.spice-space.org/usbredir.html
>> could help on this.
>>
>> My host has below usb devices
>>
>> lizj@FNSTPC:~/workspace/vgt/virt-viewer/src$ lsusb
>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>> Bus 001 Device 006: ID 04d8:0b2a Microchip Technology, Inc.
>> Bus 001 Device 021: ID 046d:c534 Logitech, Inc. Unifying Receiver
>> Bus 001 Device 004: ID 0424:2137 Standard Microsystems Corp.
>> Bus 001 Device 003: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS
>> 802.11n WLAN Adapter
>> Bus 001 Device 002: ID 0bda:8771 Realtek Semiconductor Corp.
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>
>> $ remote-viewer
>> --spice-usbredir-auto-redirect-filter="-1,0x0bda,-1,-1,0" --spice-debug
>> spice://localhost:5900
>>
>
>> For testing, i just want to hide produce id 0x0bda from remote-viewer
>> with above command line. But acutally
>>
>> i am still able to redirec both Realtek device to the guest through
>> remote-viewer.
>>
>> So is there something with my usage ? Feel free to let me know if there
>> is something wrong.
>>
>
> The auto-redirect-filter only works for auto-redirected USB devices.
> When a user is choosing a device from the menu, the filter does not apply.
>
> Regards,
> Uri.T
>
>
>>
>> Thanks
>>
>> Zhijian
>>
>>
>>
>>
>


Re: [Spice-devel] usbredir doesn't hide/filter specific usb devices

2022-02-15 Thread Uri Lublin
Hi Zhijian,

On Tue, Feb 15, 2022 at 3:52 PM Li, Zhijian 
wrote:

> Hi guys
>
> I intended to not allow redirecting some of my usb devices(HID) to the
> guest, i thought https://www.spice-space.org/usbredir.html
> could help on this.
>
> My host has below usb devices
>
> lizj@FNSTPC:~/workspace/vgt/virt-viewer/src$ lsusb
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 006: ID 04d8:0b2a Microchip Technology, Inc.
> Bus 001 Device 021: ID 046d:c534 Logitech, Inc. Unifying Receiver
> Bus 001 Device 004: ID 0424:2137 Standard Microsystems Corp.
> Bus 001 Device 003: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS
> 802.11n WLAN Adapter
> Bus 001 Device 002: ID 0bda:8771 Realtek Semiconductor Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> $ remote-viewer
> --spice-usbredir-auto-redirect-filter="-1,0x0bda,-1,-1,0" --spice-debug
> spice://localhost:5900
>

> For testing, i just want to hide produce id 0x0bda from remote-viewer
> with above command line. But acutally
>
> i am still able to redirec both Realtek device to the guest through
> remote-viewer.
>
> So is there something with my usage ? Feel free to let me know if there
> is something wrong.
>

The auto-redirect-filter only works for auto-redirected USB devices.
When a user is choosing a device from the menu, the filter does not apply.

Regards,
Uri.


>
> Thanks
>
> Zhijian
>
>
>
>


Re: [Spice-devel] error: No free USB channel

2021-12-26 Thread Uri Lublin
Hi iordan,

On Sat, Dec 25, 2021 at 11:49 PM i iordanov  wrote:
>
> Hey Frediano,
>
> Thanks for responding - so I take it this is a server-side setting
> (how many channels are attached to the VM)?

Yes, the USB (usbredir) devices are defined in the VM configuration
(likely via a libvirt domxml file).
If you need more than 2 USB devices connected to the guest at the same
time, add more
such devices to your VM.

>
> Also, is there a spice-gtk API that may be used to obtain the number
> of available USB channels at any given time? I.e. the UI of any client
> application should have a way to inform the user how many "ports" are
> still available at any point, right?

Both remote-viewer (virt-viewer) and the spicy test tool use
spice-gtk's usb device widget
which has this information.

Alternatively, you can get "free-channels" from spice-gtk's usb device manager

Uri.

>
> Thanks!
> iordan
>
> On Fri, Dec 24, 2021 at 4:05 AM Frediano Ziglio  wrote:
> >
> > Il giorno gio 23 dic 2021 alle ore 23:38 i iordanov  
> > ha scritto:
> >>
> >> Hi guys,
> >>
> >> During my testing I've been unable to connect more than 2 USB devices
> >> at a time - could you please help me figure out why that's happening?
> >>
> >> The backend starts returning error with message "No free USB channel",
> >> but I can't see how to tune the number of USB channels available!
> >>
> >> 2021-12-23 15:27:52.608 29721-29760/com.iiordanov.aSPICE
> >> D/android-service: connect_cb: start
> >> 2021-12-23 15:27:52.608 29721-29760/com.iiordanov.aSPICE
> >> I/android-service: connect_cb: successfully redirected device
> >> 2021-12-23 15:28:00.499 29721-29760/com.iiordanov.aSPICE
> >> D/android-service: connect_cb: start
> >> 2021-12-23 15:28:00.499 29721-29760/com.iiordanov.aSPICE
> >> I/android-service: connect_cb: successfully redirected device
> >> 2021-12-23 15:28:03.582 29721-29760/com.iiordanov.aSPICE
> >> D/android-service: connect_cb: start
> >> 2021-12-23 15:28:03.582 29721-29760/com.iiordanov.aSPICE
> >> E/android-service: connect_cb: failed to redirect device, error: No
> >> free USB channel
> >> 2021-12-23 15:28:06.385 29721-29760/com.iiordanov.aSPICE
> >> D/android-service: connect_cb: start
> >> 2021-12-23 15:28:06.385 29721-29760/com.iiordanov.aSPICE
> >> E/android-service: connect_cb: failed to redirect device, error: No
> >> free USB channel
> >> 2021-12-23 15:28:08.634 29721-29760/com.iiordanov.aSPICE
> >> D/android-service: connect_cb: start
> >> 2021-12-23 15:28:08.634 29721-29760/com.iiordanov.aSPICE
> >> E/android-service: connect_cb: failed to redirect device, error: No
> >> free USB channel
> >>
> >> Your help is very appreciated.
> >>
> >> Thanks!
> >> iordan
> >>
> >
> > Hi,
> >   this is expected. Every USB channel allow to attach one USB device. Is 
> > like having 2 physical USB ports on your computer. If you don't use an HUB 
> > you can attach only 2 USB physical devices. Currently there's no software 
> > USB hub so one USB device takes one USB channel and by default only 2 USB 
> > channels are attached to the VM.
> >
> > Frediano
>
>
>
> --
> The conscious mind has only one thread of execution.
>



Re: [Spice-devel] attaching a USB device by libusb_device or libusb_device_handle on Android

2021-12-21 Thread Uri Lublin
rdanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2703 usbredir-9:1: Open coroutine starting
> 0x725fae4340
> 2021-12-21 02:13:59.963 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2540 usbredir-9:1: Started background coroutine
> 0x725fae41f8
> 2021-12-21 02:13:59.963 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-session.c:2265 usbredir-9:1: Using plain text, port 6001
> 2021-12-21 02:13:59.965 3011-3060/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-session.c:2196 open host MYHOST:6001
> 2021-12-21 02:13:59.965 3011-3060/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-session.c:2118 usbredir-9:0: connecting 0x709fb7aaf0...
> 2021-12-21 02:13:59.965 3011-3060/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-session.c:2196 open host MYHOST:6001
> 2021-12-21 02:13:59.966 3011-3060/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-session.c:2118 usbredir-9:1: connecting 0x709fa7caf0...
> 2021-12-21 02:13:59.992 3011-3060/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-session.c:2102 usbredir-9:0: connect ready
> 2021-12-21 02:13:59.992 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1372 usbredir-9:0: channel type 9 id 0 num
> common caps 1 num caps 1
> 2021-12-21 02:14:00.002 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1396 usbredir-9:0: Peer version: 2:2
> 2021-12-21 02:14:00.002 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1952 usbredir-9:0: spice_channel_recv_link_msg:
> 2 caps
> 2021-12-21 02:14:00.002 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1966 usbredir-9:0: got remote common caps:
> 2021-12-21 02:14:00.002 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1902 0:0xB
> 2021-12-21 02:14:00.002 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1973 usbredir-9:0: got remote channel caps:
> 2021-12-21 02:14:00.002 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1902 0:0x1
> 2021-12-21 02:14:00.002 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2921 test cap 0 in 0xB: yes
> 2021-12-21 02:14:00.002 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2921 test cap 1 in 0xB: yes
> 2021-12-21 02:14:00.003 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2921 test cap 3 in 0xB: yes
> 2021-12-21 02:14:00.003 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2005 usbredir-9:0: use mini header: 1
> 2021-12-21 02:14:00.003 3011-3060/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-session.c:2102 usbredir-9:1: connect ready
> 2021-12-21 02:14:00.003 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1372 usbredir-9:1: channel type 9 id 1 num
> common caps 1 num caps 1
> 2021-12-21 02:14:00.005 3011-3115/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1303 usbredir-9:0: channel up, state 3
> 2021-12-21 02:14:00.013 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1396 usbredir-9:1: Peer version: 2:2
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1952 usbredir-9:1: spice_channel_recv_link_msg:
> 2 caps
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1966 usbredir-9:1: got remote common caps:
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1902 0:0xB
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1973 usbredir-9:1: got remote channel caps:
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1902 0:0x1
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2921 test cap 0 in 0xB: yes
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2921 test cap 1 in 0xB: yes
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2921 test cap 3 in 0xB: yes
> 2021-12-21 02:14:00.014 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:2005 usbredir-9:1: use mini header: 1
> 2021-12-21 02:14:00.018 3011-3116/com.iiordanov.aSPICE D/GLib+GSpice:
> ../src/spice-channel.c:1303 usbredir-9:1: channel up, state 3
> ==
>
> Your help and suggestions are highly appreciated!
>
> Sincerely,
> iordan
>
> On Mon, Dec 20, 2021 at 5:57 AM Uri Lublin  wrote:
> >
> > Hi iordan,
> >
> > On Mon, Dec 20, 2021 at 9:46 AM i iordanov  wrote:
> > >
> > > Hi guys,
> > >
> > 

Re: [Spice-devel] attaching a USB device by libusb_device or libusb_device_handle on Android

2021-12-20 Thread Uri Lublin
Hi iordan,

On Mon, Dec 20, 2021 at 9:46 AM i iordanov  wrote:
>
> Hi guys,
>
> I saw that the developers at libusb have done a bunch of work to
> support accessing USB devices on unrooted Android devices, and in
> response to a user request, I decided to look into the current state
> of the implementation.

Congrats to libusb developers.

>
> I am able to obtain permissions and get both:
>
> libusb_device *dev
>
> and
>
> libusb_device_handle *handle
>
> for an attached USB stick, but now do not have a good idea how to
> request libspice to attach the device to the remote.
>
> Is there an API exposed that would permit me to attach devices by
> either libusb_device or libusb_device_handle? In either case, any
> pointers on how to accomplish this are welcome!

On the client side, you need to build usbredir and rebuild spice-gtk
with usbredir enabled.

On the server side you need to build usbredir and rebuild Qemu with
usbredir enabled.
You also need to add to your VM configuration some USB devices and
attach them to SPICE.
See SPICE User Manual [1] "USB redirection" for details.

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

Regards,
Uri.

>
> Sincerely,
> iordan
>
> --
> The conscious mind has only one thread of execution.
>



Re: [Spice-devel] No mouse with nvidia driver (spice-vdagent not working)

2021-08-23 Thread Uri Lublin
Hi,

What Victor said but also more below.


On Mon, Aug 23, 2021 at 6:34 PM Victor Toso  wrote:

> Hi,
>
> On Mon, Aug 23, 2021 at 05:14:00PM +0300, ole-kru...@yandex.ru wrote:
> > - nvidia vGPU with proprietary driver is the only video
> > adapter.
>
> This is a know issue. NVIDIA driver does not provide a guest
> cursor. You can probably verify it with VNC too.
>

> The proper fix is to NVIDIA implement this feature, otherwise all
> we have is workarounds.
>
> You can try running a spice-gtk based client like remote-viewer
> with SPICE_DEBUG_CURSOR=1 as that might give you something
> rendered in the client side.
>

Yeah, it's the same for VNC.
Recently a command line option was added to virt-viewer/remote-viewer for
VNC.
https://gitlab.com/virt-viewer/virt-viewer/-/merge_requests/78


>
> You could also try to set "HWCursor" "off" in the xorg
> configuration file.
>
> > - spice-vdagent v.0.20 and qemu-guest-agent are installed.
>
> You should try v0.21 as I recall people were doing work around
> testing NVDIA and Wayland based systems, although I can't
> pinpoint something that would fix the logs I see.
>
>
I think the problem is not with spice-vdagent, but that SPICE gets no
cursor data from NVIDIA.

What qemu-kvm command line option do you use for connecting with the NVIDIA
GPU ?

Uri


Re: [Spice-devel] Speed of file transfers

2021-07-12 Thread Uri Lublin
On Thu, Jul 8, 2021 at 12:59 PM Sofia Son  wrote:

>  hello,i use proxmox host, and remote vms by spice, and why speed file
> transfers through drag and drop is slowly,only 150kb -230kb/s ,how can i
> improve this speed ?although in LAN but when i drag and drop file i have to
> compress file,cant be transfer folder
>


Hi,

1. Drag and Drop transfer rate:
How fast is your connection ?
For example, what is the transfer rate when you copy a file from client to
guest using e.g. scp ?
Is it only for a single host/VM or all hosts/VMs ?

I just tried to drag and drop a big file from my host (Fedora 33) to a VM
running on that host  (Fedora 34 guest) and I'm seeing a much faster
transfer rate.

2. Compress files copied via Drag and Drop:
It's probably good for big files.

3. Transferring a folder via Drag and Drop:
It's not currently possible.
You can transfer a folder via the SPICE WebDAV feature.

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


Re: [Spice-devel] [PATCH] meson: Fix pkgconfig required library name reference

2021-04-08 Thread Uri Lublin

Hi,

Thanks for sending this patch.

On 4/6/21 7:49 PM, Bruce Rogers wrote:

Signed-off-by: Bruce Rogers 


Ack.

Uri.


---
  usbredirhost/meson.build | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/usbredirhost/meson.build b/usbredirhost/meson.build
index 28dc688..a09188c 100644
--- a/usbredirhost/meson.build
+++ b/usbredirhost/meson.build
@@ -51,5 +51,6 @@ pkgconfig = import('pkgconfig')
  pkgconfig.generate(usbredir_host_lib,
 name : 'libusbredirhost',
 description : 'usbredirhost library',
-   requires : [libusb_required_version, 'usbredirparser-0.5'],
+   requires : [libusb_required_version, 
'libusbredirparser-0.5'],
 variables : 'exec_prefix=${prefix}')
+



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


Re: [Spice-devel] Multiple monitors at 4K, in virt-manager?

2021-03-22 Thread Uri Lublin

On 3/22/21 5:27 PM, Dr. Jennifer Nussbaum wrote:
On Monday, March 22, 2021, 10:51:48 AM EDT, Victor Toso 
 wrote:


Hi,

On Mon, Mar 22, 2021 at 01:46:08PM +, Dr. Jennifer Nussbaum wrote:


 > > I'm using virt-manger, and its related suite of stuff, to run
 > > KVM/QEMU VM's on a Debian Bullseye host, which has two 4K
 > > monitors. I am unable to get dual-head working at all, and I
 > > can't get 4K resolution working in the way I'm apparently
 > > supposed to.
 >
 > Can you share the vm's domain? virsh dumpxml $vm

I've posted this at the bottom of this message, with only small changes 
to obscure the UUID and paths.


 > > I have a Debian Bullseye guest, with spice-vdagent and the QXL

 > video drivers installed in it. The Spice user manual suggests
 > that multiple-monitor support is easy; you're supposed to use a
 > Video QXL device and then everything should just work. But it
 > doesn't. Even when I increase the video memory in the XML file
 > (vgamem, I assume) to 64MB I am unable to get 4K on even a
 > single monitor using Settings -> Display on the guest; it maxes
 > out at some arbitrary-seeming thing a bit over 1980 x 1200. And
 > regardless of resolution, I also do not have a second monitor
 > available in the guest.


Hi,

It seems 64MB is not enough.

4096 * 2160 * 4 * 2 > 64MB

Can you try replacing all those 64MB below with 128MB ?
Please try with 1 head first. Possibly 2 heads need
more (but not for all params).

Regards,
Uri.


 >
 > Are you accessing with virt-manager? I don't think there is
 > support for multi-monitor there? You should use virt-viewer or
 > remote-viewer instead.

virt-manager uses virt-viewer natively; it's what virt-manager fires up 
when you use the "view graphical console" option.


Regardless, I did just launch virt-viewer separately, and it's 
functioning in the same way.



 > If I have a video device set to Virtio, then 4K works perfectly
 > on the guest machine; if I go to Settings -> Display there, I
 > can select 4096 x 2160, and I get lovely 4K video. However,
 > dual-head does not work. If I try to edit the XML for the video
 > device to 'heads="2"', there is no effect--at least, when I
 > restart the guest and go to Settings -> Display, there isn't an
 > option for selecting another monitor.  Could someone tell me
 > what I'm supposed to be doing?  Thank you.

Just confirming, for Spice multi-monitor [0] in recent linux
guests, one qxl device is enough and you should set the heads to
2 (virsh edit $vm)


As you can see from the XML below, I do (think I) have one qxl device, 
with 2 heads and 64MB memory.


When I go into the guest, the maximum resolution I am offered is 2952 x 
1781. And there is only one display,

called "Virtual-0".

Thank you for looking this over.

Jen




   debian-bullseye-test
   36d7d0e7-4801-4396-9f61-2b5022xxx
   4194304
   4194304
   2
   
     hvm
     
   
   
     
     
     
   
   
   
     
     
     
   
   destroy
   restart
   restart
   
     
     
   
   
     /usr/bin/kvm
     
       
       
       
       function="0x0"/>

     
     
       
       
       
       
     
     
       function="0x7"/>

     
     
       
       function="0x0" multifunction="on"/>

     
     
       
       function="0x1"/>

     
     
       
       function="0x2"/>

     
     
     
       function="0x1"/>

     
     
       function="0x0"/>

     
     
       
       
       
       function="0x0"/>

     
     
       
         
       
     
     
       
     
     
       
       
     
     
       
       
     
     
       
     
     
     
     
       
       
     
     
       function="0x0"/>

     
     
       heads="2" primary="yes"/>
       function="0x0"/>

     
     
       
     
     
       
     
     
       function="0x0"/>

     
   



___
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] Problems encountered during development

2021-02-07 Thread Uri Lublin

On 2/4/21 4:45 AM, ?? wrote:

Dear friend:
I'm having some problems compiling Spice - Server, this version is 
0.14.91, spice-protocol version is 0.14.3, compiling always fails. I 
can't think of a solution. I hope you can help me, thank you!


What OS are you running on ?
It seems your C++ compiler version is  5.4.0, can you use a newer one ?

Also the compiler used is located under /usr/local. It may help if
you use the system C++ compiler ?

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


Re: [Spice-devel] Is the data after USB camera redirection compressed?

2021-02-02 Thread Uri Lublin

On 2/2/21 2:50 PM, lx wrote:



Uri Lublin mailto:u...@redhat.com>> 于2021年1月31日周 
日 下午9:48写道:


On 1/30/21 1:25 PM, lx wrote:
 > Frediano Ziglio mailto:fredd...@gmail.com>>
于2021年1月29日周五 下午6:39写道:
 >
 >> Il giorno gio 28 gen 2021 alle ore 01:45 lx
mailto:lxlenovos...@gmail.com>> ha
 >> scritto:
 >>>
 >>>
 >>> Uri Lublin mailto:u...@redhat.com>> 于2021年1
月27日周三 下午11:47写道:
 >>>>
 >>>> On 1/27/21 4:22 AM, lx wrote:
 >>>>> Hi all:
 >>>>>          If I redirect USB camera to virtual machine, I think
we send
 >>>>> original URB to virtual machine by USB channel.
 >>>>> Is this understanding correct? If we want to improve the user
 >> experience,
 >>>>> we need to compress URB data?
 >>>>
 >>>> Hi,
 >>>>
 >>>> If you build with lz4 enabled (both client and server),
 >>>> then it should use lz4 to compress the data.
 >>>>
 >>>> There is no functionality to create
 >>>> a video stream out of raw data.
 >>>>
 >>>> Can the USB camera be configured to send a compress stream?
 >>>>
 >>>> Uri.
 >>>>
 >>>
 >>>    Hi:
 >>>     USB camera can support MJPG and YUV.   I think H264 is
better than
 >> MJPG. So Can we
 >>> let spice support H264 ? Is this feasible?
 >>>
 >>
 >> This is independent from SPICE, if the camera send compressed data
 >> already SPICE will just
 >> forward compressed data in whatever format is in USB.
 >> If the camera supports MJPEG and YUV choose MJPEG, YUV is not
 >> compressed (just a different color
 >> space than RGB, often taking less bits but still not compressed).
 >>
 >> Frediano
 >>
 >
 > If the camera chooses YUV, can we encode it to H264 in SPICE? Is this
 > feasible?

Currently, SPICE does not do look at USB data.


Hi:

What do you mean spice just forward USB protocol data?


SPICE does look at USB headers, configurations, etc.

I meant that SPICE does not look at data that is
being transferred. So for example, it does
not know if the data coming from the camera is YUV,
RGB, MJPEG or other.

To answer your question above more clearly:
Currently it's not possible to H264-encode the
YUV data coming from the camera.
It is feasible to add code that does it.
If possible, it's best if the camera sends an encoded video stream.

Uri.

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


Re: [Spice-devel] Is the data after USB camera redirection compressed?

2021-01-31 Thread Uri Lublin

On 1/30/21 1:25 PM, lx wrote:

Frediano Ziglio  于2021年1月29日周五 下午6:39写道:


Il giorno gio 28 gen 2021 alle ore 01:45 lx  ha
scritto:



Uri Lublin  于2021年1月27日周三 下午11:47写道:


On 1/27/21 4:22 AM, lx wrote:

Hi all:
 If I redirect USB camera to virtual machine, I think we send
original URB to virtual machine by USB channel.
Is this understanding correct? If we want to improve the user

experience,

we need to compress URB data?


Hi,

If you build with lz4 enabled (both client and server),
then it should use lz4 to compress the data.

There is no functionality to create
a video stream out of raw data.

Can the USB camera be configured to send a compress stream?

Uri.



   Hi:
USB camera can support MJPG and YUV.   I think H264 is better than

MJPG. So Can we

let spice support H264 ? Is this feasible?



This is independent from SPICE, if the camera send compressed data
already SPICE will just
forward compressed data in whatever format is in USB.
If the camera supports MJPEG and YUV choose MJPEG, YUV is not
compressed (just a different color
space than RGB, often taking less bits but still not compressed).

Frediano



If the camera chooses YUV, can we encode it to H264 in SPICE? Is this
feasible?


Currently, SPICE does not do look at USB data.

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


Re: [Spice-devel] Compression parameters in images

2021-01-27 Thread Uri Lublin

On 1/27/21 8:39 AM, alireza kahdoyee wrote:

Hi dear friend

I am working on the connection between the spice client and the spice server 
and I
do not have information about the parameters below the to know the exact settings. 
>

image-compression

jpeg-wan-compression

zlib-glz-wan-compression

I searched the internet a lot, but I did not find the exact information. If 
possible, send
me a good document about this or help me.

Thank you


Hi,

You can find more information at the "Image Compression" section of the
spice-user-manual.
https://www.spice-space.org/spice-user-manual.html

Also "man qemu-kvm" provides some information:

image-compression=[auto_glz|auto_lz|quic|glz|lz|off]
Configure  image  compression  (lossless).
Default is auto_glz.

jpeg-wan-compression=[auto|never|always];
zlib-glz-wan-compression=[auto|never|always]
Configure wan image compression (lossy for slow links).
Default is auto.

Uri.

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


Re: [Spice-devel] Is the data after USB camera redirection compressed?

2021-01-27 Thread Uri Lublin

On 1/27/21 4:22 AM, lx wrote:

Hi all:
If I redirect USB camera to virtual machine, I think we send
original URB to virtual machine by USB channel.
Is this understanding correct? If we want to improve the user experience,
we need to compress URB data?


Hi,

If you build with lz4 enabled (both client and server),
then it should use lz4 to compress the data.

There is no functionality to create
a video stream out of raw data.

Can the USB camera be configured to send a compress stream?

Uri.

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


Re: [Spice-devel] Working seamless mode

2021-01-11 Thread Uri Lublin

On 1/10/21 6:50 PM, Roland Baudin wrote:

Hi Jakub,

thanks for your detailed answer. I understand there may issues with 
Wayland, but IMHO the vast majority of Linux users don't use Wayland yet 
(too many problems!). So I still think your work is very useful. I use 
the seamless mode at home and at work in Ubuntu 20.04 and it works very 
nicely.


But I understand it's difficult to maintain theses patches and make them 
evolve.


Have a nice day,
RB


Hi,

Please do send your patches to the list.
The best way is with git send-email, but attachments
also work. Prefix patch subject with the component
it belongs to (for example [spice-gtk]).

Alternatively, if you prefer, you can create an issue
on gitlab.freedesktop.com, as Jakub suggested, and
add the the patches there.

Maybe your patches will not be maintained, but
by sharing them, others can try a better
seamless-mode and maybe even improve it further.

Thanks,
Uri.





Le 06/01/2021 à 12:48, Jakub Janku a écrit :

Hi,

On Sat, Jan 2, 2021 at 9:49 AM Roland Baudin  wrote:

Hi,

perhaps this is not the right place for this request? Could you give me
some place where I can post this request?

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

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

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

and guest side).

The main problem is probably the design itself.

spice-gkt/virt-viewer shows a single fullscreen window that is
partially transparent
(in the areas where there's no guest window). This results in a poor 
integration

with the client's system -- what you'd want is to have a new window in
the client for each
window/application on the guest and separate drawing contexts for each 
app.

The original thread goes into more detail on the issues, I think.

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

Regards,
Jakub


Thanks a lot,
RB


Le 31/12/2020 à 10:42, Roland Baudin a écrit :

Hi there,

for my own purpose, I have ported the seamless mode patches written by
Jakub Janků, Ondřej Holý and Lukáš Venhoda (see
https://www.spinics.net/lists/spice-devel/msg30177.html) to Ubuntu 
20.04.


I have also hacked the virt-viewer gtk app to allow easily entering
and leaving seamless mode. This is a very convenient way to work with
the VM in Ubuntu. It's probably not difficult to do the same with
virt-manager but alas I'm not a Python programmer.

So, I have a set of packages for Ubuntu 20.04 and installation of
these packages is very simple. In the Windows VM, it is also required
to replace the vdagent and vdservice programs by the patched ones.
This is not difficult, but it's a manual process for now.

Everything works well (but there are probably issues I didn't see,
possibly with multiple screens) and I think this could be a major
improvement to the kvm/qemu user experience in Linux.

However, I don't have time (and skills) to maintain these packages and
patches. I have two other open source projects (Xfe and TexMaths) and
a full time job...

So, I'm asking here if someone is interestedto get this work and
maintain it? I could give you my packages (the patches are in the
source packages) and a little explanation to start.

I'd be happy if the community could build something useful upon this
work.

If someone is interested, how can I send the files? Mail attachment to
this list? Google drive?

Thanks for andy answer and have a nice day,

RB




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



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


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


Re: [Spice-devel] TLS + Letsencrypt doesn't work on Windows

2020-12-21 Thread Uri Lublin
pem | grep 'Subject:'
 # and remove spaces

remote-viewer --spice-ca-file=$path_to_ca-cert.crt 
spice+tls://DOMAIN:5901 (works >

remote-viewer on Windows:
remote-viewer spice+tls://DOMAIN:5901 (doesn't work)
remote-viewer --spice-ca-file=$path_to_ca-cert.crt 
spice+tls://DOMAIN:5901 (doesn't work)


Does it help if you provide it a --spice-host-subject ?

I'll try to give it a try soon.

Uri.



debug output of both provided in the first email, also tried building 
remote-viewer and spice-client libraries from MASTER for windows.


Thank you for the help!
---
Armin ranjbar



On Sun, Dec 20, 2020 at 6:50 PM Uri Lublin <mailto:u...@redhat.com>> wrote:


On 12/15/20 1:45 PM, Armin Ranjbar wrote:
 > Dear Everyone,
 >
 > As always, let me thank you first for the effort you put in Spice.
 >
 > I have a strange case here, libvirt is configured with letsencrypt
 > certificates, remote-viewer works happily on Linux, but it
doesn't seem
 > to be able to get local issuer certificate on windows.
 > same error even when I try to give the address of CA file via
 > --spice-ca-file, attaching logs with spice-debug here:

Hi,

Can you please provide
1. qemu-kvm commandline -spice option
2. remote-viewer commandline (for both windows and linux)?
3. Does the Linux remote-viewer run on the same
     machine as libvirt/qemu-kvm or does it run on a
     different machine?
4. Did you copy the CA-certificate onto the windows machine ?
     (Just verifying, I see the name is correctly ca-cert.pem)

Uri.

 >
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.293:
 > ../src/spice-session.c:292 Supported channels: main, display,
inputs,
 > cursor, playback, record, usbredir
 > (remote-viewer.exe:3584): Spice-DEBUG: 15:13:17.293:
 > ../src/usb-device-manager.c:259:spice_usb_device_manager_init: UsbDk
 > driver is not installed
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.293:
 > ../src/usb-device-manager.c:485 auto-connect filter set to
 > 0x03,-1,-1,-1,0|-1,-1,-1,-1,1
 >
 > (remote-viewer.exe:3584): GSpice-CRITICAL **: 15:13:17.293:
 > _usbdk_hider_update: assertion 'priv->usbdk_api != NULL' failed
 >
 > (remote-viewer.exe:3584): GSpice-WARNING **: 15:13:17.962:
password may
 > be visible in process listings
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.965:
 > ../src/spice-session.c:1814 no migration in progress
 > Spice-INFO: 15:13:17.965:
 > ../src/channel-main.c:337:spice_main_set_property:
 > SpiceMainChannel::color-depth has been deprecated. Property is
ignored
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.965:
 > ../src/spice-channel.c:141 main-1:0: spice_channel_constructed
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.965:
 > ../src/spice-session.c:2309 main-1:0: new main channel, switching
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.680:
 > ../src/spice-channel.c:2707 main-1:0: Open coroutine starting
 > 0462E480
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.680:
 > ../src/spice-channel.c:2544 main-1:0: Started background coroutine
 > 0462E338
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.680:
 > ../src/spice-session.c:2231 Missing port value, not attempting
 > unencrypted connection.
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.680:
 > ../src/spice-channel.c:2570 main-1:0: trying with TLS port
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.694:
 > ../src/spice-session.c:2244 main-1:0: Using TLS, port 5901
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.694:
 > ../src/spice-session.c:2177 open host DOMAIN_REPLACED:5901
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.694:
 > ../src/spice-session.c:2099 main-1:0: connecting 071DFDD0...
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.757:
 > ../src/spice-session.c:2083 main-1:0: connect ready
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.757:
 > ../src/spice-channel.c:2466 main-1:0: Load CA, file: C:\ca-cert.pem,
 > data: 
 >
 > (remote-viewer.exe:3584): Spice-WARNING **: 15:13:18.819:
 > ../subprojects/spice-common/common/ssl_verify.c:444:openssl_verify:
 > Error in certificate chain verification: unable to get issuer
 > certificate (num=2:depth1:/C=US/O=Let's Encrypt/CN=R3)
 >
 > (remote-viewer.exe:3584): GSpice-WARNING **: 15:13:18.819: main-1:0:
 > SSL_connect: error:0001:lib(0):func(0):reason(1)
 > (remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.819:
 > ../src/spice-channel.c:2680 main-1:0: Coroutine exit main-1:0
 > (remote-

Re: [Spice-devel] TLS + Letsencrypt doesn't work on Windows

2020-12-20 Thread Uri Lublin

On 12/15/20 1:45 PM, Armin Ranjbar wrote:

Dear Everyone,

As always, let me thank you first for the effort you put in Spice.

I have a strange case here, libvirt is configured with letsencrypt 
certificates, remote-viewer works happily on Linux, but it doesn't seem 
to be able to get local issuer certificate on windows.


Hi,

Can you please provide
1. qemu-kvm commandline -spice option
2. remote-viewer commandline (for both windows and linux)?
3. Does the Linux remote-viewer run on the same
   machine as libvirt/qemu-kvm or does it run on a
   different machine?
4. Did you copy the CA-certificate onto the windows machine ?
   (Just verifying, I see the name is correctly ca-cert.pem)

Uri.


same error even when I try to give the address of CA file via 
--spice-ca-file, attaching logs with spice-debug here:


(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.293: 
../src/spice-session.c:292 Supported channels: main, display, inputs, 
cursor, playback, record, usbredir
(remote-viewer.exe:3584): Spice-DEBUG: 15:13:17.293: 
../src/usb-device-manager.c:259:spice_usb_device_manager_init: UsbDk 
driver is not installed
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.293: 
../src/usb-device-manager.c:485 auto-connect filter set to 
0x03,-1,-1,-1,0|-1,-1,-1,-1,1


(remote-viewer.exe:3584): GSpice-CRITICAL **: 15:13:17.293: 
_usbdk_hider_update: assertion 'priv->usbdk_api != NULL' failed


(remote-viewer.exe:3584): GSpice-WARNING **: 15:13:17.962: password may 
be visible in process listings
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.965: 
../src/spice-session.c:1814 no migration in progress
Spice-INFO: 15:13:17.965: 
../src/channel-main.c:337:spice_main_set_property: 
SpiceMainChannel::color-depth has been deprecated. Property is ignored
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.965: 
../src/spice-channel.c:141 main-1:0: spice_channel_constructed
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:17.965: 
../src/spice-session.c:2309 main-1:0: new main channel, switching
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.680: 
../src/spice-channel.c:2707 main-1:0: Open coroutine starting 
0462E480
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.680: 
../src/spice-channel.c:2544 main-1:0: Started background coroutine 
0462E338
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.680: 
../src/spice-session.c:2231 Missing port value, not attempting 
unencrypted connection.
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.680: 
../src/spice-channel.c:2570 main-1:0: trying with TLS port
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.694: 
../src/spice-session.c:2244 main-1:0: Using TLS, port 5901
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.694: 
../src/spice-session.c:2177 open host DOMAIN_REPLACED:5901
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.694: 
../src/spice-session.c:2099 main-1:0: connecting 071DFDD0...
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.757: 
../src/spice-session.c:2083 main-1:0: connect ready
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.757: 
../src/spice-channel.c:2466 main-1:0: Load CA, file: C:\ca-cert.pem, 
data: 


(remote-viewer.exe:3584): Spice-WARNING **: 15:13:18.819: 
../subprojects/spice-common/common/ssl_verify.c:444:openssl_verify: 
Error in certificate chain verification: unable to get issuer 
certificate (num=2:depth1:/C=US/O=Let's Encrypt/CN=R3)


(remote-viewer.exe:3584): GSpice-WARNING **: 15:13:18.819: main-1:0: 
SSL_connect: error:0001:lib(0):func(0):reason(1)
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.819: 
../src/spice-channel.c:2680 main-1:0: Coroutine exit main-1:0
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.819: 
../src/spice-channel.c:2871 main-1:0: reset
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.819: 
../src/channel-main.c:1567 agent connected: no
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.819: 
../src/spice-channel.c:2819 main-1:0: channel reset
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.819: 
../src/spice-channel.c:2425 main-1:0: Delayed unref channel 0462E480
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.819: 
../src/spice-session.c:2006 session: disconnecting 0
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.819: 
../src/spice-session.c:2349 main-1:0: the session lost the main channel
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.835: 
../src/spice-channel.c:2888 main-1:0: channel disconnect 0
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.835: 
../src/spice-channel.c:159 main-1:0: spice_channel_dispose 0462E480
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:18.835: 
../src/spice-channel.c:2888 main-1:0: channel disconnect 12
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:19.756: 
../src/spice-session.c:2006 session: disconnecting 1151
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:19.757: 
../src/spice-session.c:288 New session (compiled from package spice-gtk 
0.37)
(remote-viewer.exe:3584): GSpice-DEBUG: 15:13:19.758: 
../src/spice-session.c:292 

Re: [Spice-devel] Windows 10 VDAgent incompatible with "hidden" KVM?

2020-09-29 Thread Uri Lublin

On 9/25/20 7:39 PM, Frediano Ziglio wrote:


On 9/25/20 9:47 AM, Ian Pilcher wrote:

On 9/25/20 2:34 AM, Frediano Ziglio wrote:


Can you post the agent logs when it's not working?


Where are the agent logs stored?



Found 'em.

Here is the vdagent.log when the GPU is disabled (when the mouse works):

4348::INFO::2020-09-25 10:26:31,627::run::***Agent started in session 1***
4348::INFO::2020-09-25 10:26:31,627::log_version::0.9.0.0
4348::INFO::2020-09-25 10:26:31,627::debug_print_config::\\.\DISPLAY1
[Before SetDisplayConfig] (0,0) (1680x1050).
4348::INFO::2020-09-25 10:26:31,627::set_display_config::path states
says nothing changed
4348::INFO::2020-09-25 10:26:31,627::consistent_displays::#qxls 1 #others 0
4348::INFO::2020-09-25 10:26:31,643::send_announce_capabilities::Sending
capabilities:
4348::INFO::2020-09-25 10:26:31,643::send_announce_capabilities::6B7
4348::INFO::2020-09-25 10:26:31,643::run::Connected to server
4348::INFO::2020-09-25
10:26:31,643::input_desktop_message_loop::Desktop: Winlogon
4348::INFO::2020-09-25 10:26:31,658::handle_announce_capabilities::Got
capabilities (1)
4348::INFO::2020-09-25 10:26:31,674::handle_announce_capabilities::35077
4348::INFO::2020-09-25 10:26:31,674::send_announce_capabilities::Sending
capabilities:
4348::INFO::2020-09-25 10:26:31,674::send_announce_capabilities::6B7
4348::INFO::2020-09-25 10:26:31,674::handle_announce_capabilities::Got
capabilities (1)
4348::INFO::2020-09-25 10:26:31,674::handle_announce_capabilities::35077
4348::INFO::2020-09-25 10:26:31,674::set::setting display options
4348::INFO::2020-09-25 10:26:31,674::get_user_process_id::explorer.exe
not found
4348::INFO::2020-09-25
10:26:31,674::reload_from_registry::get_user_process_id failed
4348::INFO::2020-09-25 10:26:31,674::handle_max_clipboard::Set max
clipboard size: 104857600
4348::INFO::2020-09-25 10:26:31,674::handle_mon_config::0. 1680*1050*32
(0,0) 1
4348::INFO::2020-09-25 10:26:31,674::consistent_displays::#qxls 1 #others 0
4348::INFO::2020-09-25 10:26:31,674::update_mode_position::\\.\DISPLAY1
updated path mode to (0, 0) - (1680 x1050)
4348::INFO::2020-09-25 10:26:31,674::handle_max_clipboard::Set max
clipboard size: 104857600
4348::INFO::2020-09-25 10:26:31,674::handle_mon_config::0. 1680*1050*32
(0,0) 1
4348::INFO::2020-09-25 10:26:31,674::consistent_displays::#qxls 1 #others 0
4348::INFO::2020-09-25 10:26:31,674::update_mode_position::\\.\DISPLAY1
updated path mode to (0, 0) - (1680 x1050)
4348::INFO::2020-09-25 10:26:33,408::handle_control_event::Control command 3
4348::INFO::2020-09-25 10:26:33,408::handle_control_event::session logon
4348::INFO::2020-09-25 10:26:36,440::handle_control_event::Control command 2
4348::INFO::2020-09-25
10:26:36,440::input_desktop_message_loop::Desktop: Default
4348::INFO::2020-09-25 10:26:36,440::input_desktop_message_loop::First
display setting
4348::INFO::2020-09-25 10:26:36,440::load::loading display setting
4348::INFO::2020-09-25 10:26:36,440::reload_from_registry::explorer pid 5796
4348::INFO::2020-09-25 10:26:36,440::reload_wallpaper::
4348::INFO::2020-09-25 10:26:36,440::reload_wallpaper::wallpaper wasn't
disabled
4348::INFO::2020-09-25 10:26:36,440::reload_font_smoothing::
4348::INFO::2020-09-25 10:26:36,440::reload_font_smoothing::font
smoothing value didn't change
4348::INFO::2020-09-25 10:26:36,440::reload_animation::
4348::INFO::2020-09-25 10:26:36,440::reload_win_animation::
4348::INFO::2020-09-25 10:26:36,440::reload_win_animation::reload window
animation: success
4348::INFO::2020-09-25 10:26:36,440::reload_ui_effects::
4348::INFO::2020-09-25
10:26:36,440::reload_ui_effects::UserPreferencesMask = 80071e9e 12
4348::INFO::2020-09-25 10:26:46,268::handle_control_event::Control command 2
4348::INFO::2020-09-25
10:26:46,268::input_desktop_message_loop::Desktop: Winlogon
4348::INFO::2020-09-25 10:26:50,596::handle_control_event::Control command 2
4348::INFO::2020-09-25
10:26:50,596::input_desktop_message_loop::Desktop: Default
4348::INFO::2020-09-25 10:27:48,096::event_dispatcher::received stop event
4348::INFO::2020-09-25 10:27:48,112::run::Agent stopped

And here is vdagent.log when the GPU is enabled (when the mouse doesn't
work):

4172::INFO::2020-09-25 10:09:09,885::run::***Agent started in session 1***
4172::INFO::2020-09-25 10:09:09,885::log_version::0.9.0.0
4172::INFO::2020-09-25 10:09:09,885::debug_print_config::\\.\DISPLAY1
[Before SetDisplayConfig] (0,0) (1680x1050).
4172::INFO::2020-09-25 10:09:09,885::set_display_config::path states
says nothing changed
4172::INFO::2020-09-25 10:09:09,885::consistent_displays::#qxls 1 #others 4
4172::INFO::2020-09-25 10:09:09,885::run::No QXL devices!
4172::INFO::2020-09-25 10:09:09,901::send_announce_capabilities::Sending
capabilities:
4172::INFO::2020-09-25 10:09:09,901::send_announce_capabilities::6B7
4172::INFO::2020-09-25 10:09:09,901::run::Connected to server
4172::INFO::2020-09-25
10:09:09,901::input_desktop_message_loop::Desktop: Winlogon
4172::INFO::2020-09-25 

Re: [Spice-devel] OSX Client Bundle

2020-08-09 Thread Uri Lublin

On 8/8/20 10:44 PM, D. L. Fuller wrote:

Noob here trying to use SPICE from a Mac for a Proxmox VM.



Note that I do not run Promox VMs nor use a Mac client.



I downloaded and installed RemoteViewer from 
RemoteViewer-0.5.7-1.dmg.And setup my Ubuntu VM for SPICE in the Proxmox 
Console. Then I had to download the "download" file which I assume is 
not needed in this case.


Is the "download" file of type .vv, e.g. console.vv?

If it is, try running from the command line: remote-viewer 



BTW, is 0.5.7 the latest verion of remote-viewer for Mac ?



RemoteViewer opens with a window requesting an URL.Everything I try is 
rejected.



What am I missing?Any suggestions sure appreciated.



If you know the hostname and port the spice-server is listening
on (via qemu-kvm), try -- spice://host:port

Uri

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


Re: [Spice-devel] spice-streaming-agent, the motivation and drive

2020-07-26 Thread Uri Lublin

On 7/26/20 4:36 PM, Armin Ranjbar wrote:

Thanks for the Info,

looking at the code, it seems support for running the streaming agent on
windows is not yet implemented, is there a blocker to this? (excluding the
build scripts, etc)


I think there is no blocker for running it on windows guests.
I never tried it.

Uri.



---
Armin ranjbar



On Sun, Jul 26, 2020 at 5:18 PM Uri Lublin  wrote:


On 7/25/20 6:43 PM, Armin Ranjbar wrote:

Dear All

First of all, let me thank you again for your efforts!

I was reading on spice-streaming-agent, which is in experimental stage,

and

I was wondering what is the driver behind the idea?
Will that lead to less bandwidth consumption? less latency? or is it

just a

refactoring to make the codebase cleaner?


Hi,

It is possible to configure a VM with a hardware GPU (either assign the
whole
device to the VM or a part of it).
That is helpful for running, on the guest, applications that require such
strong GPU (e.g. 3D graphics).
When that is the case, spice-streaming-agent can use the GPU
on the guest
to stream video (encode the screenbuffer and send it).
This is what spice-streaming-agent does and it indeed leads to less
bandwidth used.

Uri.






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


Re: [Spice-devel] spice-streaming-agent, the motivation and drive

2020-07-26 Thread Uri Lublin

On 7/25/20 6:43 PM, Armin Ranjbar wrote:

Dear All

First of all, let me thank you again for your efforts!

I was reading on spice-streaming-agent, which is in experimental stage, and
I was wondering what is the driver behind the idea?
Will that lead to less bandwidth consumption? less latency? or is it just a
refactoring to make the codebase cleaner?


Hi,

It is possible to configure a VM with a hardware GPU (either assign the 
whole

device to the VM or a part of it).
That is helpful for running, on the guest, applications that require such
strong GPU (e.g. 3D graphics).
When that is the case, spice-streaming-agent can use the GPU
on the guest
to stream video (encode the screenbuffer and send it).
This is what spice-streaming-agent does and it indeed leads to less 
bandwidth used.


Uri.

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


Re: [Spice-devel] spice & virt-viewver & dedicated mouse & keyboard

2020-07-05 Thread Uri Lublin

On 7/4/20 12:13 PM, mnavahan wrote:

Hi

I have problem with virt-viewver & dedicated mouse & keyboard

I use spice with VirGL in Ubuntu 20.04 server with also Ubuntu guest 20.04

We Have TWO monitor & also TWO mouse & keyboard

then i pass 2nd mouse & keyboard to guest , and also use virt-viewer

for use of two different user i move virt-viewer to 2nd monitor but 
seems when host mouse out of  virt-viewer screen , guest mouse work BUT 
cursor hide :-(


how disable guest mouse always show in this mode ?


Hi,

The VM has only a single virtual monitor plus its own
mouse+keyboard usb devices, right ?

Try adding ",agent-mouse=off" to "-spice" option of your qemu-kvm 
command line.


Uri.

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


Re: [Spice-devel] drag and drop

2020-07-02 Thread Uri Lublin

On 7/2/20 8:57 AM, Peter Kecho wrote:

Hello.

I'm using a Manjaro host with XFCE and running a windows 10 vm on KVM. I 
have downloaded and ran the spice guest tools latest on the windows 
client and can now copy and paste from host to vm and from vm to host, 
but can only drag and drop from host to vm. I cannot drag and drop from 
vm to host. Please advise.


Hi,

The drag and drop feature only works from client to guest.

If you need to copy files both ways, you can try using webdav

Uri.

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


Re: [Spice-devel] No mouse under Win 10 when Nvidia drivers are active

2020-06-02 Thread Uri Lublin

On 6/2/20 4:50 PM, ole-kru...@yandex.ru wrote:

Hi,
No, I do not use spice-streaming-agent with windows VM at all.


How do you see the NVIDIA window on the client ?



01.06.2020, 22:24, "Uri Lublin" :

On 6/1/20 6:59 PM, ole-kru...@yandex.ru
<mailto:ole-kru...@yandex.ru> wrote:

  Now I have tried different combinations of vd-agent state and
mouse
  cursor type. In no case mouse cursor was visible on nvidia display
  window. With dual display, qxl+nvidia, stopping vd-agent made
cursor
  visible on qxl window. Reaction to mouse events was seen on nvidia
  window too, but with invisible mouse cursor.



Hi,

I assume you have your own spice-streaming-agent plugin.

Does it support the display_info interface ?

Uri

  01.06.2020, 17:27, "Frediano Ziglio" mailto:fzig...@redhat.com>>:

    Hi all,
    when just qxl adapter is attached to VM all works
well. But
  when Nvidia GRID
    instance is attached and its drivers are running,
mouse cursor
  is never
    shown on its display window. Sometimes it's just
invisible but
  active and
    reacting to mouse movements, clicks and wheel scrolling,
  sometimes it's
    totally missing. This behaviour is a bit dependent of is
  Nvidia adapter
    alone or together with qxl. Just sometimes mouse
cursor is
  visible on qxl
    display but it's very unstable and totally unusable.
Similar
  behaviour is
    under linux VM too. Is it normal "won't fix" state,
or can I
  provide some
    additional info? Windows has latest vd-agent and
spice-agent
  installed.


  Hi,
 recently we got similar reports. Can you try to see
what's happen if
  you disable the agent?

  It seems that in these conditions the agent is not able to
handle
  the mouse
  so mouse events are "lost".

  Another test would you could do is to use the "spicy"
utility. This
  utility
  has an option to switch manually the mouse mode
(server/client). It
  would be
  helpful to understand different behaviour using the 2 modes.

  Frediano


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



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


Re: [Spice-devel] No mouse under Win 10 when Nvidia drivers are active

2020-06-01 Thread Uri Lublin

On 6/1/20 6:59 PM, ole-kru...@yandex.ru wrote:
Now I have tried different combinations of vd-agent state and mouse 
cursor type. In no case mouse cursor was visible on nvidia display 
window. With dual display, qxl+nvidia, stopping vd-agent made cursor 
visible on qxl window. Reaction to mouse events was seen on nvidia 
window too, but with invisible mouse cursor.



Hi,

I assume you have your own spice-streaming-agent plugin.

Does it support the display_info interface ?

Uri


01.06.2020, 17:27, "Frediano Ziglio" :

  Hi all,
  when just qxl adapter is attached to VM all works well. But
when Nvidia GRID
  instance is attached and its drivers are running, mouse cursor
is never
  shown on its display window. Sometimes it's just invisible but
active and
  reacting to mouse movements, clicks and wheel scrolling,
sometimes it's
  totally missing. This behaviour is a bit dependent of is
Nvidia adapter
  alone or together with qxl. Just sometimes mouse cursor is
visible on qxl
  display but it's very unstable and totally unusable. Similar
behaviour is
  under linux VM too. Is it normal "won't fix" state, or can I
provide some
  additional info? Windows has latest vd-agent and spice-agent
installed.


Hi,
   recently we got similar reports. Can you try to see what's happen if
you disable the agent?

It seems that in these conditions the agent is not able to handle
the mouse
so mouse events are "lost".

Another test would you could do is to use the "spicy" utility. This
utility
has an option to switch manually the mouse mode (server/client). It
would be
helpful to understand different behaviour using the 2 modes.

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] Stuttering video playback on LAN

2020-05-18 Thread Uri Lublin

On 5/17/20 6:35 PM, Felix Leimbach wrote:

Hi Uri,

On 17.05.20 16:08, Uri Lublin wrote:

On 5/16/20 7:07 PM, Felix Leimbach wrote:




I experience stuttering video playback in remote-viewer despite connecting
via GBit/s LAN, using fast hardware and the QXL driver.
Up until a video size of roughly 800x600 the playback is smooth. But on
anything bigger, like my native resolution of 2540x1440, video playback is
stuttering annoyingly.
After lots of unsuccessful tinkering with spice parameters and qxl parameters
I'm asking you guys for help.

Client:
Windows 10 1909
Remote Viewer 8.0-256
Quadcore i7-7820HQ 2.9GHz
16GB DDR4 RAM

Host of the VM:
Gentoo Linux
Kernel 4.14.172
Qemu 4.2.0


I've updated to newer versions in the meantime, but no noticeable changes.

Qemu 5.0.0
Host kernel 5.4.39
Remote Viewer 9.0-256 (x64) on the Windows 10 Client









I noticed very high CPU usage in the guest during playback, because chrome, 
vlc, mpv used software h264 decoding.
I fixed this by passing a virtualized instance of the hosts Intel GPU to the 
guest via GVT-g.

These are the qemu parameters I use for GVT-g:
-spice port=5906,addr=10.42.2.250,password=changed
-vga virtio
-display egl-headless,rendernode=/dev/dri/card0
-device 
vfio-pci,sysfsdev=/sys/bus/mdev/devices/f14c80d5-9ade-4802-9509-1d877d32d159,display=on,ramfb=on,driver=vfio-pci-nohotplug


Perhaps here it would help to set streaming-video=all -spice option.


It doesn't really help. Still very stuttering playback, even with a 
video-player window size of only 720x576.
I now believe this is caused by a CPU bottleneck on the CLIENT (not guest), 
i.e. my Windows 10 machine.
virt-viewer.exe uses consistently 12% CPU, which is 100% of one core (Quad Core 
with SMT => 8 logical cores).
This is crazy, since the CPU core is running a modern i7 at 3.6 GHz (Turbo) 
with no other significant CPU users (system is idle).
Could this be a problem of remote-viewer.exe not using gstreamer codecs (and hw 
accel) properly?
Got these spice-debug messages on the client: "no video decoders from GSTreamer for 
{mjpeg,vp8,h264,vp9,h265} were found".


Maybe the client is built without gstreamer.



Also I noticed that the qemu process on the host is using much CPU, probably 
due to spice encoding the video frames.
The host shows 4 qemu-ystem-x86_64 threads using 93%, 34%, 24%, 16% CPU when 
playing a 720x576 video in the guest.
However the guest shows only 14% and 7% use for its 2 vCPUs in htop because it 
uses VA-API (GPT-g) in the video player (vlc, mpv).


With egl-headless, spice-server encodes the whole screen, not 720x576 
video. Since the client

supports almost no codec likely
it's using mjpeg



So the host qemu threads use MUCH more CPU than the guest. When I disconnect 
spice (video still playing) the host qemu CPU usage drops to 35%, 1%, 1%, 1%, 
as expected.
Conclusion: Spice encoding on the host is very CPU hungry.


Your conclusion makes sense to me.



Is it possible to GPU-accelerate the video encoding in the host qemu process?


I think it can not use anything other than mjpeg if that's the only 
codec the client supports.



I've built spice and qemu with gstreamer and drm support and VA-API is working 
nicely.
Can spice use that? How?


Possibly, for H264 you need to change the get_gst_codec_name (gstreamer 
pipe);

For vp8 it should be done already.





Unfortunately video playback is still not smoother. In fact it is about the 
same smoothness but new visual artefacts in the video make it worse. I think 
this is due to egl-headless.
For testing/comparison I installed a Windows 10 guest with the same GVT-g GPU 
and used RDP with h264 activated. Playback was much better and used only about 
120MBit/s.

Next I tried using the spice-streaming-agent in the guest to send a h264 
encoded picture via spice.
However, the windows build of remote-viewer doesn't seem to support this. The 
new spice display is created and I see the mouse cursor in it but no picture 
(just black).


You may be the first to test spice-streaming-agent + windows client.

I think there is some work to be done in the windows client to make
it handle better streams from spice-streaming-agent

Also there is some work to be done to enable spice-streaming-agent
on windows guests.


Log from the guest:
felix@idefix:~$ ./spice-streaming-agent -d
spice-streaming-agent[2465]: GOT START_STOP message -- request to START 
streaming
spice-streaming-agent[2465]: streaming starts now
spice-streaming-agent[2465]: Got device info of 1 devices from the plugin
spice-streaming-agent[2465]:    stream id 0: device address: pci//06.0, 
device display id: 2
spice-streaming-agent[2465]: got a frame -- size is 321265 (26 ms) 
(1589641660285 ms from last frame)(1589641660258136 us)
spice-streaming-agent[2465]: wXh 1920X1200  codec=1


Note that it's not H264, but MJPEG (codec=1)


You are right, so I debugged this:

Launching spice-streaming-agent with GST_DEBUG=6 shows a bunch of h264 related 
m

Re: [Spice-devel] Stuttering video playback on LAN

2020-05-17 Thread Uri Lublin

On 5/16/20 7:07 PM, Felix Leimbach wrote:

Hi Ferdiano


Hi,

I experience stuttering video playback in remote-viewer despite connecting
via GBit/s LAN, using fast hardware and the QXL driver.
Up until a video size of roughly 800x600 the playback is smooth. But on
anything bigger, like my native resolution of 2540x1440, video playback is
stuttering annoyingly.
After lots of unsuccessful tinkering with spice parameters and qxl parameters
I'm asking you guys for help.

Client:
Windows 10 1909
Remote Viewer 8.0-256
Quadcore i7-7820HQ 2.9GHz
16GB DDR4 RAM

Host of the VM:
Gentoo Linux
Kernel 4.14.172
Qemu 4.2.0


I've updated to newer versions in the meantime, but no noticeable changes.

Qemu 5.0.0
Host kernel 5.4.39
Remote Viewer 9.0-256 (x64) on the Windows 10 Client


Quadcore i7-7700K 4.2GHz
64GB DDR4 RAM
Server is headless, has no dedicated graphics card, only the Intel HD 630
from the CPU

Guest VM:
Debian Bullseye
I don't think it's guest related, because the same problem happens with a
Windows 10 Guest with latest QXL drivers and spice-tools installed.

Network performance client<=>host:
Ping 0.2ms
Throughput benchmarked at 960MBit/s






I noticed very high CPU usage in the guest during playback, because chrome, 
vlc, mpv used software h264 decoding.
I fixed this by passing a virtualized instance of the hosts Intel GPU to the 
guest via GVT-g.

These are the qemu parameters I use for GVT-g:
-spice port=5906,addr=10.42.2.250,password=changed
-vga virtio
-display egl-headless,rendernode=/dev/dri/card0
-device 
vfio-pci,sysfsdev=/sys/bus/mdev/devices/f14c80d5-9ade-4802-9509-1d877d32d159,display=on,ramfb=on,driver=vfio-pci-nohotplug


Perhaps here it would help to set streaming-video=all -spice option.



Unfortunately video playback is still not smoother. In fact it is about the 
same smoothness but new visual artefacts in the video make it worse. I think 
this is due to egl-headless.
For testing/comparison I installed a Windows 10 guest with the same GVT-g GPU 
and used RDP with h264 activated. Playback was much better and used only about 
120MBit/s.

Next I tried using the spice-streaming-agent in the guest to send a h264 
encoded picture via spice.
However, the windows build of remote-viewer doesn't seem to support this. The 
new spice display is created and I see the mouse cursor in it but no picture 
(just black).


You may be the first to test spice-streaming-agent + windows client.

I think there is some work to be done in the windows client to make
it handle better streams from spice-streaming-agent

Also there is some work to be done to enable spice-streaming-agent
on windows guests.


Log from the guest:
felix@idefix:~$ ./spice-streaming-agent -d
spice-streaming-agent[2465]: GOT START_STOP message -- request to START 
streaming
spice-streaming-agent[2465]: streaming starts now
spice-streaming-agent[2465]: Got device info of 1 devices from the plugin
spice-streaming-agent[2465]:    stream id 0: device address: pci//06.0, 
device display id: 2
spice-streaming-agent[2465]: got a frame -- size is 321265 (26 ms) 
(1589641660285 ms from last frame)(1589641660258136 us)
spice-streaming-agent[2465]: wXh 1920X1200  codec=1


Note that it's not H264, but MJPEG (codec=1)

Uri


spice-streaming-agent[2465]: got a frame -- size is 335175 (87 ms) (87 ms from 
last frame)(189 us)
spice-streaming-agent[2465]: got a frame -- size is 341098 (133 ms) (133 ms 
from last frame)(66 us)

Log from remote-viewer.exe on client (Windows):
remote-viewer.exe:1436): GSpice-WARNING **: 16:36:47.347: notify the server 
that stream 48 does not exist
(remote-viewer.exe:1436): GSpice-CRITICAL **: 16:36:47.348: 
display_handle_stream_clip: assertion 'st != NULL' failed
(remote-viewer.exe:1436): GSpice-WARNING **: 16:36:47.356: notify the server 
that stream 41 does not exist
(remote-viewer.exe:1436): GSpice-CRITICAL **: 16:36:47.357: 
display_handle_stream_clip: assertion 'st != NULL' failed
(remote-viewer.exe:1436): GSpice-WARNING **: 16:36:47.363: notify the server 
that stream 33 does not exist
(remote-viewer.exe:1436): GSpice-CRITICAL **: 16:36:47.364: 
display_handle_stream_clip: assertion 'st != NULL' failed
(remote-viewer.exe:1436): GSpice-WARNING **: 16:36:47.366: notify the server 
that stream 34 does not exist
(remote-viewer.exe:1436): GSpice-CRITICAL **: 16:36:47.367: 
display_handle_stream_clip: assertion 'st != NULL

If I use remote viewer from a linux client then it does indeed work! Playback 
is nearly smooth, about the same as with RDP and h264!
So I guess it's a bug in the windows remote-viewer. Seems like it doesn't have 
gstreamer support, so I'll open a bug report.

Any other ideas what I can try to get good reasonable video playback with good 
office-work performance?

On a side note: Audio via spice isn't working. I hear a few strange noises and 
then only silence. So I use pulseaudio transmitting the sound to the client 
independent of spice.


-spice

Re: [Spice-devel] spice-vdagent: how to enable additional mouse buttons?

2020-05-11 Thread Uri Lublin

On 5/11/20 4:47 PM, br...@netc.fr wrote:



Uri,



Would it be as simple as adding:



ioctl(uinput->fd, UI_SET_KEYBIT,  BTN_BACK);

ioctl(uinput->fd, UI_SET_KEYBIT,  BTN_FORWARD);



and re-compiling / testing?


I'm sorry, but it is not that simple.


That's the agent side.
You also need the client side, and
to add those buttons to the protocol (including client/server, possibly 
with a proper capability).


Uri.





I am not an experienced coder and have not had the time yet to get a good 
overview of the spice-vdagent code, so this might be a too simple approach.



I guess all of these values might be tested:



#define BTN_MISC        0x100
#define BTN_0            0x100
#define BTN_1            0x101
#define BTN_2            0x102
#define BTN_3            0x103
#define BTN_4            0x104
#define BTN_5            0x105
#define BTN_6            0x106
#define BTN_7            0x107
#define BTN_8            0x108
#define BTN_9            0x109

#define BTN_MOUSE        0x110
#define BTN_LEFT        0x110
#define BTN_RIGHT        0x111
#define BTN_MIDDLE        0x112
#define BTN_SIDE        0x113
#define BTN_EXTRA        0x114
#define BTN_FORWARD        0x115
#define BTN_BACK        0x116
#define BTN_TASK        0x117



Is there any way to test the btn value? Like xev is not showing me anything 
related to this value?



Your input is appreciated!



Thanks





De : Uri Lublin 
À : br...@netc.fr;
    spice-devel@lists.freedesktop.org
Sujet : Re: [Spice-devel] spice-vdagent: how to enable additional mouse buttons?
Date : 11/05/2020 15:23:30 Europe/Paris

On 5/11/20 4:08 PM, br...@netc.fr wrote:

Hi,



Yes most likely.

I find these lines of code:



/* buttons */
     ioctl(uinput->fd, UI_SET_EVBIT, EV_KEY);
     ioctl(uinput->fd, UI_SET_KEYBIT, BTN_LEFT);
     ioctl(uinput->fd, UI_SET_KEYBIT, BTN_MIDDLE);
     ioctl(uinput->fd, UI_SET_KEYBIT, BTN_RIGHT);

     /* wheel */
     ioctl(uinput->fd, UI_SET_EVBIT, EV_REL);
     ioctl(uinput->fd, UI_SET_RELBIT, REL_WHEEL);


I will probably need to declare the additional mouse buttons of my mouse 
(Logitech G403), so I run xev to find some information:



(BTN_LEFT, BTN_RIGHT, button 8, button 9)



ButtonPress event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 361327, (127,94), root:(128,144),
     state 0x0, button 1, same_screen YES

ButtonRelease event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 361426, (127,94), root:(128,144),
     state 0x100, button 1, same_screen YES

ButtonPress event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 362448, (127,94), root:(128,144),
     state 0x0, button 3, same_screen YES

ButtonRelease event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 362556, (127,94), root:(128,144),
     state 0x400, button 3, same_screen YES

ButtonPress event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 366829, (127,94), root:(128,144),
     state 0x0, button 8, same_screen YES

ButtonRelease event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 366949, (127,94), root:(128,144),
     state 0x0, button 8, same_screen YES

ButtonPress event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 368093, (127,94), root:(128,144),
     state 0x0, button 9, same_screen YES

ButtonRelease event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 368250, (127,94), root:(128,144),
     state 0x0, button 9, same_screen YES



Now the next question is obvious: how do I adjust the code to add support for 
button 8,9 ?



I thought BTN_LEFT and BTN_RIGHT would be declared in uinput.h but they are 
global variables? or where are they declared?


I found them in
/usr/include/linux/input-event-codes.h.
There is also BTN_BACK but I'm not sure it's mapped to any of button-8
or 9.

Uri.



Any help with adding support for these buttons would be very appreciated and 
finally make me stop using virtualbox lol.

Thanks!







De : Uri Lublin 
À : br...@netc.fr;
    spice-devel@lists.freedesktop.org
Sujet : Re: [Spice-devel] spice-vdagent: how to enable additional mouse buttons?
Date : 03/05/2020 17:33:55 Europe/Paris

On 5/1/20 3:51 PM, br...@netc.fr wrote:


I am using spice-vdagent on most of my qemu-kvm vm's, while this is very
convenient, mouse button 8 and 9 are not working (those are the side
buttons of the mouse, one is often used for BACK function of the
browser, which my thumb is actually addicted to).
How could i make these buttons work with spice-vdagent?


Hi,

Currently 5 mouse buttons are supported. I think some code is needed to
be added in order to support more buttons.

Uri.



Thanks for the suggestions,

Bruts










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


Re: [Spice-devel] spice-vdagent: how to enable additional mouse buttons?

2020-05-11 Thread Uri Lublin

On 5/11/20 4:08 PM, br...@netc.fr wrote:

Hi,



Yes most likely.

I find these lines of code:



/* buttons */
     ioctl(uinput->fd, UI_SET_EVBIT, EV_KEY);
     ioctl(uinput->fd, UI_SET_KEYBIT, BTN_LEFT);
     ioctl(uinput->fd, UI_SET_KEYBIT, BTN_MIDDLE);
     ioctl(uinput->fd, UI_SET_KEYBIT, BTN_RIGHT);

     /* wheel */
     ioctl(uinput->fd, UI_SET_EVBIT, EV_REL);
     ioctl(uinput->fd, UI_SET_RELBIT, REL_WHEEL);


I will probably need to declare the additional mouse buttons of my mouse 
(Logitech G403), so I run xev to find some information:



(BTN_LEFT, BTN_RIGHT, button 8, button 9)



ButtonPress event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 361327, (127,94), root:(128,144),
     state 0x0, button 1, same_screen YES

ButtonRelease event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 361426, (127,94), root:(128,144),
     state 0x100, button 1, same_screen YES

ButtonPress event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 362448, (127,94), root:(128,144),
     state 0x0, button 3, same_screen YES

ButtonRelease event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 362556, (127,94), root:(128,144),
     state 0x400, button 3, same_screen YES

ButtonPress event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 366829, (127,94), root:(128,144),
     state 0x0, button 8, same_screen YES

ButtonRelease event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 366949, (127,94), root:(128,144),
     state 0x0, button 8, same_screen YES

ButtonPress event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 368093, (127,94), root:(128,144),
     state 0x0, button 9, same_screen YES

ButtonRelease event, serial 48, synthetic NO, window 0x301,
     root 0x3ad, subw 0x0, time 368250, (127,94), root:(128,144),
     state 0x0, button 9, same_screen YES



Now the next question is obvious: how do I adjust the code to add support for 
button 8,9 ?



I thought BTN_LEFT and BTN_RIGHT would be declared in uinput.h but they are 
global variables? or where are they declared?


I found them in
/usr/include/linux/input-event-codes.h.
There is also 	BTN_BACK but I'm not sure it's mapped to any of button-8 
or 9.


Uri.



Any help with adding support for these buttons would be very appreciated and 
finally make me stop using virtualbox lol.

Thanks!







De : Uri Lublin 
À : br...@netc.fr;
    spice-devel@lists.freedesktop.org
Sujet : Re: [Spice-devel] spice-vdagent: how to enable additional mouse buttons?
Date : 03/05/2020 17:33:55 Europe/Paris

On 5/1/20 3:51 PM, br...@netc.fr wrote:


I am using spice-vdagent on most of my qemu-kvm vm's, while this is very
convenient, mouse button 8 and 9 are not working (those are the side
buttons of the mouse, one is often used for BACK function of the
browser, which my thumb is actually addicted to).
How could i make these buttons work with spice-vdagent?


Hi,

Currently 5 mouse buttons are supported. I think some code is needed to
be added in order to support more buttons.

Uri.



Thanks for the suggestions,

Bruts






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


Re: [Spice-devel] spice-vdagent: how to enable additional mouse buttons?

2020-05-03 Thread Uri Lublin

On 5/1/20 3:51 PM, br...@netc.fr wrote:


I am using spice-vdagent on most of my qemu-kvm vm's, while this is very 
convenient, mouse button 8 and 9 are not working (those are the side 
buttons of the mouse, one is often used for BACK function of the 
browser, which my thumb is actually addicted to).

How could i make these buttons work with spice-vdagent?


Hi,

Currently 5 mouse buttons are supported. I think some code is needed to 
be added in order to support more buttons.


Uri.



Thanks for the suggestions,

Bruts


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


Re: [Spice-devel] Spice-streaming-agent: is it possible to replace main display channel with agent's video stream?

2020-04-27 Thread Uri Lublin

On 4/27/20 3:24 PM, ole-kru...@yandex.ru wrote:

Hi,
I can set display=off of course. But in that case Nvidia FBC 
(FrameBuffer Capturing) is unusable. But we try to make and use a plugin 
that uses that feature. I use GRID vGPUs. xorg.conf is set to use nvidia 
card -- it's the same config that works with gst-plugin.


Hi,

Maybe try to modify some settings in FBC, such that it works with 
display=off.


Uri.



27.04.2020, 15:20, "Uri Lublin" :

On 4/27/20 11:31 AM, Oleg Krutov wrote:

  We are trying to make plugin which uses nvidia FBC + NVENC
instead of
  gst-plugin. When using FBC, I must set "display" to "on", else
FBC is
  reporting as not supported. I can't do the trick with
qxl+nvidia with
  display off as with gst-plugin. Thus, two spice windows
appear, one with
  main display channel with choppy video, and second -- with h264
  compressed captured video. There is no mouse controls in
second window,
  and first window consumes much cpu and network bandwidth when
video or
  dynamic graphics is displayed. So it would be great to stop output
  primary display and redirect agent's video stream into it. Is
it somehow
  possible? Thank you.

  --
  Отправлено из мобильного приложения Яндекс.Почты


Hi,

Why can you not set display=off ?

Did you configure your X server to use the NVIDIA GPU or the QXL ?

What NVIDIA card and driver are you using ?

Uri.



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


Re: [Spice-devel] Spice-streaming-agent: is it possible to replace main display channel with agent's video stream?

2020-04-27 Thread Uri Lublin

On 4/27/20 11:31 AM, Oleg Krutov wrote:
We are trying to make plugin which uses nvidia FBC + NVENC instead of 
gst-plugin. When using FBC, I must set "display" to "on", else FBC is 
reporting as not supported. I can't do the trick with qxl+nvidia with 
display off as with gst-plugin. Thus, two spice windows appear, one with 
main display channel with choppy video, and second -- with h264 
compressed captured video. There is no mouse controls in second window, 
and first window consumes much cpu and network bandwidth when video or 
dynamic graphics is displayed. So it would be great to stop output 
primary display and redirect agent's video stream into it. Is it somehow 
possible? Thank you.


--
Отправлено из мобильного приложения Яндекс.Почты


Hi,

Why can you not set display=off ?

Did you configure your X server to use the NVIDIA GPU or the QXL ?

What NVIDIA card and driver are you using ?

Uri.

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


Re: [Spice-devel] spice X session?

2020-04-27 Thread Uri Lublin

On 4/27/20 6:17 AM, Tomasz Chmielewski wrote:

Is it possible to configure a spice X session?

So that X session is available remotely?


Tomasz


Hi Tomasz,

There are two Spice projects that do that: x11spice and Xspice.

Uri.

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


Re: [Spice-devel] A question about USB-DK

2020-04-26 Thread Uri Lublin

On 4/13/20 7:09 AM, 1274678826 wrote:
hello!?0?2I opened the virtual machine?0?2 through the spice client, and my 
phone is connected to my computer via a data cable,I tried to redirect 
my phone to the vm through usbdk,but failed.I would like to know weather 
the usbdk support the phone redirct to the vm!

Looking forward to your reply??Thank you!


Hi,

Last time I tried phone redirect as a USB device, long time ago,  it did 
not work.


Uri.

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


Re: [Spice-devel] [PATCH x11spice] Fix compliation on gcc 4.X.

2020-03-12 Thread Uri Lublin

On 3/11/20 9:10 PM, Jeremy White wrote:

Hi,

I'm afraid that does not help on the gcc 4.8.5 on RHEL 7.X, particularly 
with structures that contain other structures.


gcc -Wall -DTHREE -o /dev/null -c test.c
test.c: In function ‘handle_sigterm’:
test.c:12:12: warning: missing braces around initializer [-Wmissing-braces]
  struct sigaction act = { 0 };


missing-braces --> it works with { {0} };

I guess when using a RHEL-7 gcc (version 4.x) there is a difference
between struct and union (or other non-simple structures).

With my test program there is no problem with RHEL-7 gcc with either {0} 
and {0,}


I see there already exists { } initialization for a struct sigaction in 
the code.


Also the code in src.c below fails to compile for me with missing-braces 
too (which may solved by {{0}}).


To summarize, I'm OK with this patch.

Uri.


     ^
test.c:12:12: warning: (near initialization for 
‘act.__sigaction_handler’) [-Wmissing-braces]


Attached is the test program.

Cheers,

Jeremy

On 3/11/20 1:27 PM, Uri Lublin wrote:

Hi,

Thanks for the ping on IRC.

On 9/17/19 7:23 PM, Jeremy White wrote:

gcc 4.x warns if you use a { 0 } initialization construct
for a structure with an initial member that is also a struct.

The { } construct is simpler and appears to work on a wider
range of gcc versions.


On my Fedora 31, gcc (version 9.2.1) does complain about {} but not 
about {0}

when built with -Wpedantic (see simple program below).


Does {0, } works better for you ?




#include 

struct S {int a, b; };

void print_s(struct S* ps)
{
 if (!ps) { printf("null\n"); return; }
 printf("(%d, %d)\n", ps->a, ps->b);
}

int main ()
{
 struct S s = { };

 print_s();
 return 0;
}




Uri.



This is a correction to fdfdf1107be100b983de1bff4beee8e6360f670b

Signed-off-by: Jeremy White 
---
  src/gui.c    | 2 +-
  src/listen.c | 2 +-
  src/main.c   | 2 +-
  src/spice.c  | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gui.c b/src/gui.c
index 88acf5c9..3c26b864 100644
--- a/src/gui.c
+++ b/src/gui.c
@@ -147,7 +147,7 @@ void session_disconnect_client(session_t *session)
  int main(int argc, char *argv[])
  {
  gui_t gui;
-    session_t session = { 0 };
+    session_t session = { };
  setlocale(LC_ALL, "");
  gui_create(, , argc, argv);
diff --git a/src/listen.c b/src/listen.c
index 452fd81f..76c0798a 100644
--- a/src/listen.c
+++ b/src/listen.c
@@ -117,7 +117,7 @@ int listen_parse(const char *listen_spec, char 
**addr, int *port_start, int *por

  static int try_port(const char *addr, int port)
  {
  static const int on = 1, off = 0;
-    struct addrinfo ai = { 0 }, *res, *e;
+    struct addrinfo ai = { }, *res, *e;
  char portbuf[33];
  int sock, rc;
diff --git a/src/main.c b/src/main.c
index 71cbb465..890ff133 100644
--- a/src/main.c
+++ b/src/main.c
@@ -55,7 +55,7 @@ int main(int argc, char *argv[])
  {
  int rc;
-    session_t session = { 0 };
+    session_t session = { };
  int display_opened = 0;
  int spice_started = 0;
diff --git a/src/spice.c b/src/spice.c
index 08a5d09a..561c85ff 100644
--- a/src/spice.c
+++ b/src/spice.c
@@ -474,7 +474,7 @@ static int send_monitors_config(spice_t *s, int 
w, int h)
  int spice_create_primary(spice_t *s, int w, int h, int 
bytes_per_line, void *shmaddr)

  {
-    QXLDevSurfaceCreate surface = { 0 };
+    QXLDevSurfaceCreate surface = { };
  surface.height = h;
  surface.width = w;







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


Re: [Spice-devel] [PATCH x11spice] Fix compliation on gcc 4.X.

2020-03-11 Thread Uri Lublin

Hi,

Thanks for the ping on IRC.

On 9/17/19 7:23 PM, Jeremy White wrote:

gcc 4.x warns if you use a { 0 } initialization construct
for a structure with an initial member that is also a struct.

The { } construct is simpler and appears to work on a wider
range of gcc versions.


On my Fedora 31, gcc (version 9.2.1) does complain about {} but not 
about {0}

when built with -Wpedantic (see simple program below).


Does {0, } works better for you ?




#include 

struct S {int a, b; };

void print_s(struct S* ps)
{
if (!ps) { printf("null\n"); return; }
printf("(%d, %d)\n", ps->a, ps->b);
}

int main ()
{
struct S s = { };

print_s();
return 0;
}




Uri.



This is a correction to fdfdf1107be100b983de1bff4beee8e6360f670b

Signed-off-by: Jeremy White 
---
  src/gui.c| 2 +-
  src/listen.c | 2 +-
  src/main.c   | 2 +-
  src/spice.c  | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gui.c b/src/gui.c
index 88acf5c9..3c26b864 100644
--- a/src/gui.c
+++ b/src/gui.c
@@ -147,7 +147,7 @@ void session_disconnect_client(session_t *session)
  int main(int argc, char *argv[])
  {
  gui_t gui;
-session_t session = { 0 };
+session_t session = { };
  
  setlocale(LC_ALL, "");

  gui_create(, , argc, argv);
diff --git a/src/listen.c b/src/listen.c
index 452fd81f..76c0798a 100644
--- a/src/listen.c
+++ b/src/listen.c
@@ -117,7 +117,7 @@ int listen_parse(const char *listen_spec, char **addr, int 
*port_start, int *por
  static int try_port(const char *addr, int port)
  {
  static const int on = 1, off = 0;
-struct addrinfo ai = { 0 }, *res, *e;
+struct addrinfo ai = { }, *res, *e;
  char portbuf[33];
  int sock, rc;
  
diff --git a/src/main.c b/src/main.c

index 71cbb465..890ff133 100644
--- a/src/main.c
+++ b/src/main.c
@@ -55,7 +55,7 @@ int main(int argc, char *argv[])
  {
  int rc;
  
-session_t session = { 0 };

+session_t session = { };
  
  int display_opened = 0;

  int spice_started = 0;
diff --git a/src/spice.c b/src/spice.c
index 08a5d09a..561c85ff 100644
--- a/src/spice.c
+++ b/src/spice.c
@@ -474,7 +474,7 @@ static int send_monitors_config(spice_t *s, int w, int h)
  
  int spice_create_primary(spice_t *s, int w, int h, int bytes_per_line, void *shmaddr)

  {
-QXLDevSurfaceCreate surface = { 0 };
+QXLDevSurfaceCreate surface = { };
  
  surface.height = h;

  surface.width = w;



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


Re: [Spice-devel] [PATCH client] channel-display: Fix wording of the deep_element_added_cb() documentation

2020-01-06 Thread Uri Lublin

On 1/3/20 6:15 PM, Francois Gouget wrote:

Signed-off-by: Francois Gouget 


Ack.

Uri.


---
  src/channel-display-gst.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 6fccf621..bd72625d 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -469,7 +469,7 @@ sink_event_probe(GstPad *pad, GstPadProbeInfo *info, 
gpointer data)
  return GST_PAD_PROBE_OK;
  }
  
-/* This function is called to used to set a probe on the sink */

+/* This function is used to set a probe on the sink */
  static void
  deep_element_added_cb(GstBin *pipeline, GstBin *bin, GstElement *element,
SpiceGstDecoder *decoder)



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


Re: [Spice-devel] [PATCH client] build: Avoid line continuation for compatibility with older Meson

2020-01-06 Thread Uri Lublin

On 1/3/20 6:15 PM, Francois Gouget wrote:

This fixes building spice-gtk on Debian 10.

Signed-off-by: Francois Gouget 


Ack.

Maybe mention the issue below in the commit log.

Uri.


---

See https://github.com/mesonbuild/meson/issues/4720

  tests/meson.build | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tests/meson.build b/tests/meson.build
index 57bd2cc5..bc5be5fd 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -23,9 +23,8 @@ endif
  
  # create a static library from a shared one extracting all objects

  # this allows to rewrite part of it if necessary for mocking
-test_lib = \
-  static_library('test-lib',
- objects : spice_client_glib_lib.extract_all_objects())
+test_lib = static_library('test-lib',
+  objects : 
spice_client_glib_lib.extract_all_objects())
  
  foreach src : tests_sources

name = 'test-@0@'.format(src).split('.')[0]



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


Re: [Spice-devel] cannot drag file from guest to client.

2020-01-01 Thread Uri Lublin

On 12/27/19 4:49 AM, franklin zhou wrote:
I tried drag file from guest to client, but it cannot success, only drag 
file from client to guest is ok. is it a bug or need some setting?



It (file-transfer, currently) only works from client to guest.






client:  window10, ubuntu18.04

guest: windows10, windows7, ubuntu18.04




___
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] after enable streaming agent , but the mouse does not work in spice-gtk streaming window

2020-01-01 Thread Uri Lublin

On 12/19/19 5:49 AM, franklin zhou wrote:

hi, all,


Hi,



I try streaming agent, after enable,

when start spicy at client side, it will popup two windows, one is 
origin,  the other one is for guest streaming agent,


the origin window mouse is ok, but at the other one (for streaming 
agent) mouse not work,

Is this a bug?


What graphic cards does the VM have ?

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


Re: [Spice-devel] [qxl-xddm] xddm: add Wix script for driver installation

2019-12-04 Thread Uri Lublin

On 11/22/19 9:06 AM, Yuri Benditovich wrote:

Signed-off-by: Yuri Benditovich 


This is very similar to wddm-dod one.

I did not test it.

Looks good to me.

Ack.

Thanks,
Uri.



---
  xddm/QXLInstaller.wxs | 88 +++
  1 file changed, 88 insertions(+)
  create mode 100644 xddm/QXLInstaller.wxs

diff --git a/xddm/QXLInstaller.wxs b/xddm/QXLInstaller.wxs
new file mode 100644
index 000..664b3ed
--- /dev/null
+++ b/xddm/QXLInstaller.wxs
@@ -0,0 +1,88 @@
+
+http://schemas.microsoft.com/wix/2006/wi;
+ xmlns:difx="http://schemas.microsoft.com/wix/DifxAppExtension;>
+
+  
+
+
+
+  
+
+
+
+  
+
+  
+
+
+
+  
+  
+  
+
+
+
+  
+
+
+
+
+
+
+  
+
+  
+
+
+
+  
+
+  
+
+
+  
+  
+  
+  
+  
+
+
+  
+
+  
+
+
+
+
+
+
+  PREVIOUSVERSIONSINSTALLED""
+  NEWERVERSIONINSTALLED"" AND NOT Installed
+
+
+
+  
+
+
+  
+



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

Re: [Spice-devel] [qxl-wddm-dod] add Wix script for driver installation

2019-12-04 Thread Uri Lublin

Hi Yuri,

I quickly tested install, uninstall, and upgrade. Works well for me.

Some minor questions:
- I see UsbDK does not use difx. Is it easier to use difx ?
- Do people run Windows 10 x86 (32 bit)? Do we need such a driver ?

Ack.

Thanks,
Uri.

On 11/22/19 8:39 AM, Yuri Benditovich wrote:

Signed-off-by: Yuri Benditovich 
---
  QXLWDDMDODInstaller.wxs | 94 +
  1 file changed, 94 insertions(+)
  create mode 100644 QXLWDDMDODInstaller.wxs

diff --git a/QXLWDDMDODInstaller.wxs b/QXLWDDMDODInstaller.wxs
new file mode 100644
index 000..64145cc
--- /dev/null
+++ b/QXLWDDMDODInstaller.wxs
@@ -0,0 +1,94 @@
+
+http://schemas.microsoft.com/wix/2006/wi;
+ xmlns:difx="http://schemas.microsoft.com/wix/DifxAppExtension;>
+
+  
+
+
+
+  
+
+
+
+  
+
+  
+
+
+
+  
+
+  
+
+
+
+  
+  
+  
+
+
+
+  
+
+
+
+
+
+
+  
+
+  
+
+
+
+  
+
+  
+
+
+
+
+
+
+
+
+
+  
+
+  
+
+
+
+
+
+
+  PREVIOUSVERSIONSINSTALLED""
+  NEWERVERSIONINSTALLED"" AND NOT Installed
+
+
+
+  
+
+
+  
+



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

Re: [Spice-devel] regression from 0.14.0 -> 0.14.2 in screen resizing

2019-11-10 Thread Uri Lublin

On 11/3/19 3:17 PM, Uri Lublin wrote:

On 11/3/19 2:42 PM, Jason A. Donenfeld wrote:

On Sun, Nov 3, 2019, 20:23 Uri Lublin  wrote:



I'll try Windows 10 later (couple of days).


I tried changing the resolution of a Windows 10 VM from within the 
guest.

Indeed, remote-viewer fails to change the resolution of the window on
v0.14.2 but works fine on v0.14.0.
I also noticed that it works fine on the git master branch.



Cool, so presumably already fixed for 0.14.3 then? Any idea what commit
caused the regression and what fixed it?



I plan to git bisect and report.


The commit that fixes the issue is .

red-qxl: Make sure we have at least one monitor
4f2d90a7849fafebc74dec608f9b4ffa9400d1a6


Uri.

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

Re: [Spice-devel] [spice v1 8/8] tests: migrate: add seamless-migration option

2019-10-30 Thread Uri Lublin

On 10/7/19 3:19 PM, Victor Toso wrote:

From: Victor Toso 

Now we always add seamless-migration option to qemu command line and
disabled (off) by default although seamless migration is supported for
over 7 years already!


If it's not a seemless migration the client disconnects.

I think you should further modify the script if you want to test this case.

Uri.



Signed-off-by: Victor Toso 
---
  tests/migrate.py | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tests/migrate.py b/tests/migrate.py
index a9a2c1cb..3dcbc9f1 100755
--- a/tests/migrate.py
+++ b/tests/migrate.py
@@ -69,6 +69,8 @@ def get_args():
  help="Wait spice client to connect to move to next step of 
migration (default False)")
  parser.add_argument('--count', dest='counter', type=int, default=100,
  help="Number of migrations to run (set 0 for 
infinite)")
+parser.add_argument('--seamless-migration', dest="seamless_migration", 
action='store_true', default=False,
+help="Enable seamless-migration support")
  args = parser.parse_args(sys.argv[1:])
  if os.path.exists(args.qemu):
  args.qemu_exec = args.qemu
@@ -79,11 +81,12 @@ def get_args():
  sys.exit(1)
  return args
  
-def start_qemu(qemu_exec, image, spice_port, qmp_filename, incoming_port=None, with_agent=False):

+def start_qemu(qemu_exec, seamless_migration, image, spice_port, qmp_filename, 
incoming_port=None, with_agent=False):
+seamless_option = "on" if seamless_migration else "off"
  args = [
  qemu_exec,
  "-qmp", "unix:%s,server,nowait" % qmp_filename,
-"-spice", "disable-ticketing,port=%s" % spice_port
+"-spice", "seamless-migration=%s,disable-ticketing,port=%s" % 
(seamless_option, spice_port)
  ]
  if incoming_port:
  args += ("-incoming tcp::%s" % incoming_port).split()
@@ -153,7 +156,7 @@ class Migrator(object):
  migration_count = 0
  
  def __init__(self, log, client, qemu_exec, image, monitor_files,

- spice_ports, migration_port, vdagent, hostname):
+ spice_ports, migration_port, vdagent, hostname, 
seamless_migration):
  self.client = client if client != "none" else None
  self.log = log
  self.qemu_exec = qemu_exec
@@ -163,16 +166,19 @@ class Migrator(object):
  self.spice_ports = spice_ports
  self.vdagent = vdagent
  self.hostname = hostname
+self.seamless_migration = seamless_migration
  
  self.active = start_qemu(qemu_exec = qemu_exec,

   image = image,
   spice_port = spice_ports[0],
   qmp_filename = monitor_files[0],
+ seamless_migration = self.seamless_migration,
   with_agent = self.vdagent)
  self.target = start_qemu(qemu_exec = qemu_exec,
   image = image,
   spice_port = spice_ports[1],
   qmp_filename = monitor_files[1],
+ seamless_migration = self.seamless_migration,
   with_agent = self.vdagent,
   incoming_port = migration_port)
  self.remove_monitor_files()
@@ -235,6 +241,7 @@ class Migrator(object):
  del dead
  self.active = self.target
  self.target = start_qemu(spice_port = new_spice_port,
+ seamless_migration = self.seamless_migration,
   qemu_exec = self.qemu_exec,
   image = self.image,
   qmp_filename = new_qmp_filename,
@@ -256,6 +263,7 @@ def main():
  migration_port = args.migrate_port,
  spice_ports = [args.spice_port1, args.spice_port2],
  vdagent = args.vdagent,
+seamless_migration = args.seamless_migration,
  hostname = args.hostname)
  atexit.register(cleanup, migrator)
  counter = 0



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

Re: [Spice-devel] [spice v1 6/8] tests: migrate: add option for hostname change

2019-10-30 Thread Uri Lublin

Hi Victor,

On 10/7/19 3:19 PM, Victor Toso wrote:

From: Victor Toso 

This is used in the migrate message and being able to tweak it allows
clients from different machines to test this local migration test.

Example of usage:
 ./migrate.py --hostname 192.168.122.1 --wait-user-connect

In a VM with access to 192.168.122.1:
 remote-viewer spice://192.168.122.1:5911

Signed-off-by: Victor Toso 
---
  tests/migrate.py | 23 ++-
  1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/tests/migrate.py b/tests/migrate.py
index 742c9fab..2f8b3fbb 100755
--- a/tests/migrate.py
+++ b/tests/migrate.py
@@ -20,7 +20,7 @@ Will leave a log file, migrate_test.log, in current directory.
  # and repeat:
  #  active wait until it's active
  #  active client_migrate_info
-#  active migrate tcp:localhost:9000
+#  active migrate tcp:$hostname:9000


I think the migrate command itself can keep the "localhost"
(Not too important, but shows that the migration itself is on a single 
host.)

See also below for the same


  #  _wait for event of quit
  #  active stop, active<->passive
  #
@@ -57,6 +57,8 @@ def get_args():
  parser.add_argument('--qemu', dest='qemu', 
default='../../qemu/x86_64-softmmu/qemu-system-x86_64')
  parser.add_argument('--log_filename', dest='log_filename', 
default='migrate.log')
  parser.add_argument('--image', dest='image', default='')
+parser.add_argument("--hostname", dest='hostname', default='localhost',
+help="Set hostname used in migration message (default: 
localhost")


This is to be used together with --wait-user-connect, right ?
Consider adding a check for it (can be a separate patch).


  parser.add_argument('--client', dest='client', default='none', 
choices=['spicy', 'remote-viewer', 'none'],
  help="Automatically lunch one of supported clients or none 
(default)")
  parser.add_argument('--vdagent', dest="vdagent", action='store_true', 
default=False,
@@ -115,10 +117,10 @@ def start_qemu(qemu_exec, image, spice_port, 
qmp_filename, incoming_port=None, w
  proc.incoming_port = incoming_port
  return proc
  
-def start_client(client, spice_port):

-client_cmd = "spicy --uri spice://localhost:%s" % (spice_port)
+def start_client(client, hostname, spice_port):
+client_cmd = "spicy --uri spice://%s:%s" % (hostname, spice_port)
  if client == "remote-viewer":
-client_cmd = "remote-viewer spice://localhost:%s" % (spice_port)
+client_cmd = "remote-viewer spice://%s:%s" % (hostname, spice_port)


If the script starts it, then both server and client are on the same 
(localhost) machine.


  
  return Popen(client_cmd.split(), executable=client)
  
@@ -151,7 +153,7 @@ class Migrator(object):

  migration_count = 0
  
  def __init__(self, log, client, qemu_exec, image, monitor_files,

- spice_ports, migration_port, vdagent):
+ spice_ports, migration_port, vdagent, hostname):
  self.client = client if client != "none" else None
  self.log = log
  self.qemu_exec = qemu_exec
@@ -160,6 +162,7 @@ class Migrator(object):
  self.monitor_files = monitor_files
  self.spice_ports = spice_ports
  self.vdagent = vdagent
+self.hostname = hostname
  
  self.active = start_qemu(qemu_exec=qemu_exec, image=image, spice_port=spice_ports[0],

   qmp_filename=monitor_files[0], 
with_agent=self.vdagent)
@@ -189,7 +192,9 @@ class Migrator(object):
  wait_active(self.target.qmp, False)
  if not self.connected_client:
  if self.client:
-self.connected_client = start_client(client=self.client, 
spice_port=self.spice_ports[0])
+self.connected_client = start_client(client = self.client,
+ hostname = self.hostname,
+ spice_port = 
self.spice_ports[0])
  
  if wait_for_user_input:

  print "waiting for Enter to start migrations"
@@ -201,11 +206,11 @@ class Migrator(object):
  
  self.active.qmp.cmd('client_migrate_info', {

  'protocol' : 'spice',
-'hostname' : 'localhost',
+'hostname' : self.hostname,


I think this is the important code.


  'port' : self.target.spice_port
  })
  self.active.qmp.cmd('migrate', {
-'uri': 'tcp:localhost:%s' % self.migration_port
+'uri': 'tcp:%s:%s' % (self.hostname, 
self.migration_port)


Here, it can be left 'localhost'


Uri.


  })
  wait_active(self.active.qmp, False)
  wait_active(self.target.qmp, True)
@@ -239,7 +244,7 @@ def main():
  migrator 

Re: [Spice-devel] [spice/tests/migrate v1 2/4] tests: migrate: wait user launch client option

2019-10-11 Thread Uri Lublin

On 10/7/19 11:10 AM, Victor Toso wrote:

Hi,

On Sun, Oct 06, 2019 at 10:49:13AM +0300, Uri Lublin wrote:

On 10/4/19 11:37 AM, Victor Toso > On Thu, Oct 03, 2019 at 05:13:46PM +0300,
Uri Lublin wrote:>> On 10/3/19 1:14 PM, Victor Toso wrote:>>> From: Victor
Toso >>>>>> Useful to test different clients running
different tools (gdb,>>> valgrind).>>>>>> Signed-off-by: Victor Toso
>>> --->>>tests/migrate.py | 13 +>>>
1 file changed, 9 insertions(+), 4 deletions(-)>>>>>> diff --git
a/tests/migrate.py b/tests/migrate.py>>> index 5ed9eba4..88e17691 100755>>>
--- a/tests/migrate.py>>> +++ b/tests/migrate.py>>> @@ -63,6 +63,8 @@ def
get_args():>>>  help="Append options for agent's
virtserialport")>>>  parser.add_argument('--wait-user-input',
dest="wait_user_input", action='store_true', default=False,>>> help="Wait
user's input to start migration test")>>> +
parser.add_argument('--wait-user-connect', dest="wait_user_connect",
action='store_true', default=False,>>> + help="Wait spice client to connect
to move to next step of migration (default False)")>>>> Consider adding a
check for both --wait-user-connect and --client=non-none>> (which I expect
will break something)

Not really, runs fine here (assuming you mean a valid client such
as spicy or remote-viewer)


I do mean with e.g. remote-viewer.

The problem is that there are two clients in this scenario:
  1. the one that is started by the script (--client)
  2. the one that is started by the user ( --wait-user-connect )


Not sure where is the problem? If you mean issues in the client
itself, reproducing them easily is the reason I started to poke
with this migrate.py! I'm trying to address them now.


Hi,

The problem I think may exist is that there can only be 1 client,
but the command line suggests there are two.
Don't worry about it. I can send a followup/fixup patch.

Thanks,
Uri.



Just to be 100% clear, I'm fine in having specific client
launched (1) for automated testing scenarios, so you don't need
to run a client by yourself; I'm happy in having (2) for
debugging and also to play with different clients.

Thanks for the comments and reviews!
Victor


Uri.



With --wait-user-connect it launches but migration only starts
after connection is established. Also tried with
--wait-user-input and client connects but no migration happens
till some keystroke on console.




Thanks for the reviews!
Victor


Uri.


parser.add_argument('--count', dest='counter', type=int, default=100,
help="Number of migrations to run (set 0 for 
infinite)")
args = parser.parse_args(sys.argv[1:])
@@ -174,25 +176,28 @@ class Migrator(object):
if os.path.exists(x):
os.unlink(x)
-def iterate(self, wait_for_user_input=False):
+def iterate(self, wait_for_user_input=False, wait_user_connect=False):
wait_active(self.active.qmp, True)
wait_active(self.target.qmp, False)
if not self.connected_client:
if self.client:
self.connected_client = start_client(client=self.client, 
spice_port=self.spice_ports[0])
-wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
if wait_for_user_input:
print "waiting for Enter to start migrations"
raw_input()
+# Tester can launch its own client or we wait start_client() to connect
+if wait_user_connect:
+wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
+
self.active.qmp.cmd('client_migrate_info', {'protocol':'spice',
'hostname':'localhost', 'port':self.target.spice_port})
self.active.qmp.cmd('migrate', {'uri': 'tcp:localhost:%s' % 
self.migration_port})
wait_active(self.active.qmp, False)
wait_active(self.target.qmp, True)
-if self.connected_client:
+if self.connected_client or wait_user_connect:
wait_for_event(self.target.qmp, 'SPICE_CONNECTED')
dead = self.active
@@ -224,7 +229,7 @@ def main():
atexit.register(cleanup, migrator)
counter = 0
while args.counter == 0 or counter < args.counter:
-migrator.iterate(args.wait_user_input)
+migrator.iterate(args.wait_user_input, args.wait_user_connect)
counter += 1
if __name__ == '__main__':







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

Re: [Spice-devel] [spice/tests/migrate v1 2/4] tests: migrate: wait user launch client option

2019-10-06 Thread Uri Lublin
On 10/4/19 11:37 AM, Victor Toso > On Thu, Oct 03, 2019 at 05:13:46PM 
+0300, Uri Lublin wrote:>> On 10/3/19 1:14 PM, Victor Toso wrote:>>> 
From: Victor Toso >>>>>> Useful to test different 
clients running different tools (gdb,>>> valgrind).>>>>>> Signed-off-by: 
Victor Toso >>> --->>>tests/migrate.py | 13 
+>>>1 file changed, 9 insertions(+), 4 
deletions(-)>>>>>> diff --git a/tests/migrate.py b/tests/migrate.py>>> 
index 5ed9eba4..88e17691 100755>>> --- a/tests/migrate.py>>> +++ 
b/tests/migrate.py>>> @@ -63,6 +63,8 @@ def get_args():>>> 
 help="Append options for agent's virtserialport")>>> 
 parser.add_argument('--wait-user-input', dest="wait_user_input", 
action='store_true', default=False,>>> 
help="Wait user's input to start migration test")>>> + 
parser.add_argument('--wait-user-connect', dest="wait_user_connect", 
action='store_true', default=False,>>> + 
help="Wait spice client to connect to move to next step of migration 
(default False)")>>>> Consider adding a check for both 
--wait-user-connect and --client=non-none>> (which I expect will break 
something)

Not really, runs fine here (assuming you mean a valid client such
as spicy or remote-viewer)


I do mean with e.g. remote-viewer.

The problem is that there are two clients in this scenario:
 1. the one that is started by the script (--client)
 2. the one that is started by the user ( --wait-user-connect )

Uri.



With --wait-user-connect it launches but migration only starts
after connection is established. Also tried with
--wait-user-input and client connects but no migration happens
till some keystroke on console.




Thanks for the reviews!
Victor


Uri.


   parser.add_argument('--count', dest='counter', type=int, default=100,
   help="Number of migrations to run (set 0 for 
infinite)")
   args = parser.parse_args(sys.argv[1:])
@@ -174,25 +176,28 @@ class Migrator(object):
   if os.path.exists(x):
   os.unlink(x)
-def iterate(self, wait_for_user_input=False):
+def iterate(self, wait_for_user_input=False, wait_user_connect=False):
   wait_active(self.active.qmp, True)
   wait_active(self.target.qmp, False)
   if not self.connected_client:
   if self.client:
   self.connected_client = start_client(client=self.client, 
spice_port=self.spice_ports[0])
-wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
   if wait_for_user_input:
   print "waiting for Enter to start migrations"
   raw_input()
+# Tester can launch its own client or we wait start_client() to connect
+if wait_user_connect:
+wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
+
   self.active.qmp.cmd('client_migrate_info', {'protocol':'spice',
   'hostname':'localhost', 'port':self.target.spice_port})
   self.active.qmp.cmd('migrate', {'uri': 'tcp:localhost:%s' % 
self.migration_port})
   wait_active(self.active.qmp, False)
   wait_active(self.target.qmp, True)
-if self.connected_client:
+if self.connected_client or wait_user_connect:
   wait_for_event(self.target.qmp, 'SPICE_CONNECTED')
   dead = self.active
@@ -224,7 +229,7 @@ def main():
   atexit.register(cleanup, migrator)
   counter = 0
   while args.counter == 0 or counter < args.counter:
-migrator.iterate(args.wait_user_input)
+migrator.iterate(args.wait_user_input, args.wait_user_connect)
   counter += 1
   if __name__ == '__main__':





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

Re: [Spice-devel] regression from 0.14.0 -> 0.14.2 in screen resizing

2019-10-03 Thread Uri Lublin

On 10/3/19 7:52 PM, Jason A. Donenfeld wrote:

On Thu, Oct 3, 2019 at 6:52 PM Uri Lublin  wrote:



It works for me also with spice v0.14.2 (from git) and current master.

The qemu version is 4.1.50 (from git) and also tested QEMU 3.1.1 (Fedora
30).

BTW, what distro is it ?  Which Windows guest ?


Gentoo. Windows 10.


I'll try Windows 10 later (couple of days).
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] regression from 0.14.0 -> 0.14.2 in screen resizing

2019-10-03 Thread Uri Lublin

On 10/3/19 6:11 PM, Jason A. Donenfeld wrote:

On Thu, Oct 3, 2019 at 5:10 PM Uri Lublin  wrote:


Hi,

I just tested v0.14.0 and resolution change works for me (Windows 7 x64,
remote-viewer).


This is why I specified that it fails in 0.14.2.


Indeed.

It works for me also with spice v0.14.2 (from git) and current master.

The qemu version is 4.1.50 (from git) and also tested QEMU 3.1.1 (Fedora 
30).


BTW, what distro is it ?  Which Windows guest ?

Uri.




What driver is installed on the guest ?

The usual ones from the spice website.


Is spice-vdagent service running ?

Yes.


If you change resolution from within the guest does that work
(Control Panel -> Display -> Adjust Resolution,
   or simply right-click on the desktop -> Screen resolution)?

Weird behavior as described.

Jason



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

Re: [Spice-devel] regression from 0.14.0 -> 0.14.2 in screen resizing

2019-10-03 Thread Uri Lublin

On 9/27/19 1:27 PM, Jason A. Donenfeld wrote:

Hi,

My distro upgraded spice from 0.14.0 to 0.14.2. This has caused screen
resizing geometry problems for my Windows guest.

In spicy, I experience a massive black border around the screen, as
though it's getting the internal coordinates and external coordinates
out of sync. This seems to go away in lo-dpi mode.

In remote-viewer, I experience only ~square screen resolutions and big
performance regressions.

Reverting to 0.14.0 (and rebuilding qemu to use it) makes things work
again, with all guest screen resolutions being possible and resizing
working well.

Please let me know if you require additional information or would like
me to try with some commits reverted.


Hi,

I just tested v0.14.0 and resolution change works for me (Windows 7 x64, 
remote-viewer).


What driver is installed on the guest ?
Is spice-vdagent service running ?

If you change resolution from within the guest does that work
(Control Panel -> Display -> Adjust Resolution,
 or simply right-click on the desktop -> Screen resolution)?

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

Re: [Spice-devel] [spice/tests/migrate v1 2/4] tests: migrate: wait user launch client option

2019-10-03 Thread Uri Lublin

On 10/3/19 1:14 PM, Victor Toso wrote:

From: Victor Toso 

Useful to test different clients running different tools (gdb,
valgrind).

Signed-off-by: Victor Toso 
---
  tests/migrate.py | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/tests/migrate.py b/tests/migrate.py
index 5ed9eba4..88e17691 100755
--- a/tests/migrate.py
+++ b/tests/migrate.py
@@ -63,6 +63,8 @@ def get_args():
  help="Append options for agent's virtserialport")
  parser.add_argument('--wait-user-input', dest="wait_user_input", 
action='store_true', default=False,
  help="Wait user's input to start migration test")
+parser.add_argument('--wait-user-connect', dest="wait_user_connect", 
action='store_true', default=False,
+help="Wait spice client to connect to move to next step of 
migration (default False)")


Consider adding a check for both  --wait-user-connect and --client=non-none
(which I expect will break something)

Uri.


  parser.add_argument('--count', dest='counter', type=int, default=100,
  help="Number of migrations to run (set 0 for 
infinite)")
  args = parser.parse_args(sys.argv[1:])
@@ -174,25 +176,28 @@ class Migrator(object):
  if os.path.exists(x):
  os.unlink(x)
  
-def iterate(self, wait_for_user_input=False):

+def iterate(self, wait_for_user_input=False, wait_user_connect=False):
  wait_active(self.active.qmp, True)
  wait_active(self.target.qmp, False)
  if not self.connected_client:
  if self.client:
  self.connected_client = start_client(client=self.client, 
spice_port=self.spice_ports[0])
-wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
  
  if wait_for_user_input:

  print "waiting for Enter to start migrations"
  raw_input()
  
+# Tester can launch its own client or we wait start_client() to connect

+if wait_user_connect:
+wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
+
  self.active.qmp.cmd('client_migrate_info', {'protocol':'spice',
  'hostname':'localhost', 'port':self.target.spice_port})
  self.active.qmp.cmd('migrate', {'uri': 'tcp:localhost:%s' % 
self.migration_port})
  wait_active(self.active.qmp, False)
  wait_active(self.target.qmp, True)
  
-if self.connected_client:

+if self.connected_client or wait_user_connect:
  wait_for_event(self.target.qmp, 'SPICE_CONNECTED')
  
  dead = self.active

@@ -224,7 +229,7 @@ def main():
  atexit.register(cleanup, migrator)
  counter = 0
  while args.counter == 0 or counter < args.counter:
-migrator.iterate(args.wait_user_input)
+migrator.iterate(args.wait_user_input, args.wait_user_connect)
  counter += 1
  
  if __name__ == '__main__':




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

[Spice-devel] [spice-streaming-agent PATCH v2 0/3] Get ready for v0.3 release

2019-10-03 Thread Uri Lublin
v1 -> v2:
 - More information in gitignore patch commit log (Frediano)
 - Dropped a .spec patch adding BuildRequires autoconf (Frediano)

Uri Lublin (3):
  gitignore: ignore tar.xz
  Add a man page
  Prepare for v0.3 release

 .gitignore|  1 +
 Makefile.am   |  2 +
 NEWS  | 17 
 configure.ac  |  2 +-
 spice-streaming-agent.1   | 78 +++
 spice-streaming-agent.spec.in |  4 ++
 6 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100644 spice-streaming-agent.1

-- 
2.21.0

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

[Spice-devel] [spice-streaming-agent PATCH v2 1/3] gitignore: ignore tar.xz

2019-10-03 Thread Uri Lublin
"make dist" generates it (dist-xz is specified in configure.ac)

Signed-off-by: Uri Lublin 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 601cc9f..29d4a92 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,6 +4,7 @@
 *.lo
 *.tar.bz2
 *.tar.gz
+*.tar.xz
 .*.sw?
 .deps
 .dirstamp
-- 
2.21.0

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

[Spice-devel] [spice-streaming-agent PATCH v2 2/3] Add a man page

2019-10-03 Thread Uri Lublin
Signed-off-by: Uri Lublin 
Acked-by: Frediano Ziglio 
---
 Makefile.am   |  2 +
 spice-streaming-agent.1   | 78 +++
 spice-streaming-agent.spec.in |  1 +
 3 files changed, 81 insertions(+)
 create mode 100644 spice-streaming-agent.1

diff --git a/Makefile.am b/Makefile.am
index 99c1308..e57839d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -25,3 +25,5 @@ EXTRA_DIST = \
data/90-spice-guest-streaming.rules \
data/spice-streaming.desktop \
$(NULL)
+
+dist_man_MANS = spice-streaming-agent.1
diff --git a/spice-streaming-agent.1 b/spice-streaming-agent.1
new file mode 100644
index 000..81926fc
--- /dev/null
+++ b/spice-streaming-agent.1
@@ -0,0 +1,78 @@
+.TH SPICE-STREAMING-AGENT 1
+.SH NAME
+spice-streaming-agent \- An agent, running on a guest, sending video
+stream of X display to a remote client (over SPICE)
+
+.SH SYNOPSIS
+.B spice-streaming-agent [  ]
+
+.SH DESCRIPTION
+.B spice-streaming-agent
+is an agent, running on a guest, sending video stream of X display to
+a remote client (over SPICE)
+
+The video stream itself depends on plugins/codecs installed on the guest
+(and the client).
+
+Currently only supports X display (Xorg/X11).
+
+Requires a virtio-port device to communicate and a recent enough
+spice-server.
+
+.B spice-streaming-agent
+should start automatically with your X session.
+
+.\" ToDo: add qemu-kvm command line option example
+.\"   or refer to README file
+
+.SH OPTIONS
+.TP
+.BR \-p " " \fIportname\fR
+The virtio-serial port to use
+(default is /dev/virtio-ports/org.spice-space.stream.0)
+.TP
+.BR \-l " " \fIfile\fR
+log frames to file
+
+.TP
+.BR \-\-log-binary
+log binary frames (following -l)
+
+.TP
+.BR \-\-log-categories
+log categories, separated by ':' (currently: frames)
+
+.TP
+.BR \-\-plugins-dir " " path
+change plugins directory
+
+.TP
+.BR \-d
+enable debug logs
+
+.TP
+.BR \-c  " " \fIvariable=value\fR
+A generic way to change plugins/codecs settings.
+This only affects plugins that support this variable
+and this value (and ignored otherwise).
+
+.TP
+.BR \-c  " " \fIframerate=1-100\fR
+
+.\" ToDo: more -c options related to plugins
+
+.SH EXAMPLES
+.TP
+run spice-streaming-agent with a framerate of 20 frames per second
+spice-streaming-agent -c framerate=20
+
+.TP
+run and log binary frames to /tmp/ssa.log
+spice-streaming-agent -l /tmp/ssa.log --log-binary
+
+.TP
+run and print a lot of debug information
+spice-streaming-agent -d
+
+.SH SEE ALSO
+qemu-kvm(1)
diff --git a/spice-streaming-agent.spec.in b/spice-streaming-agent.spec.in
index 299ea02..9ca6dc6 100644
--- a/spice-streaming-agent.spec.in
+++ b/spice-streaming-agent.spec.in
@@ -65,6 +65,7 @@ fi
 %{_bindir}/spice-streaming-agent
 %{_sysconfdir}/xdg/autostart/spice-streaming.desktop
 %{_datadir}/gdm/greeter/autostart/spice-streaming.desktop
+%{_mandir}/man1/spice-streaming-agent.1.gz
 
 %files devel
 %defattr(-,root,root,-)
-- 
2.21.0

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

[Spice-devel] [spice-streaming-agent PATCH v2 3/3] Prepare for v0.3 release

2019-10-03 Thread Uri Lublin
1. update NEWS
2. update configure.ac
3. update spec file

Signed-off-by: Uri Lublin 
Acked-by: Frediano Ziglio 
---
 NEWS  | 17 +
 configure.ac  |  2 +-
 spice-streaming-agent.spec.in |  3 +++
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index aedf07a..2bd6b18 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,20 @@
+Major changes in 0.3:
+=
+- Improve the invalid option argument (-c) error message
+- Improve the frame log messages
+- Make the try-catch block in main() a catch-all
+- Set default syslog mask to a lower level
+- Fix some clang build errors
+- Adding gstreamer based plugin
+- Make error.hpp and the Error class a public API
+- Export symbols in the binary to be used by plugins
+- Interface + implementation of getting device display info
+- Send the GraphicsDeviceInfo to the server
+- Add support for logging statistics from plugins
+- Enable building with GCC 9
+- Add a man page
+
+
 Major changes in 0.2:
 =
 - First release
diff --git a/configure.ac b/configure.ac
index 1c7788b..bab1cc7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,6 +1,6 @@
 AC_PREREQ([2.57])
 
-AC_INIT(spice-streaming-agent, 0.2,
+AC_INIT(spice-streaming-agent, 0.3,
 [spice-devel@lists.freedesktop.org])
 
 AM_CONFIG_HEADER([config.h])
diff --git a/spice-streaming-agent.spec.in b/spice-streaming-agent.spec.in
index 9ca6dc6..13cef13 100644
--- a/spice-streaming-agent.spec.in
+++ b/spice-streaming-agent.spec.in
@@ -73,6 +73,9 @@ fi
 %{_libdir}/pkgconfig
 
 %changelog
+* Thu Sep 19 2019 Uri Lublin  - 0.3-1
+- Update to 0.3 release
+
 * Thu May 31 2018 Uri Lublin  - 0.2-1
 - First release
 
-- 
2.21.0

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

Re: [Spice-devel] [spice/tests/migrate v1 2/4] tests: migrate: wait user launch client option

2019-10-03 Thread Uri Lublin

On 10/3/19 3:47 PM, Victor Toso wrote:

On Thu, Oct 03, 2019 at 03:34:50PM +0300, Uri Lublin wrote:

On 10/3/19 1:14 PM, Victor Toso wrote:

From: Victor Toso 

Useful to test different clients running different tools (gdb,
valgrind).


It seems to me it's already solved by --wait-user-input.
The user can start the migration only after running the tool/client.


They are similar but with wait-user-input you can do the wait
without having to launch your own client, that is, it is good to
test the host side migration. Also, both of them should work well
together, that is:

./migrate.py --wait-user-connect --wait-user-input

By default, test does not launch the client so it will wait we
connect remote-viewer, than after connected it waits for user
input to start migration.


Since with wait-user-input the script waits for the user
to manually start the migrations, it can wait for the user to
start run own client/tool.

Thinking about it some more, it may be a good option if you want to run
the script (and client/tool) automatically, without user intervention.



Signed-off-by: Victor Toso 


OK,

Uri.



---
   tests/migrate.py | 13 +
   1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/tests/migrate.py b/tests/migrate.py
index 5ed9eba4..88e17691 100755
--- a/tests/migrate.py
+++ b/tests/migrate.py
@@ -63,6 +63,8 @@ def get_args():
   help="Append options for agent's virtserialport")
   parser.add_argument('--wait-user-input', dest="wait_user_input", 
action='store_true', default=False,
   help="Wait user's input to start migration test")
+parser.add_argument('--wait-user-connect', dest="wait_user_connect", 
action='store_true', default=False,
+help="Wait spice client to connect to move to next step of 
migration (default False)")
   parser.add_argument('--count', dest='counter', type=int, default=100,
   help="Number of migrations to run (set 0 for 
infinite)")
   args = parser.parse_args(sys.argv[1:])
@@ -174,25 +176,28 @@ class Migrator(object):
   if os.path.exists(x):
   os.unlink(x)
-def iterate(self, wait_for_user_input=False):
+def iterate(self, wait_for_user_input=False, wait_user_connect=False):
   wait_active(self.active.qmp, True)
   wait_active(self.target.qmp, False)
   if not self.connected_client:
   if self.client:
   self.connected_client = start_client(client=self.client, 
spice_port=self.spice_ports[0])
-wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
   if wait_for_user_input:
   print "waiting for Enter to start migrations"
   raw_input()
+# Tester can launch its own client or we wait start_client() to connect
+if wait_user_connect:
+wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
+
   self.active.qmp.cmd('client_migrate_info', {'protocol':'spice',
   'hostname':'localhost', 'port':self.target.spice_port})
   self.active.qmp.cmd('migrate', {'uri': 'tcp:localhost:%s' % 
self.migration_port})
   wait_active(self.active.qmp, False)
   wait_active(self.target.qmp, True)
-if self.connected_client:
+if self.connected_client or wait_user_connect:
   wait_for_event(self.target.qmp, 'SPICE_CONNECTED')
   dead = self.active
@@ -224,7 +229,7 @@ def main():
   atexit.register(cleanup, migrator)
   counter = 0
   while args.counter == 0 or counter < args.counter:
-migrator.iterate(args.wait_user_input)
+migrator.iterate(args.wait_user_input, args.wait_user_connect)
   counter += 1
   if __name__ == '__main__':





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

Re: [Spice-devel] [spice/tests/migrate v1 4/4] tests: migrate: fix migration with --vdagent option

2019-10-03 Thread Uri Lublin

On 10/3/19 1:14 PM, Victor Toso wrote:

From: Victor Toso 

Before this patch, running the test with --vdagent option would error
in the second migration attempt with:

  | qemu-system-x86_64: Unknown savevm section or instance
  | ':00:04.0/virtio-console' 0. Make sure that your current VM setup
  | matches your saved VM setup, including any hotplugged devices

The reason is that target host created for migration was lacking the
configuration for vdagent that is present in the first source/target
migration VMs.

Signed-off-by: Victor Toso 


Looks good to me.

Uri.


---
  tests/migrate.py | 19 +--
  1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/tests/migrate.py b/tests/migrate.py
index 9afeb59c..5f0f13a2 100755
--- a/tests/migrate.py
+++ b/tests/migrate.py
@@ -77,10 +77,17 @@ def get_args():
  sys.exit(1)
  return args
  
-def start_qemu(qemu_exec, image, spice_port, qmp_filename, incoming_port=None, extra_args=[]):

+def start_qemu(qemu_exec, image, spice_port, qmp_filename, incoming_port=None, 
with_agent=False):
  incoming_args = []
  if incoming_port:
  incoming_args = ("-incoming tcp::%s" % incoming_port).split()
+
+extra_args = []
+if with_agent:
+extra_args = ['-device', 'virtio-serial',
+  '-chardev', 'spicevmc,name=vdagent,id=vdagent',
+  '-device', 
'virtserialport,chardev=vdagent,name=com.redhat.spice.0']
+
  args = ([qemu_exec, "-qmp", "unix:%s,server,nowait" % qmp_filename,
  "-spice", "disable-ticketing,port=%s" % spice_port]
  + incoming_args + extra_args)
@@ -147,13 +154,12 @@ class Migrator(object):
  self.monitor_files = monitor_files
  self.spice_ports = spice_ports
  self.vdagent = vdagent
-extra_args = []
-if self.vdagent:
-extra_args = ['-device', 'virtio-serial', '-chardev', 
'spicevmc,name=vdagent,id=vdagent', '-device', 
'virtserialport,chardev=vdagent,name=com.redhat.spice.0']
+
  self.active = start_qemu(qemu_exec=qemu_exec, image=image, 
spice_port=spice_ports[0],
- qmp_filename=monitor_files[0], 
extra_args=extra_args)
+ qmp_filename=monitor_files[0], 
with_agent=self.vdagent)
  self.target = start_qemu(qemu_exec=qemu_exec, image=image, 
spice_port=spice_ports[1],
- qmp_filename=monitor_files[1], 
incoming_port=migration_port)
+ qmp_filename=monitor_files[1], 
with_agent=self.vdagent,
+ incoming_port=migration_port)
  self.remove_monitor_files()
  self.connected_client = None
  
@@ -209,6 +215,7 @@ class Migrator(object):

  self.target = start_qemu(spice_port=new_spice_port,
  qemu_exec=self.qemu_exec, image=self.image,
  qmp_filename=new_qmp_filename,
+with_agent=self.vdagent,
  incoming_port=self.migration_port)
  print self.migration_count
  self.migration_count += 1



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

Re: [Spice-devel] [spice/tests/migrate v1 2/4] tests: migrate: wait user launch client option

2019-10-03 Thread Uri Lublin

On 10/3/19 1:14 PM, Victor Toso wrote:

From: Victor Toso 

Useful to test different clients running different tools (gdb,
valgrind).


It seems to me it's already solved by --wait-user-input.
The user can start the migration only after running the tool/client.

Uri.



Signed-off-by: Victor Toso 
---
  tests/migrate.py | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/tests/migrate.py b/tests/migrate.py
index 5ed9eba4..88e17691 100755
--- a/tests/migrate.py
+++ b/tests/migrate.py
@@ -63,6 +63,8 @@ def get_args():
  help="Append options for agent's virtserialport")
  parser.add_argument('--wait-user-input', dest="wait_user_input", 
action='store_true', default=False,
  help="Wait user's input to start migration test")
+parser.add_argument('--wait-user-connect', dest="wait_user_connect", 
action='store_true', default=False,
+help="Wait spice client to connect to move to next step of 
migration (default False)")
  parser.add_argument('--count', dest='counter', type=int, default=100,
  help="Number of migrations to run (set 0 for 
infinite)")
  args = parser.parse_args(sys.argv[1:])
@@ -174,25 +176,28 @@ class Migrator(object):
  if os.path.exists(x):
  os.unlink(x)
  
-def iterate(self, wait_for_user_input=False):

+def iterate(self, wait_for_user_input=False, wait_user_connect=False):
  wait_active(self.active.qmp, True)
  wait_active(self.target.qmp, False)
  if not self.connected_client:
  if self.client:
  self.connected_client = start_client(client=self.client, 
spice_port=self.spice_ports[0])
-wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
  
  if wait_for_user_input:

  print "waiting for Enter to start migrations"
  raw_input()
  
+# Tester can launch its own client or we wait start_client() to connect

+if wait_user_connect:
+wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
+
  self.active.qmp.cmd('client_migrate_info', {'protocol':'spice',
  'hostname':'localhost', 'port':self.target.spice_port})
  self.active.qmp.cmd('migrate', {'uri': 'tcp:localhost:%s' % 
self.migration_port})
  wait_active(self.active.qmp, False)
  wait_active(self.target.qmp, True)
  
-if self.connected_client:

+if self.connected_client or wait_user_connect:
  wait_for_event(self.target.qmp, 'SPICE_CONNECTED')
  
  dead = self.active

@@ -224,7 +229,7 @@ def main():
  atexit.register(cleanup, migrator)
  counter = 0
  while args.counter == 0 or counter < args.counter:
-migrator.iterate(args.wait_user_input)
+migrator.iterate(args.wait_user_input, args.wait_user_connect)
  counter += 1
  
  if __name__ == '__main__':




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

Re: [Spice-devel] [spice/tests/migrate v1 1/4] tests: migrate: default to not launch client

2019-10-03 Thread Uri Lublin

On 10/3/19 1:14 PM, Victor Toso wrote:

From: Victor Toso 

This supports doing migration without any client to be connected.
If tester wants client, it needs to pass an option to --client.

Change of default still is to keep the test as simple as possible
when no arguments are given.

Signed-off-by: Victor Toso 


Ack.

Uri.


---
  tests/migrate.py | 16 +++-
  1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/tests/migrate.py b/tests/migrate.py
index b11befdd..5ed9eba4 100755
--- a/tests/migrate.py
+++ b/tests/migrate.py
@@ -57,7 +57,8 @@ def get_args():
  parser.add_argument('--qemu', dest='qemu', 
default='../../qemu/x86_64-softmmu/qemu-system-x86_64')
  parser.add_argument('--log_filename', dest='log_filename', 
default='migrate.log')
  parser.add_argument('--image', dest='image', default='')
-parser.add_argument('--client', dest='client', default='spicy', 
choices=['spicy', 'remote-viewer'])
+parser.add_argument('--client', dest='client', default='none', 
choices=['spicy', 'remote-viewer', 'none'],
+help="Automatically lunch one of supported clients or none 
(default)")
  parser.add_argument('--vdagent', dest="vdagent", action='store_true', 
default=False,
  help="Append options for agent's virtserialport")
  parser.add_argument('--wait-user-input', dest="wait_user_input", 
action='store_true', default=False,
@@ -140,7 +141,7 @@ class Migrator(object):
  
  def __init__(self, log, client, qemu_exec, image, monitor_files,

   spice_ports, migration_port, vdagent):
-self.client = client
+self.client = client if client != "none" else None
  self.log = log
  self.qemu_exec = qemu_exec
  self.image = image
@@ -177,8 +178,10 @@ class Migrator(object):
  wait_active(self.active.qmp, True)
  wait_active(self.target.qmp, False)
  if not self.connected_client:
-self.connected_client = start_client(client=self.client, 
spice_port=self.spice_ports[0])
-wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
+if self.client:
+self.connected_client = start_client(client=self.client, 
spice_port=self.spice_ports[0])
+wait_for_event(self.active.qmp, 'SPICE_INITIALIZED')
+
  if wait_for_user_input:
  print "waiting for Enter to start migrations"
  raw_input()
@@ -188,7 +191,10 @@ class Migrator(object):
  self.active.qmp.cmd('migrate', {'uri': 'tcp:localhost:%s' % 
self.migration_port})
  wait_active(self.active.qmp, False)
  wait_active(self.target.qmp, True)
-wait_for_event(self.target.qmp, 'SPICE_CONNECTED')
+
+if self.connected_client:
+wait_for_event(self.target.qmp, 'SPICE_CONNECTED')
+
  dead = self.active
  dead.qmp.cmd("quit")
  dead.qmp.close()



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

Re: [Spice-devel] [spice-streaming-agent PATCH 4/4] Prepare for v0.3 release

2019-10-02 Thread Uri Lublin

On 9/27/19 10:47 AM, Frediano Ziglio wrote:


1. update NEWS
2. update configure.ac
3. update spec file

Signed-off-by: Uri Lublin 
---
  NEWS  | 17 +
  configure.ac  |  2 +-
  spice-streaming-agent.spec.in |  3 +++
  3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index aedf07a..2bd6b18 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,20 @@
+Major changes in 0.3:
+=
+- Improve the invalid option argument (-c) error message
+- Improve the frame log messages
+- Make the try-catch block in main() a catch-all
+- Set default syslog mask to a lower level
+- Fix some clang build errors
+- Adding gstreamer based plugin
+- Make error.hpp and the Error class a public API
+- Export symbols in the binary to be used by plugins
+- Interface + implementation of getting device display info
+- Send the GraphicsDeviceInfo to the server
+- Add support for logging statistics from plugins
+- Enable building with GCC 9
+- Add a man page
+
+
  Major changes in 0.2:
  =
  - First release
diff --git a/configure.ac b/configure.ac
index 1c7788b..bab1cc7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,6 +1,6 @@
  AC_PREREQ([2.57])
  
-AC_INIT(spice-streaming-agent, 0.2,

+AC_INIT(spice-streaming-agent, 0.3,
  [spice-devel@lists.freedesktop.org])
  
  AM_CONFIG_HEADER([config.h])

diff --git a/spice-streaming-agent.spec.in b/spice-streaming-agent.spec.in
index fcb8231..8faeecf 100644
--- a/spice-streaming-agent.spec.in
+++ b/spice-streaming-agent.spec.in
@@ -77,6 +77,9 @@ fi
  %{_libdir}/pkgconfig
  
  %changelog

+* Thu Sep 19 2019 Uri Lublin  - 0.3-1
+- Update to 0.3 release
+
  * Thu May 31 2018 Uri Lublin  - 0.2-1
  - First release
  


Sure the update to spec is necessary?

It just a bit more consistent (the generated spec will
have 0.3 version and 0.3 changelog).

If you prefer I can drop the spec-file change.



Otherwise,
Acked-by: Frediano Ziglio 


Thanks,
Uri.


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

Re: [Spice-devel] [spice-streaming-agent PATCH 2/4] spec: BuildRequires autoconf and friends

2019-10-02 Thread Uri Lublin

On 9/26/19 8:12 PM, Frediano Ziglio wrote:




Also only build for x86_64

Signed-off-by: Uri Lublin 


I don't see the reason, the spec file does not use them, the distributed
configure and related files are used.
Unless you force the generation of a new configure (that would be an
additional change in the spec).


You are right.
If you try to make an RPM of current master (based on 0.2 
tarball+patches), you'd need it.


I'll drop this patch.

Uri.



Why only amd64 ?

That's what was tested.




---
  spice-streaming-agent.spec.in | 4 
  1 file changed, 4 insertions(+)

diff --git a/spice-streaming-agent.spec.in b/spice-streaming-agent.spec.in
index 299ea02..a267c54 100644
--- a/spice-streaming-agent.spec.in
+++ b/spice-streaming-agent.spec.in
@@ -14,11 +14,15 @@ BuildRequires:  pkgconfig(udev)
  BuildRequires:  libdrm-devel
  BuildRequires:  libXrandr-devel
  BuildRequires:  gcc-c++
+BuildRequires:  automake autoconf autoconf-archive libtool
  # we need /usr/sbin/semanage program which is available on different
  # packages depending on distribution
  Requires(post): /usr/sbin/semanage
  Requires(postun): /usr/sbin/semanage
  
+ExclusiveArch: x86_64

+
+
  %description
  An agent, running on a guest, sending video streams of the X display to a
  remote client (over SPICE).


Frediano



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

Re: [Spice-devel] [spice-streaming-agent PATCH 1/4] gitignore: ignore tar.xz

2019-10-02 Thread Uri Lublin

On 9/26/19 8:10 PM, Frediano Ziglio wrote:

I would add the reason. In this case as "make dist" generates it (dist-xz is 
specified in configure.ac)


OK.





---
  .gitignore | 1 +
  1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 601cc9f..29d4a92 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,6 +4,7 @@
  *.lo
  *.tar.bz2
  *.tar.gz
+*.tar.xz
  .*.sw?
  .deps
  .dirstamp


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

[Spice-devel] [spice-streaming-agent PATCH 0/4] Get ready for v0.3 release

2019-09-26 Thread Uri Lublin
pipeline:
https://gitlab.freedesktop.org/uril/spice-streaming-agent/pipelines/66708

Uri Lublin (4):
  gitignore: ignore tar.xz
  spec: BuildRequires autoconf and friends
  Add a man page
  Prepare for v0.3 release

 .gitignore|  1 +
 Makefile.am   |  2 +
 NEWS  | 17 
 configure.ac  |  2 +-
 spice-streaming-agent.1   | 78 +++
 spice-streaming-agent.spec.in |  8 
 6 files changed, 107 insertions(+), 1 deletion(-)
 create mode 100644 spice-streaming-agent.1

-- 
2.21.0

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

[Spice-devel] [spice-streaming-agent PATCH 3/4] Add a man page

2019-09-26 Thread Uri Lublin
---
 Makefile.am   |  2 +
 spice-streaming-agent.1   | 78 +++
 spice-streaming-agent.spec.in |  1 +
 3 files changed, 81 insertions(+)
 create mode 100644 spice-streaming-agent.1

diff --git a/Makefile.am b/Makefile.am
index 99c1308..e57839d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -25,3 +25,5 @@ EXTRA_DIST = \
data/90-spice-guest-streaming.rules \
data/spice-streaming.desktop \
$(NULL)
+
+dist_man_MANS = spice-streaming-agent.1
diff --git a/spice-streaming-agent.1 b/spice-streaming-agent.1
new file mode 100644
index 000..81926fc
--- /dev/null
+++ b/spice-streaming-agent.1
@@ -0,0 +1,78 @@
+.TH SPICE-STREAMING-AGENT 1
+.SH NAME
+spice-streaming-agent \- An agent, running on a guest, sending video
+stream of X display to a remote client (over SPICE)
+
+.SH SYNOPSIS
+.B spice-streaming-agent [  ]
+
+.SH DESCRIPTION
+.B spice-streaming-agent
+is an agent, running on a guest, sending video stream of X display to
+a remote client (over SPICE)
+
+The video stream itself depends on plugins/codecs installed on the guest
+(and the client).
+
+Currently only supports X display (Xorg/X11).
+
+Requires a virtio-port device to communicate and a recent enough
+spice-server.
+
+.B spice-streaming-agent
+should start automatically with your X session.
+
+.\" ToDo: add qemu-kvm command line option example
+.\"   or refer to README file
+
+.SH OPTIONS
+.TP
+.BR \-p " " \fIportname\fR
+The virtio-serial port to use
+(default is /dev/virtio-ports/org.spice-space.stream.0)
+.TP
+.BR \-l " " \fIfile\fR
+log frames to file
+
+.TP
+.BR \-\-log-binary
+log binary frames (following -l)
+
+.TP
+.BR \-\-log-categories
+log categories, separated by ':' (currently: frames)
+
+.TP
+.BR \-\-plugins-dir " " path
+change plugins directory
+
+.TP
+.BR \-d
+enable debug logs
+
+.TP
+.BR \-c  " " \fIvariable=value\fR
+A generic way to change plugins/codecs settings.
+This only affects plugins that support this variable
+and this value (and ignored otherwise).
+
+.TP
+.BR \-c  " " \fIframerate=1-100\fR
+
+.\" ToDo: more -c options related to plugins
+
+.SH EXAMPLES
+.TP
+run spice-streaming-agent with a framerate of 20 frames per second
+spice-streaming-agent -c framerate=20
+
+.TP
+run and log binary frames to /tmp/ssa.log
+spice-streaming-agent -l /tmp/ssa.log --log-binary
+
+.TP
+run and print a lot of debug information
+spice-streaming-agent -d
+
+.SH SEE ALSO
+qemu-kvm(1)
diff --git a/spice-streaming-agent.spec.in b/spice-streaming-agent.spec.in
index a267c54..fcb8231 100644
--- a/spice-streaming-agent.spec.in
+++ b/spice-streaming-agent.spec.in
@@ -69,6 +69,7 @@ fi
 %{_bindir}/spice-streaming-agent
 %{_sysconfdir}/xdg/autostart/spice-streaming.desktop
 %{_datadir}/gdm/greeter/autostart/spice-streaming.desktop
+%{_mandir}/man1/spice-streaming-agent.1.gz
 
 %files devel
 %defattr(-,root,root,-)
-- 
2.21.0

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

[Spice-devel] [spice-streaming-agent PATCH 1/4] gitignore: ignore tar.xz

2019-09-26 Thread Uri Lublin
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 601cc9f..29d4a92 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,6 +4,7 @@
 *.lo
 *.tar.bz2
 *.tar.gz
+*.tar.xz
 .*.sw?
 .deps
 .dirstamp
-- 
2.21.0

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

[Spice-devel] [spice-streaming-agent PATCH 4/4] Prepare for v0.3 release

2019-09-26 Thread Uri Lublin
1. update NEWS
2. update configure.ac
3. update spec file

Signed-off-by: Uri Lublin 
---
 NEWS  | 17 +
 configure.ac  |  2 +-
 spice-streaming-agent.spec.in |  3 +++
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index aedf07a..2bd6b18 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,20 @@
+Major changes in 0.3:
+=
+- Improve the invalid option argument (-c) error message
+- Improve the frame log messages
+- Make the try-catch block in main() a catch-all
+- Set default syslog mask to a lower level
+- Fix some clang build errors
+- Adding gstreamer based plugin
+- Make error.hpp and the Error class a public API
+- Export symbols in the binary to be used by plugins
+- Interface + implementation of getting device display info
+- Send the GraphicsDeviceInfo to the server
+- Add support for logging statistics from plugins
+- Enable building with GCC 9
+- Add a man page
+
+
 Major changes in 0.2:
 =
 - First release
diff --git a/configure.ac b/configure.ac
index 1c7788b..bab1cc7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,6 +1,6 @@
 AC_PREREQ([2.57])
 
-AC_INIT(spice-streaming-agent, 0.2,
+AC_INIT(spice-streaming-agent, 0.3,
 [spice-devel@lists.freedesktop.org])
 
 AM_CONFIG_HEADER([config.h])
diff --git a/spice-streaming-agent.spec.in b/spice-streaming-agent.spec.in
index fcb8231..8faeecf 100644
--- a/spice-streaming-agent.spec.in
+++ b/spice-streaming-agent.spec.in
@@ -77,6 +77,9 @@ fi
 %{_libdir}/pkgconfig
 
 %changelog
+* Thu Sep 19 2019 Uri Lublin  - 0.3-1
+- Update to 0.3 release
+
 * Thu May 31 2018 Uri Lublin  - 0.2-1
 - First release
 
-- 
2.21.0

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

[Spice-devel] [spice-streaming-agent PATCH 2/4] spec: BuildRequires autoconf and friends

2019-09-26 Thread Uri Lublin
Also only build for x86_64

Signed-off-by: Uri Lublin 
---
 spice-streaming-agent.spec.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/spice-streaming-agent.spec.in b/spice-streaming-agent.spec.in
index 299ea02..a267c54 100644
--- a/spice-streaming-agent.spec.in
+++ b/spice-streaming-agent.spec.in
@@ -14,11 +14,15 @@ BuildRequires:  pkgconfig(udev)
 BuildRequires:  libdrm-devel
 BuildRequires:  libXrandr-devel
 BuildRequires:  gcc-c++
+BuildRequires:  automake autoconf autoconf-archive libtool
 # we need /usr/sbin/semanage program which is available on different
 # packages depending on distribution
 Requires(post): /usr/sbin/semanage
 Requires(postun): /usr/sbin/semanage
 
+ExclusiveArch: x86_64
+
+
 %description
 An agent, running on a guest, sending video streams of the X display to a
 remote client (over SPICE).
-- 
2.21.0

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

Re: [Spice-devel] [spice v2 2/8] tests: migrate: use uri for default's spicy client

2019-09-26 Thread Uri Lublin

On 9/25/19 1:02 PM, Victor Toso wrote:

From: Victor Toso 

Signed-off-by: Victor Toso 
Acked-by: Frediano Ziglio 
---
  tests/migrate.py | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/migrate.py b/tests/migrate.py
index 0c302c92..5a0f5930 100755
--- a/tests/migrate.py
+++ b/tests/migrate.py
@@ -96,8 +96,8 @@ def start_qemu(qemu_exec, image, spice_port, qmp_filename, 
incoming_port=None, e
  return proc
  
  def start_client(client, spice_port):

-return Popen(("%(client)s -h localhost -p %(port)d" % dict(port=spice_port,
-client=client)).split(), executable=client)
+client_cmd = "spicy --uri spice://localhost:%s" % (spice_port)
+return Popen(client_cmd.split(), executable=client)


Hi,

Since you remote-viewer is made available as a client on the next patch,
you can leave '%(client)s ' as is and not replace it with 'spicy'.

That also makes the next patch smaller.

Uri.

  
  def wait_active(q, active):

  events = ["RESUME"] if active else ["STOP"]



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

Re: [Spice-devel] proxmox spice - control video and audio compression

2019-09-10 Thread Uri Lublin

On 9/10/19 3:28 AM, Rafael de Almeida wrote:

Hello,

We use x2go and chrome remote desktop for VDI on the virtual machines 
that are on proxmox.


We recently started using spice to access webcam through weaker 
computers (dualcore processors) that don't support good quality video 
conferencing.



Everything is working perfectly (audio and image), but I believe there 
has been a high compression in the spice that causes a slight delay in 
sending video and audio.


The network has hardly any more significant use even with video sending.

How can I control compression? How do I deduce or disable compression in 
vm proxmox?




Hi,

You can use qemu-kvm -spice option to set the following options:
 * image-compression=[auto_glz|auto_lz|quic|glz|lz|off]
 * jpeg-wan-compression=[auto|never|always]
 * zlib-glz-wan-compression=[auto|never|always]
 * streaming-video=[off|all|filter]

See man qemu-kvm for more information.
You can start by setting all these options to 'off'.

See libvirt documentation about domain xml for setting these
options when running the VM via libvirt.

Hope that helps,
Uri.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk v4 24/29] usb-backend: Rewrite USB emulation support

2019-09-03 Thread Uri Lublin

On 9/3/19 3:08 PM, Frediano Ziglio wrote:


Hi,

On 8/27/19 12:22 PM, Frediano Ziglio wrote:

Make initialisation easier.
Always initialise parser.
Initialise both parser and host during spice_usb_backend_channel_new.
Support not having libusb context (no physical devices).
Avoids too much state variables.
parser is always initialised after creation making sure the state
is consistent.


If usbredirhost is used, why is there a need for a parser too ?
Also below in initialize_parser there is a check that
ch->usbredirhost is NULL (possibly because the parser is always
being initialized before the host).



For a larger explanation see former patch from Yuri.
For a shorter to parse data directed to emulated devices.
So host devices (physical) through usbredirhost, emulated devices
through usbparser.


The commit log is saying the parser is always being initialized.
I'm asking if it is needed also for physical devices.



The check for NULL as this path is supposed to initialize the
parse only if usbredirhost is not initialize > Maybe would be worth a comment 
or another name. Or maybe just inline
it now, not very long. What do you suggest?


Just leave it as is. I'll look at previous patches to better understand.




Use a single state variable, data flows into/from a single parser.

Signed-off-by: Frediano Ziglio 
---
   src/usb-backend.c | 236 +++---
   1 file changed, 116 insertions(+), 120 deletions(-)

diff --git a/src/usb-backend.c b/src/usb-backend.c
index 36a73a89..d614e693 100644
--- a/src/usb-backend.c
+++ b/src/usb-backend.c
@@ -78,21 +78,21 @@ struct _SpiceUsbBackend
   uint32_t own_devices_mask;
   };
   
+typedef enum {

+USB_CHANNEL_STATE_INITIALIZING,
+USB_CHANNEL_STATE_HOST,
+USB_CHANNEL_STATE_PARSER,
+} SpiceUsbBackendChannelState;
+
   struct _SpiceUsbBackendChannel
   {
   struct usbredirhost *usbredirhost;
-struct usbredirhost *hidden_host;
   struct usbredirparser *parser;
-struct usbredirparser *hidden_parser;
+SpiceUsbBackendChannelState state;
   uint8_t *read_buf;
   int read_buf_size;
   struct usbredirfilter_rule *rules;
   int rules_count;
-uint32_t host_caps;
-uint32_t parser_init_done  : 1;
-uint32_t parser_with_hello : 1;
-uint32_t hello_done_parser : 1;
-uint32_t hello_sent: 1;
   uint32_t rejected  : 1;
   uint32_t wait_disconnect_ack : 1;
   SpiceUsbBackendDevice *attached;
@@ -405,15 +405,16 @@ from both the main thread as well as from the usb
event handling thread */
   static void usbredir_write_flush_callback(void *user_data)
   {
   SpiceUsbBackendChannel *ch = user_data;
+if (ch->parser == NULL) {
+return;
+}
   if (is_channel_ready(ch->user_data)) {
-if (ch->usbredirhost) {


Do you need the following g_assert, or is the ch->parser==NULL enough
 g_assert(ch->state != USB_CHANNEL_STATE_INITIALIZING);



Which one are you referring to?


+if (ch->state == USB_CHANNEL_STATE_HOST) {
   SPICE_DEBUG("%s ch %p -> usbredirhost", __FUNCTION__, ch);
   usbredirhost_write_guest_data(ch->usbredirhost);
-} else if (ch->parser) {
+} else {
   SPICE_DEBUG("%s ch %p -> parser", __FUNCTION__, ch);
   usbredirparser_do_write(ch->parser);
-} else {
-SPICE_DEBUG("%s ch %p (NOT ACTIVE)", __FUNCTION__, ch);
   }
   } else {
   SPICE_DEBUG("%s ch %p (not ready)", __FUNCTION__, ch);
@@ -673,21 +674,42 @@ static void usbredir_log(void *user_data, int level,
const char *msg)
   }
   }
   
+static struct usbredirparser *create_parser(SpiceUsbBackendChannel *ch);

+
   static int usbredir_write_callback(void *user_data, uint8_t *data, int
   count)
   {
   SpiceUsbBackendChannel *ch = user_data;
   int res;
   SPICE_DEBUG("%s ch %p, %d bytes", __FUNCTION__, ch, count);
-if (!ch->hello_sent) {
-/* hello is short header (12) + hello struct (64) + capabilities
(4) */
-int hello_size = sizeof(struct usb_redir_header) + sizeof(struct
usb_redir_hello_header);
-ch->hello_sent = 1;
-if (count == hello_size) {
-memcpy(>host_caps, data + hello_size -
sizeof(ch->host_caps),
-   sizeof(ch->host_caps));
-SPICE_DEBUG("%s ch %p, sending first hello, caps %08X",
-__FUNCTION__, ch, ch->host_caps);
+
+// handle first packet (HELLO) creating parser from capabilities
+if (SPICE_UNLIKELY(ch->parser == NULL)) {
+// we are still initializing the host
+if (ch->usbredirhost == NULL) {
+return 0;
   }
+
+ch->parser = create_parser(ch);
+if (!ch->parser) {
+return 0;
+}
+
+/* hello is short header (12) + hello struct (64) */
+const int hello_size = 12 + sizeof(struct usb_redir_hello_header);


sizeof(struct usb_redir_header) 

Re: [Spice-devel] [PATCH spice-gtk v4 24/29] usb-backend: Rewrite USB emulation support

2019-09-03 Thread Uri Lublin

Hi,

On 8/27/19 12:22 PM, Frediano Ziglio wrote:

Make initialisation easier.
Always initialise parser.
Initialise both parser and host during spice_usb_backend_channel_new.
Support not having libusb context (no physical devices).
Avoids too much state variables.
parser is always initialised after creation making sure the state
is consistent.


If usbredirhost is used, why is there a need for a parser too ?
Also below in initialize_parser there is a check that
ch->usbredirhost is NULL (possibly because the parser is always
being initialized before the host).


Use a single state variable, data flows into/from a single parser.

Signed-off-by: Frediano Ziglio 
---
  src/usb-backend.c | 236 +++---
  1 file changed, 116 insertions(+), 120 deletions(-)

diff --git a/src/usb-backend.c b/src/usb-backend.c
index 36a73a89..d614e693 100644
--- a/src/usb-backend.c
+++ b/src/usb-backend.c
@@ -78,21 +78,21 @@ struct _SpiceUsbBackend
  uint32_t own_devices_mask;
  };
  
+typedef enum {

+USB_CHANNEL_STATE_INITIALIZING,
+USB_CHANNEL_STATE_HOST,
+USB_CHANNEL_STATE_PARSER,
+} SpiceUsbBackendChannelState;
+
  struct _SpiceUsbBackendChannel
  {
  struct usbredirhost *usbredirhost;
-struct usbredirhost *hidden_host;
  struct usbredirparser *parser;
-struct usbredirparser *hidden_parser;
+SpiceUsbBackendChannelState state;
  uint8_t *read_buf;
  int read_buf_size;
  struct usbredirfilter_rule *rules;
  int rules_count;
-uint32_t host_caps;
-uint32_t parser_init_done  : 1;
-uint32_t parser_with_hello : 1;
-uint32_t hello_done_parser : 1;
-uint32_t hello_sent: 1;
  uint32_t rejected  : 1;
  uint32_t wait_disconnect_ack : 1;
  SpiceUsbBackendDevice *attached;
@@ -405,15 +405,16 @@ from both the main thread as well as from the usb event 
handling thread */
  static void usbredir_write_flush_callback(void *user_data)
  {
  SpiceUsbBackendChannel *ch = user_data;
+if (ch->parser == NULL) {
+return;
+}
  if (is_channel_ready(ch->user_data)) {
-if (ch->usbredirhost) {


Do you need the following g_assert, or is the ch->parser==NULL enough
   g_assert(ch->state != USB_CHANNEL_STATE_INITIALIZING);


+if (ch->state == USB_CHANNEL_STATE_HOST) {
  SPICE_DEBUG("%s ch %p -> usbredirhost", __FUNCTION__, ch);
  usbredirhost_write_guest_data(ch->usbredirhost);
-} else if (ch->parser) {
+} else {
  SPICE_DEBUG("%s ch %p -> parser", __FUNCTION__, ch);
  usbredirparser_do_write(ch->parser);
-} else {
-SPICE_DEBUG("%s ch %p (NOT ACTIVE)", __FUNCTION__, ch);
  }
  } else {
  SPICE_DEBUG("%s ch %p (not ready)", __FUNCTION__, ch);
@@ -673,21 +674,42 @@ static void usbredir_log(void *user_data, int level, 
const char *msg)
  }
  }
  
+static struct usbredirparser *create_parser(SpiceUsbBackendChannel *ch);

+
  static int usbredir_write_callback(void *user_data, uint8_t *data, int count)
  {
  SpiceUsbBackendChannel *ch = user_data;
  int res;
  SPICE_DEBUG("%s ch %p, %d bytes", __FUNCTION__, ch, count);
-if (!ch->hello_sent) {
-/* hello is short header (12) + hello struct (64) + capabilities (4) */
-int hello_size = sizeof(struct usb_redir_header) + sizeof(struct 
usb_redir_hello_header);
-ch->hello_sent = 1;
-if (count == hello_size) {
-memcpy(>host_caps, data + hello_size - sizeof(ch->host_caps),
-   sizeof(ch->host_caps));
-SPICE_DEBUG("%s ch %p, sending first hello, caps %08X",
-__FUNCTION__, ch, ch->host_caps);
+
+// handle first packet (HELLO) creating parser from capabilities
+if (SPICE_UNLIKELY(ch->parser == NULL)) {
+// we are still initializing the host
+if (ch->usbredirhost == NULL) {
+return 0;
  }
+
+ch->parser = create_parser(ch);
+if (!ch->parser) {
+return 0;
+}
+
+/* hello is short header (12) + hello struct (64) */
+const int hello_size = 12 + sizeof(struct usb_redir_hello_header);


sizeof(struct usb_redir_header) instead of 12 (and btw it's 16)


+g_assert(count >= hello_size + 4);


nit: Maybe replace 4 with
  const size_t caps_size = sizeof(uint32_t) * USB_REDIR_CAPS_SIZE;
  g_assert(count >= hello_size + caps_size);


Uri.


+g_assert(SPICE_ALIGNED_CAST(struct usb_redir_header *, data)->type == 
usb_redir_hello);
+
+const uint32_t flags =
+usbredirparser_fl_write_cb_owns_buffer | 
usbredirparser_fl_usb_host |
+usbredirparser_fl_no_hello;
+
+usbredirparser_init(ch->parser,
+PACKAGE_STRING,
+SPICE_ALIGNED_CAST(uint32_t *, data + hello_size),
+(count - hello_size) / sizeof(uint32_t),
+  

Re: [Spice-devel] [spice-common patch] test-ssl-verify: test_generic: initialize num_entries

2019-09-02 Thread Uri Lublin

On 9/1/19 7:20 PM, Frediano Ziglio wrote:


If name is null num_entries may hold garbage value

clang warning: Assigned value is garbage or undefined
g_assert_cmpint(num_entries, ==, entry_count);
^

Also check name before num_entries.



Why this last sentence?


oops, the first patch I wrote (and did not send) also
checked name before (switched the order of the two check lines).
Since it does not really matter, I removed it.

I'll delete this from the commit log.

Thanks,
Uri.




Signed-off-by: Uri Lublin 
---
  tests/test-ssl-verify.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/test-ssl-verify.c b/tests/test-ssl-verify.c
index f5c5881..f80eb4c 100644
--- a/tests/test-ssl-verify.c
+++ b/tests/test-ssl-verify.c
@@ -79,7 +79,7 @@ static void test_generic(const void *arg)
  {
  const TestGenericParams *params = arg;
  X509_NAME *name;
-int num_entries;
+int num_entries = -1;
  
  setup_results(params->output);

  name = subject_to_x509_name(params->input, _entries);


Otherwise patch is fine.

Frediano



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

[Spice-devel] [spice-common patch] test-ssl-verify: test_generic: initialize num_entries

2019-09-01 Thread Uri Lublin
If name is null num_entries may hold garbage value

clang warning: Assigned value is garbage or undefined
   g_assert_cmpint(num_entries, ==, entry_count);
   ^

Also check name before num_entries.

Signed-off-by: Uri Lublin 
---
 tests/test-ssl-verify.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/test-ssl-verify.c b/tests/test-ssl-verify.c
index f5c5881..f80eb4c 100644
--- a/tests/test-ssl-verify.c
+++ b/tests/test-ssl-verify.c
@@ -79,7 +79,7 @@ static void test_generic(const void *arg)
 {
 const TestGenericParams *params = arg;
 X509_NAME *name;
-int num_entries;
+int num_entries = -1;
 
 setup_results(params->output);
 name = subject_to_x509_name(params->input, _entries);
-- 
2.21.0

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

[Spice-devel] [spice-vdagent PATCH v2 1/2] vdagentd: daemonize: check fopen/fprintf return value

2019-08-29 Thread Uri Lublin
Upon failure, write a warning message and continue

Found-by: covscan

Signed-off-by: Uri Lublin  
---

v1->v2: added a check for fopen too.

---
 src/vdagentd/vdagentd.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/vdagentd/vdagentd.c b/src/vdagentd/vdagentd.c
index 72a3e13..ba1b0c7 100644
--- a/src/vdagentd/vdagentd.c
+++ b/src/vdagentd/vdagentd.c
@@ -996,8 +996,13 @@ static void daemonize(void)
 }
 pidfile = fopen(pidfilename, "w");
 if (pidfile) {
-fprintf(pidfile, "%d\n", (int)getpid());
+int r = fprintf(pidfile, "%d\n", (int)getpid());
+if (r < 0) {
+syslog(LOG_WARNING, "Error writing to %s: %m", pidfilename);
+}
 fclose(pidfile);
+} else {
+syslog(LOG_WARNING, "Failed to create pidfile %s: %m", 
pidfilename);
 }
 break;
 case -1:
-- 
2.21.0

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

[Spice-devel] [spice-vdagent PATCH v2 2/2] virtio-port: handle_fds: make read and write code consistent

2019-08-29 Thread Uri Lublin
A comment and curly brackets for style were added.

Signed-off-by: Uri Lublin 
---

v1->v2: use shorter version (alternative of v1)
add curly brackets to if blocks

---
 src/vdagentd/virtio-port.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/vdagentd/virtio-port.c b/src/vdagentd/virtio-port.c
index 3ae7f22..06f3a32 100644
--- a/src/vdagentd/virtio-port.c
+++ b/src/vdagentd/virtio-port.c
@@ -166,14 +166,14 @@ int vdagent_virtio_port_fill_fds(struct 
vdagent_virtio_port *vport,
 void vdagent_virtio_port_handle_fds(struct vdagent_virtio_port **vportp,
 fd_set *readfds, fd_set *writefds)
 {
-if (!*vportp)
-return;
-
-if (FD_ISSET((*vportp)->fd, readfds))
+if (*vportp && FD_ISSET((*vportp)->fd, readfds)) {
 vdagent_virtio_port_do_read(vportp);
+}
 
-if (*vportp && FD_ISSET((*vportp)->fd, writefds))
+/* *vportp may have been destroyed in do_read */
+if (*vportp && FD_ISSET((*vportp)->fd, writefds)) {
 vdagent_virtio_port_do_write(vportp);
+}
 }
 
 static struct vdagent_virtio_port_buf* vdagent_virtio_port_get_last_wbuf(
-- 
2.21.0

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

Re: [Spice-devel] [spice-vdagent PATCH 2/2] virtio-port: handle_fds: make read and write code consistent

2019-08-28 Thread Uri Lublin

On 8/28/19 7:13 PM, Frediano Ziglio wrote:


"return early" before write too

Signed-off-by: Uri Lublin 
---

Alternatively, change the read part such that:

 if (*vportp && FD_ISSET((*vportp)->fd, readfds))
 vdagent_virtio_port_do_read
 if (*vportp && FD_ISSET((*vportp)->fd, writefds))
 vdagent_virtio_port_do_write


---
  src/vdagentd/virtio-port.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/vdagentd/virtio-port.c b/src/vdagentd/virtio-port.c
index 3ae7f22..af5bd58 100644
--- a/src/vdagentd/virtio-port.c
+++ b/src/vdagentd/virtio-port.c
@@ -172,7 +172,10 @@ void vdagent_virtio_port_handle_fds(struct
vdagent_virtio_port **vportp,
  if (FD_ISSET((*vportp)->fd, readfds))
  vdagent_virtio_port_do_read(vportp);
  
-if (*vportp && FD_ISSET((*vportp)->fd, writefds))

+if (!*vportp) /* may have been destroyed in do_read */
+return;
+
+if (FD_ISSET((*vportp)->fd, writefds))
  vdagent_virtio_port_do_write(vportp);
  }
  


They are equivalent (beside the comment which can be added on top of
the if).
I like the alternative version if it's really important.


OK, I'll send v2 with the alternative.


Style: always brackets.


Yeah, I left it as it was ; I'll fix that too.

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

[Spice-devel] [spice-vdagent PATCH 2/2] virtio-port: handle_fds: make read and write code consistent

2019-08-28 Thread Uri Lublin
"return early" before write too

Signed-off-by: Uri Lublin 
---

Alternatively, change the read part such that:

if (*vportp && FD_ISSET((*vportp)->fd, readfds))
vdagent_virtio_port_do_read
if (*vportp && FD_ISSET((*vportp)->fd, writefds))
vdagent_virtio_port_do_write


---
 src/vdagentd/virtio-port.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/vdagentd/virtio-port.c b/src/vdagentd/virtio-port.c
index 3ae7f22..af5bd58 100644
--- a/src/vdagentd/virtio-port.c
+++ b/src/vdagentd/virtio-port.c
@@ -172,7 +172,10 @@ void vdagent_virtio_port_handle_fds(struct 
vdagent_virtio_port **vportp,
 if (FD_ISSET((*vportp)->fd, readfds))
 vdagent_virtio_port_do_read(vportp);
 
-if (*vportp && FD_ISSET((*vportp)->fd, writefds))
+if (!*vportp) /* may have been destroyed in do_read */
+return;
+
+if (FD_ISSET((*vportp)->fd, writefds))
 vdagent_virtio_port_do_write(vportp);
 }
 
-- 
2.21.0

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

[Spice-devel] [spice-vdagent PATCH 1/2] vdagentd: daemonize: check fprintf return value

2019-08-28 Thread Uri Lublin
Other fprintf calls are checked.

If fprintf fails write an error message and continue.

Make covscan happy

Signed-off-by: Uri Lublin  
---
 src/vdagentd/vdagentd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/vdagentd/vdagentd.c b/src/vdagentd/vdagentd.c
index 72a3e13..22a62b8 100644
--- a/src/vdagentd/vdagentd.c
+++ b/src/vdagentd/vdagentd.c
@@ -996,7 +996,10 @@ static void daemonize(void)
 }
 pidfile = fopen(pidfilename, "w");
 if (pidfile) {
-fprintf(pidfile, "%d\n", (int)getpid());
+int r = fprintf(pidfile, "%d\n", (int)getpid());
+if (r < 0) {
+syslog(LOG_ERR, "Error writing to %s: %m", pidfilename);
+}
 fclose(pidfile);
 }
 break;
-- 
2.21.0

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

Re: [Spice-devel] [PATCH] covscan: add comment on false-positive on g_memdup()

2019-08-28 Thread Uri Lublin

On 8/27/19 6:16 PM, Victor Toso wrote:

From: Victor Toso 

Previous commit set last element of orig_argv array to NULL.
That's redundant as g_memdup() uses memcpy() and it would do
just that. Add a comment that the reason for this change is
to workaround clang's warning.

Suggested by Uri.
Signed-off-by: Victor Toso 


Acked-by: Uri Lublin 

Thanks,
  Uri.


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

diff --git a/src/vdagent/vdagent.c b/src/vdagent/vdagent.c
index 5b146db..a944214 100644
--- a/src/vdagent/vdagent.c
+++ b/src/vdagent/vdagent.c
@@ -418,10 +418,8 @@ int main(int argc, char *argv[])
  GOptionContext *context;
  GError *error = NULL;
  VDAgent *agent;
-char **orig_argv;
-
-orig_argv = g_memdup(argv, sizeof(char*) * (argc+1));
-orig_argv[argc] = NULL;
+char **orig_argv = g_memdup(argv, sizeof(char*) * (argc+1));
+orig_argv[argc] = NULL; /* To avoid clang analyzer false-positive */
  
  context = g_option_context_new(NULL);

  g_option_context_add_main_entries(context, entries, NULL);



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

Re: [Spice-devel] [PATCH v2 1/2] covscan: initialize argv's copy

2019-08-27 Thread Uri Lublin

On 8/27/19 3:42 PM, Victor Toso wrote:

From: Victor Toso 

Otherwise we get a CLANG_WARNING due accessing garbage.

Covscan report:
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:471:9: warning: 1st function 
call argument is an uninitialized value
  > #execvp(orig_argv[0], orig_argv);
  > #^  
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:421:24: note: Storing 
uninitialized value
  > #char **orig_argv = g_memdup(argv, sizeof(char*) * (argc+1));
  > #   ^~~~
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:434:9: note: Assuming 'error' is 
equal to NULL
  > #if (error != NULL) {
  > #^
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:434:5: note: Taking false branch
  > #if (error != NULL) {
  > #^
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:442:9: note: Assuming 'portdev' 
is not equal to NULL
  > #if (portdev == NULL)
  > #^~~
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:442:5: note: Taking false branch
  > #if (portdev == NULL)
  > #^
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:445:9: note: Assuming 
'vdagentd_socket' is not equal to NULL
  > #if (vdagentd_socket == NULL)
  > #^~~
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:445:5: note: Taking false branch
  > #if (vdagentd_socket == NULL)
  > #^
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:448:30: note: Assuming 
'do_daemonize' is 0
  > #openlog("spice-vdagent", do_daemonize ? LOG_PID : (LOG_PID | 
LOG_PERROR),
  > # ^~~~
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:448:30: note: '?' condition is 
false
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:451:9: note: Assuming the 
condition is false
  > #if (!g_file_test(portdev, G_FILE_TEST_EXISTS)) {
  > #^
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:451:5: note: Taking false branch
  > #if (!g_file_test(portdev, G_FILE_TEST_EXISTS)) {
  > #^
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:457:9: note: Assuming 
'do_daemonize' is 0
  > #if (do_daemonize)
  > #^~~~
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:457:5: note: Taking false branch
  > #if (do_daemonize)
  > #^
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:468:9: note: Assuming 
'version_mismatch' is not equal to 0
  > #if (version_mismatch) {
  > #^~~~
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:468:5: note: Taking true branch
  > #if (version_mismatch) {
  > #^
  > spice-vdagent-0.19.0/src/vdagent/vdagent.c:471:9: note: 1st function call 
argument is an uninitialized value
  > #execvp(orig_argv[0], orig_argv);
  > #^  
  > #  469|   syslog(LOG_INFO, "Version mismatch, restarting");
  > #  470|   sleep(1);
  > #  471|-> execvp(orig_argv[0], orig_argv);
  > #  472|   }
  > #  473|

Signed-off-by: Victor Toso 
---
  src/vdagent/vdagent.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/vdagent/vdagent.c b/src/vdagent/vdagent.c
index 0e2e73e..5b146db 100644
--- a/src/vdagent/vdagent.c
+++ b/src/vdagent/vdagent.c
@@ -418,7 +418,10 @@ int main(int argc, char *argv[])
  GOptionContext *context;
  GError *error = NULL;
  VDAgent *agent;
-char **orig_argv = g_memdup(argv, sizeof(char*) * (argc+1));


I would not touch this line. It's already correct.
Just add the additional line.


+char **orig_argv;
+
+orig_argv = g_memdup(argv, sizeof(char*) * (argc+1));
+orig_argv[argc] = NULL;


Please add a comment saying this line's only purpose is
to overcome a false-positive in clang.
For example (feel free to use a different one) something like:

+/* This line is redundant. orig_argv[argc] is already NULL */
+orig_argv[argc] = NULL; /* "fix" clang analyzer false-positive */

Uri

  
  context = g_option_context_new(NULL);

  g_option_context_add_main_entries(context, entries, NULL);



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

  1   2   3   4   5   6   7   8   9   10   >