Description of problem: When accessing a kvm virtual machine via SPICE using virt-viewer the screen content of the vm is only updated when the virt viewer window takes or loses focus while any kind of input like typing or mouse interaction is passed to the vm without displaying it. Works perfectly with the older 3.1 version. Version-Release number of selected component (if applicable): virt-viewer 4.0-256 Win x64 (latest available) How reproducible: always Steps to Reproduce: 1. open a virt viewer connection to a kvm machine via SPICE 2. perform some user input actions like typing or moving a window 3. watch the vm display seemingly frozen 4. focus a different window so that virt-viewer loses focus 5. watch the vm display being updated once, showing former user input Actual results: Expected results: obvious Additional info:
*** Bug 1353963 has been marked as a duplicate of this bug. ***
*** Bug 1357890 has been marked as a duplicate of this bug. ***
*** Bug 1358827 has been marked as a duplicate of this bug. ***
Confirming. Hit this bug today with virt-viewer x64 4.0-256 on Windows 10 Prof x64.
I hit this bug with some virt-viewer version, but on Windows 7 Prof x64
Spent some time today cross-compiling and tracked it down to be caused by some changes in recent mingw-gtk3. With mingw-gtk3-3.18.9-1 everything works fine. Switching to mingw-gtk3-3.20.9-1 breaks remote-viewer. UI seems to be broken no matter the version of virt-viewer. I had tried compiling both v3.1 branch and latest master/HEAD branch for vier-viewer coupled with mingw-gtk3-3.20.9-1 and there are problems with UI refreshing for both. Replacing gtk3 dlls with older version (3.18.9-1) in place immediately fixes the problem. Probably it would be wise to: a) reassign this bug to mingw-gtk3 and _maybe_ forward it upstream; b) rebuild and repackage Windows releases of virt-viewer 4.0 using mingw-gtk3-3.18.9-1 so awful situation with published binaries being broken for months would finally be fixed.
(In reply to Alexey Loukianov from comment #6) > Spent some time today cross-compiling and tracked it down to be caused by > some changes in recent mingw-gtk3. With mingw-gtk3-3.18.9-1 everything works > fine. > > Switching to mingw-gtk3-3.20.9-1 breaks remote-viewer. UI seems to be broken > no matter the version of virt-viewer. I had tried compiling both v3.1 branch > and latest master/HEAD branch for vier-viewer coupled with > mingw-gtk3-3.20.9-1 and there are problems with UI refreshing for both. > Replacing gtk3 dlls with older version (3.18.9-1) in place immediately fixes > the problem. > > Probably it would be wise to: > a) reassign this bug to mingw-gtk3 and _maybe_ forward it upstream; > b) rebuild and repackage Windows releases of virt-viewer 4.0 using > mingw-gtk3-3.18.9-1 so awful situation with published binaries being broken > for months would finally be fixed. Hi, there was a discussion about it, and we were told that it is not a gtk bug :) It is needed to have following commits to fix the issue: https://git.fedorahosted.org/cgit/virt-viewer.git/commit/?id=2d2d7ac2f7286abc3b5abb6c869e97aca5b477d4 https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=fdd80e5ed4002f94d3e31c9a76426b49823ea7e5 https://git.gnome.org/browse/gtk-vnc/commit/?id=58f7e555a73de2e4b147a405beb6c76da28e09b6
Pavel, thanks for infos. It must be https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=fdd80e5ed4002f94d3e31c9a76426b49823ea7e5 then, as the builds I've done do not use gtk-vnc at all (spice&libvirt only) and I had tried latest HEAD for virt-viewer so 2d2d7ac2f does not resolve the problem. I would try to bump mingw-spice-gtk SRPM I used up to latest master/HEAD and check if having that commit in place would fix the issue. In any case my point about having broken windows binaries published for month with only solution offered being to use older version (and not v3.1, but even v.3.0 - WTF?!) is not normal at all. It leads to a situation when possible customers turn their backs on spice reasoning that other solutions work better and are at least supported in some way. It also stands for Windows USB redirection support - official virt-viewer MSI packages published on upstream site had been compiled without usbredir support. It was even reported several times on mailing list but was never fixed. :-(
(In reply to Alexey Loukianov from comment #8) > Pavel, thanks for infos. > > It must be > https://cgit.freedesktop.org/spice/spice-gtk/commit/ > ?id=fdd80e5ed4002f94d3e31c9a76426b49823ea7e5 then, as the builds I've done > do not use gtk-vnc at all (spice&libvirt only) and I had tried latest HEAD > for virt-viewer so 2d2d7ac2f does not resolve the problem. All the 3 commits I mentioned in the comment 7 are needed. I created the msi and uploaded it to https://people.freedesktop.org/~pgrunt/virt-viewer-x64-4.0-maint.msi > > I would try to bump mingw-spice-gtk SRPM I used up to latest master/HEAD and > check if having that commit in place would fix the issue. > There was no release with that commit > In any case my point about having broken windows binaries published for > month with only solution offered being to use older version (and not v3.1, > but even v.3.0 - WTF?!) is not normal at all. I don't think there are big differencies between v3.1 v3.0 and v4.0 I agree that it is not ideal. OTOH I believe that it was always stated that the msi published on virt-manager.org are experimental. > It leads to a situation when > possible customers turn their backs on spice reasoning that other solutions > work better and are at least supported in some way. It also stands for > Windows USB redirection support > - official virt-viewer MSI packages > published on upstream site had been compiled without usbredir support. It > was even reported several times on mailing list but was never fixed. :-( Support for spice usbredir (USBdK) was added last year to the libusb, but there was no release with that.
The linked .msi doesn't work for me on Windows 7 (64-bit). Remote-Viewer crashes instantly stating "Unspecified fatal error enountered, aborting."
@Ralf http://lexa2.ru/lx2/virt-viewer/ I had placed there the full set of files I use with Windows 10 virt-viewer side and Windows guests including virt-viewer MSI installer files. virt-viwer was built by me on CentOS 7 host system using sources from latest git as of three days ago. I've been using mock with slightly modified epel-7 config. Feel free to use them as long as you would risk and trust binaries found on the internet from some stranger out there :-). Other packages used during build: mingw-adwaita-icon-theme-3.20-1.lx2el7.src.rpm mingw-atk-2.20.0-1.lx2el7.src.rpm mingw-cairo-1.14.6-1.lx2el7.src.rpm mingw-celt051-0.5.1.3-15.lx2el7.src.rpm mingw-gdk-pixbuf-2.32.3-3.lx2el7.src.rpm mingw-glib2-2.48.2-1.lx2el7.src.rpm mingw-gstreamer1-1.8.1-1.lx2el7.src.rpm mingw-gstreamer1-plugins-bad-free-1.8.1-1.lx2el7.src.rpm mingw-gstreamer1-plugins-base-1.8.1-1.lx2el7.src.rpm mingw-gstreamer1-plugins-good-1.8.1-1.lx2el7.src.rpm mingw-gtk3-3.18.9-1.lx2el7.src.rpm mingw-gtk-vnc-0.5.4-5.lx2el7.src.rpm mingw-ilmbase-2.2.0-3.lx2el7.src.rpm mingw-libepoxy-1.3.1-3.lx2el7.src.rpm mingw-libgovirt-0.3.2-3.lx2el7.src.rpm mingw-libsoup-2.54.1-1.lx2el7.src.rpm mingw-libusbx-1.0.19-3.lx2el7.src.rpm mingw-libvirt-2.2.0-1.lx2el7.src.rpm mingw-libvirt-glib-0.2.3-2.lx2el7.src.rpm mingw-nettle-3.2-1.lx2el7.src.rpm mingw-OpenEXR-2.2.0-3.lx2el7.src.rpm mingw-orc-0.4.26-1.lx2el7.src.rpm mingw-pango-1.40.1-1.lx2el7.src.rpm mingw-phodav-2.0-6.lx2el7.src.rpm mingw-portablexdr-4.9.1-14.lx2el7.src.rpm mingw-rest-0.7.92-3.lx2el7.src.rpm mingw-spice-gtk-0.32-3.lx2el7.src.rpm mingw-spice-protocol-0.12.11-1.lx2el7.src.rpm mingw-usbredir-0.7.1-2.lx2el7.src.rpm
(In reply to Alexey Loukianov from comment #11) > @Ralf > > http://lexa2.ru/lx2/virt-viewer/ > I had placed there the full set of files I use with Windows 10 virt-viewer > side and Windows guests including virt-viewer MSI installer files. > virt-viwer was built by me on CentOS 7 host system using sources from latest > git as of three days ago. I've been using mock with slightly modified epel-7 > config. Feel free to use them as long as you would risk and trust binaries > found on the internet from some stranger out there :-). Alexey, I'm testing the version you uploaded. Client is Windows 7, viewer is on Windows 10. When this viewer displays a windows application with objects grayed out, they're smeared.. hard to describe what it looks like, I can send you a screen shot if you like. They display OK on earlier versions of the viewer. Vinny
@Vincent Let's keep offtopic discussion off this bug report. Feel free to reach me by e-mail and I would try to help you with your issue.
(In reply to Vincent Meyer from comment #12) > (In reply to Alexey Loukianov from comment #11) > > @Ralf > > > > http://lexa2.ru/lx2/virt-viewer/ > > I had placed there the full set of files I use with Windows 10 virt-viewer > > side and Windows guests including virt-viewer MSI installer files. > > virt-viwer was built by me on CentOS 7 host system using sources from latest > > git as of three days ago. I've been using mock with slightly modified epel-7 > > config. Feel free to use them as long as you would risk and trust binaries > > found on the internet from some stranger out there :-). > Alexey, I tried to install UsbDk_1.0.14_x86.msi with win7 x86_32 in http://lexa2.ru/lx2/virt-viewer. But I met below messages. How can I solve this problem? -------- There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.
I don't know if this is particularly helpful, but it may be worth noting that the screen-update issue here may not be a Windows build issue, because it is also true of the Debian Stretch build too. In my case, the screen only updates when the window is resized by the user, and then doesn't update again until the next resize.
@Andy G Can confirm this. I'm also using Debian Stretch and virt-viewer freezes in full screen mode with windows 7 as guest os. This only happens with me in full screen mode when guest and host os are set to the same resolution: host: 1920*1080 -- guest: 1920*1080 --> full screen:freeze scaled: ok host: 1920*1080 -- guest: 1680*1050 --> full screen: ok scaled: ok host: 1680*1050 -- guest: 1680*1050 --> full screen: freeze scaled: ok
(In reply to Pieter-Jan Crommen from comment #16) > @Andy G > > Can confirm this. > I'm also using Debian Stretch and virt-viewer freezes in full screen mode > with windows 7 as guest os. > This only happens with me in full screen mode when guest and host os are set > to the same resolution: > host: 1920*1080 -- guest: 1920*1080 --> full screen:freeze > scaled: ok > host: 1920*1080 -- guest: 1680*1050 --> full screen: ok > scaled: ok > host: 1680*1050 -- guest: 1680*1050 --> full screen: freeze > scaled: ok hi, it can be the same fix as for windows. Can you test the v4.0-maint branch https://git.fedorahosted.org/cgit/virt-viewer.git/?h=v4.0-maint ? It contains a fix for problems caused by changes in the recent gtk (3.19 and newer)
(In reply to Pavel Grunt from comment #17) > (In reply to Pieter-Jan Crommen from comment #16) > > @Andy G > > > > Can confirm this. > > I'm also using Debian Stretch and virt-viewer freezes in full screen mode > > with windows 7 as guest os. > > This only happens with me in full screen mode when guest and host os are set > > to the same resolution: > > host: 1920*1080 -- guest: 1920*1080 --> full screen:freeze > > scaled: ok > > host: 1920*1080 -- guest: 1680*1050 --> full screen: ok > > scaled: ok > > host: 1680*1050 -- guest: 1680*1050 --> full screen: freeze > > scaled: ok > > hi, it can be the same fix as for windows. Can you test the v4.0-maint > branch https://git.fedorahosted.org/cgit/virt-viewer.git/?h=v4.0-maint ? It > contains a fix for problems caused by changes in the recent gtk (3.19 and > newer) I shall report if the issue still exists when the debian branch has been merged with the upstream fix
I can also confirm the issue as described by Pieter-Jan. Issue only happens in full screen mode when host and guest have the same resolutions. Using openSUSE Tumbleweed with Windows 7 as guest. The latest virt-viewer changelog in openSUSE is: Fri 19 Aug 2016 07:00:00 CDT carnold - bsc#983689 - virt-viewer shows Domain-0 on list of virtual machines virtview-dont-show-Domain-0.patch - Upstream bug fix 813c775c-fix-filename-leak-on-transfer-dialog.patch Which matches with the last commit in the branch you pointed out @Pavel.
(In reply to David De Smet from comment #19) > I can also confirm the issue as described by Pieter-Jan. > Issue only happens in full screen mode when host and guest have the same > resolutions. Using openSUSE Tumbleweed with Windows 7 as guest. > > The latest virt-viewer changelog in openSUSE is: > > Fri 19 Aug 2016 07:00:00 CDT > carnold > - bsc#983689 - virt-viewer shows Domain-0 on list of virtual > machines > virtview-dont-show-Domain-0.patch > - Upstream bug fix > 813c775c-fix-filename-leak-on-transfer-dialog.patch > > Which matches with the last commit in the branch you pointed out @Pavel. It can be spice-gtk as well. Or even gtk - what version do you have ? Please attach debug logs (run virt-viewer --debug --spice-debug) Thanks
Hi @Pavel, I've actually tried with spice-gtk (spicy) and it works in full screen. I started a thread in openSUSE forums (link below) before getting to here; you can find a more detailed information in there. https://forums.opensuse.org/showthread.php/520283-KVM-Guest-s-fullscreen-issue-using-virt-manager I will try with debug and report back. In the meantime, my gtk version: libgtk-3-0 - The GTK+ toolkit library (version 3) 3.22.0-1.1 Thanks
Hi David, the fix is in spice-gtk commit: https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=a395ac59447dedfb922f997c7c9cff93edd53600 workaround for virt-manager is to disable "auto resize"
Created attachment 1208025 [details] virt-viewer debug and spice-debug @Pavel I already tried it but still the issue remains. View -> Scale Display -> Never View -> Scale Display -> [uncheck] Auto resize VM with window I've attached the debug log.
David, can you test with the latest release of spice-gtk: https://www.spice-space.org/download/gtk/spice-gtk-0.33.tar.bz2
@Pavel Thanks a lot! I can confirm that 0.33 version fixes the issue. I've built some rpms for openSUSE Tumbleweed which can be downloaded from here: https://www.dropbox.com/sh/c12iq01yakn9m20/AACSW080jOkUnWL09kRpceI6a?dl=0 While openSUSE updates the packages.
When would a Windows version will be released? I have used the 5.0 version that @Vinny(vincent) from: http://lexa2.ru/lx2/virt-viewer/ I have not tested all cases but it seems to work good enough compared to v3.x Eliezer
It was released: https://virt-manager.org/download/ https://releases.pagure.org/virt-viewer/