Having a very odd issue. I built a brand new WIN10 test system. System was built very carefully, with no SPICE and using GPU-passthrough / EvDev from the start. At no time this system had any tablet device presented to it and it only had ps2-mouse and ps2-kbd input devices. SPICE was setup for Looking-Glass at the very end of the install. Everything was working well until cumulative-1909 was applied. From that point on, the mouse pointer location updates only when I left-click (same behavior as if I had a tablet device mapped). Capture mode works perfect, but once you turn it off, it again loses cursor movement. The odd issue is that if I turn off the SPICE-vdagent service, everything works well (and obviously I lose clipboard functionality). Turning the service back on again and toggling capture to on and back to off will cause the cursor to lose movement again. Tried this with both the spice-guest-tools.exe installer and also with the latest agent 0.10.0 installer - same results. Has anyone experienced such an issue or knows how to fix this?
Any chance you are using wayland? I have seen this one before and it was due to changes to the way we handle mouse update events not playing nice with Wayland.
Thx for the reply. No - using xOrg:
~$ echo $XDG_SESSION_TYPE
x11
Running Ubuntu 18.04 on the host and the issue is 100% reproducible. Once vdagent service is on and you toggle mouse capture, the mouse moves on clicks. Turning the service off makes everything work. When capture mode is on, everything works fine either way.
I have the same problem and also removed after removing the agent.
It is not looking glass - passing through the mouse works just fine and using spice client in virt-manager has the same problem.
In the end using looking_glass for mouse is a waste of time, I just toggle it with a hotkey. What I wish LG had is hotkey for minimizing the window.
In plasma I have capture all global shortcuts and having one for dumping the window would be great.
Can both of you please post your QEMU command line (libvirt is not useful to me). You can obtain this from ps while the VM is running.
I already undid the setup, but I will try it again later.
Thanks for looking at this. Following is the QEMU command line as run by libvirt. I’m using QEMU version 4.2.0
/usr/local/qemu/bin/qemu-system-x86_64
-name guest=win10,debug-threads=on
-S
-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-win10/master-key.aes
-machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off
-cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff
-drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on
-drive file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1
-m 8192
-realtime mlock=off
-smp 6,sockets=1,cores=3,threads=2
-uuid 3337567b-c5e4-4799-abd3-5050e00b7ab7
-no-user-config
-nodefaults
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-win10/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control
-rtc base=localtime,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 i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e
-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0
-device pcie-root-port,port=0x8,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x1
-device pcie-root-port,port=0x9,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x1
-device pcie-root-port,port=0xa,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x2
-device pcie-root-port,port=0xb,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x3
-device pcie-root-port,port=0xc,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x4
-device pcie-root-port,port=0xd,chassis=8,id=pci.8,bus=pcie.0,addr=0x1.0x5
-device pcie-root-port,port=0xe,chassis=9,id=pci.9,bus=pcie.0,addr=0x1.0x6
-device pcie-root-port,port=0xf,chassis=10,id=pci.10,bus=pcie.0,addr=0x1.0x7
-device pcie-root-port,port=0x10,chassis=11,id=pci.11,bus=pcie.0,addr=0x2
-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2
-device virtio-serial-pci,id=virtio-serial0,bus=pci.8,addr=0x0
-drive file=/data4/libvirt_images/win10.qcow2,format=qcow2,if=none,id=drive-virtio-disk0
-device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive file=/data3/libvirt_images/win10_data1.qcow2,format=qcow2,if=none,id=drive-virtio-disk1
-device virtio-blk-pci,scsi=off,bus=pci.9,addr=0x0,drive=drive-virtio-disk1,id=virtio-disk1
-device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1
-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:84:7e:43,bus=pci.3,addr=0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-device virtio-keyboard-pci,id=input2,bus=pci.10,addr=0x0
-device virtio-mouse-pci,id=input3,bus=pci.11,addr=0x0
-spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
-device cirrus-vga,id=video0,bus=pci.2,addr=0x2
-device vfio-pci,host=03:00.0,id=hostdev0,bus=pci.6,addr=0x0
-device vfio-pci,host=03:00.1,id=hostdev1,bus=pci.7,addr=0x0
-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0
-device ich9-intel-hda,bus=pcie.0,addr=0x1b
-device hda-micro,audiodev=hda1
-audiodev pa,id=hda1,timer-period=99,server=192.168.122.1
-object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/looking-glass,size=134217728,share=yes
-device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pci.2,addr=0x1
-msg timestamp=onVery strange, I do not see anything here that could account for the behaviour you mentioned. I run the identical setup without any issues as you describe them.
I know this might be a silly thing to ask, but did you make sure to install the windows virtio keyboard and mouse drivers?
Absolutely. Both keyboard and mouse drivers were installed from the virtio-win ISO and show up working properly on the device manager tree. Hopefully @BansheeHero can bring his QEMU command line so we can see another example. Any other things I can do on my side to debug this?
I truly appreciate your assistance.
I will try to r3eplicate it again today, but I am not optimistic.
The reason why is that removing spice from the VM or removing the agent solved the problem,
I did use the Tablet during installation (easy to forget with libvirt), but switched to mouse later.
Thanks! For me it was 100% reproducible. I’ve built 2 machines from scratch to test this and every time had this issue once the agent is running.
Hi, I wanted to open a thread about this exact same issue.
How do install the virtio keyboard and mouse drivers? I can’t seem to find the instructions for this.
I only have “Generic Mouse Device”.
Besides this, it worked for a few test rounds after VM setup until it stopped working, unless I press the Scroll Key.
I have [spice-guest-tools] installed and I’m currently using version B2-RC2.
This is not the exact same issue, you’re asking how to install drivers. Please open a thread in #software:vfio for this.
Okay. Will do.