Bug 1491320 - heavy screen flicker with latest kernels in qxl+spice VM
Summary: heavy screen flicker with latest kernels in qxl+spice VM
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-13 14:00 UTC by Kamil Páral
Modified: 2017-12-01 05:53 UTC (History)
43 users (show)

Fixed In Version: kernel-4.13.10-100.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1512097 (view as bug list)
Environment:
Last Closed: 2017-11-03 13:45:13 UTC


Attachments (Terms of Use)
VM blinking video (1.43 MB, application/octet-stream)
2017-09-13 14:01 UTC, Kamil Páral
no flags Details
vm-journal.out (174.19 KB, text/plain)
2017-09-13 14:01 UTC, Kamil Páral
no flags Details
vm.xml (4.04 KB, text/plain)
2017-09-13 14:01 UTC, Kamil Páral
no flags Details


Links
System ID Priority Status Summary Last Updated
Linux Kernel 196777 None None None Never
Red Hat Bugzilla 1462381 None None None Never
Red Hat Bugzilla 1507931 None None None Never

Internal Links: 1462381 1507931

Description Kamil Páral 2017-09-13 14:00:17 UTC
Description of problem:
With 4.12.11-300.fc26, everything is fine. With 4.12.12-300.fc26, every screen update forces a switch to fully black screen for a split second and back. Like a stroboscope effect. Also the mouse cursor is invisible most of the time.

See the video.

I don't see anything interesting in neither host nor VM journal.

Version-Release number of selected component (if applicable):
kernel-4.12.12-300.fc26

How reproducible:
always

Comment 1 Kamil Páral 2017-09-13 14:01:10 UTC
Created attachment 1325471 [details]
VM blinking video

Comment 2 Kamil Páral 2017-09-13 14:01:37 UTC
Created attachment 1325473 [details]
vm-journal.out

Comment 3 Kamil Páral 2017-09-13 14:01:52 UTC
Created attachment 1325474 [details]
vm.xml

Comment 4 Debarshi Ray 2017-09-13 15:49:23 UTC
Well, my F26 VM doesn't even boot in Boxes with kernel-4.12.12-300.fc26 (bug 1462381).

Comment 5 Shane Overturf 2017-09-16 15:21:31 UTC
I can confirm the same issues as op. F26 in VM, this kernel makes it impossible to use the mouse. Host in my case is CentOS 7.4 fully patched and updated.

I also can confirm the issue described by Debarshi with all the 4.12 kernels. The work-around I discovered to get it to boot is to hit the up arrow as soon as you see the f logo during boot to switch from the logo screen to the traditional console view with the scrolling startup messages. This allows it to finish booting without freezing.

Comment 6 Kamil Páral 2017-10-02 13:15:41 UTC
This can be also seen with F27 kernels, like kernel-4.13.3-301.fc27.x86_64. See Justin's reply in bug 1462381#c52 , quoting here since it's important:

> So that test build removed the patch that introduced the flicker, but this
> is the comment I got from upstream in regards to that:
> 
> "Workaround #1: turn off wayland.
> Workaround #2: use virtio-vga instead. wayland doesn't use qxl 2d accel
> anyway.
> 
> Fundamental problem here is that the qxl virtual hardware simply doesn't
> support pageflip, we have to destroy + re-create the primary surface
> instead.  This is where the flicker comes from.
> 
> Commit "058e9f5c82 drm/qxl: simple crtc page flipping emulated using buffer
> copy" handles the issue with a pretty gross hack, blitting one framebuffer
> over the other instead of a proper primary surface update.  With atomic
> modesetting that doesn't work any more.
> 
> We could possibly decouple the primary surface from the drm framebuffers, so
> the drm framebuffers effectively become shadow framebuffers, and every
> display update becomes a drm framebuffer -> primary surface blit.  Not sure
> whenever that scheme can work properly with xorg though.  Also has a high
> chance to cause xorg performance regressions."

Proposing as a Final blocker. virt-manager is now unusable by default with F26 and F27 guests (the workaround is to use virtio gpu driver). gnome-boxes is broken comment 4 (and I don't think you can change the driver easily in there). 

That violates in lesser or greater form at least:
"The release must be able host virtual guest instances of the same release.
...when using Fedora's recommended virtualization technology, that is. This criterion applies only to the recommended Fedora virtualization tools - the qemu/kvm - libvirt - virt-manager stack."
https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria#Self_hosting_virtualization
"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test. "
https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria#Default_application_functionality

We either need a fix in the kernel (seems difficult), wayland disabled in VMs (not likely), wayland disabled in VMs only when qxl is detected (if it's even possible), change of the default gpu driver to virtio in both virt-manager and gnome-boxes (and figure out if there are any drawbacks), or... something else.

Comment 7 Kamil Páral 2017-10-02 13:32:38 UTC
I can confirm gnome-boxes blink horribly (same as virt-manager) when running F27 Beta Workstation Live in it. There seems to be no GUI option to change the gpu driver.

Comment 8 Kamil Páral 2017-10-02 16:26:06 UTC
Discussed at blocker review meeting [1]:

AcceptedBlocker (Final) - This violates "The release must be able host virtual guest instances of the same release" criterion. Affected parties, please find a solution here.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-10-02/

Comment 9 Kamil Páral 2017-10-02 17:43:00 UTC
We believe there are the following ways to fix this (there might be more, please suggest):

1. virt-manager and gnome-boxes start using virtio graphics driver instead of qxl by default. That will fix all VMs created in the future (on Fedora). The drawback is that qxl is supposed to be faster for Xorg sessions than virtio (it has some acceleration), but virtio allow us to use Wayland (which we do by default, so we should prefer that one).

2. GNOME (likely mutter) will detect when running on a qxl graphics driver and fall back to Xorg session. This will fix this issue for older VMs (created with qxl by default) and users on other distributions.

Adding Cole Robinson (virt-manager), Christophe Fergeau (gnome-boxes) and Florian Müllner (gnome-shell) to CC. Guys, can you please look at this and tell us how feasible this is before the Fedora 27 Final release [1]? Thanks.

[1] https://fedoraproject.org/wiki/Releases/27/Schedule

Comment 10 Joachim Frieben 2017-10-02 19:52:07 UTC
(In reply to Kamil Páral from comment #7)
Booting in "basic graphics mode" adds the kernel boot option "nomodeset" which still provides a means to run a working GNOME session.

Comment 11 Shane Overturf 2017-10-02 20:10:12 UTC
@Kamil
Unfortunately switching to virtio-vga is not an option when the host is CentOS, because the version of qemu installed on CentOS does not support that driver (I suppose that is more of a CentOS/Redhat issue than Fedora).
Currently I'm just keeping all my Fedora VM's at the kernel before this change happened - 4.12.11-300.fc26.
I'm anxious to see the second fix you mention (GNOME dropping to Xorg) come down the pipe so that I can test it on my CentOS host.

Comment 12 Justin M. Forbes 2017-10-02 20:23:25 UTC
https://koji.fedoraproject.org/koji/taskinfo?taskID=22215027

Anyone want to give the test kernel here a spin. I don't have high hopes, but it was worth a try.

Comment 13 Shane Overturf 2017-10-02 22:17:16 UTC
@Justin
success!
that kernel boots fine as a Fedora VM on a CentOS host.

Comment 14 Justin M. Forbes 2017-10-03 00:00:05 UTC
I know it boots, but does it still have the flicker?

Comment 15 Shane Overturf 2017-10-03 00:02:02 UTC
no, my point was that it boots and works normally - no flicker.

Comment 16 Kamil Páral 2017-10-03 07:26:31 UTC
(In reply to Justin M. Forbes from comment #12)
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22215027
> 
> Anyone want to give the test kernel here a spin. I don't have high hopes,
> but it was worth a try.

It doesn't flicker for me on my F27 QXL VM. Looks good. What exactly did you do there?

Comment 17 Joachim Frieben 2017-10-03 07:52:44 UTC
(In reply to Justin M. Forbes from comment #14)
Booting from custom kernel-4.13.4-300.fc27, the virtual machine hangs before reaching the graphic login manager. After setting "WaylandEnable=false" in /etc/gdm/custom.conf, the graphic login manager starts up as expected but it is running on top of Xorg, of course.

Comment 18 Justin M. Forbes 2017-10-03 12:09:38 UTC
(In reply to Kamil Páral from comment #16)
> (In reply to Justin M. Forbes from comment #12)
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=22215027
> > 
> > Anyone want to give the test kernel here a spin. I don't have high hopes,
> > but it was worth a try.
> 
> It doesn't flicker for me on my F27 QXL VM. Looks good. What exactly did you
> do there?

I backed out a portion of the fixes from earlier. I am afraid the result is going to be mixed, some users will see it as a complete fix, some users will see a non working machine. I am curious how many that is.

Comment 19 Kamil Páral 2017-10-04 12:02:59 UTC
I tested some more, and it works for me, using wayland, but it breaks plymouth splash screen (it doesn't show up and resets back to console during boot).

Justin, is there a chance of bug 1462381 reoccurring on some setups? Comment 17 seems to indicate that.
Also, by "non working machine" do you mean system hanging or screen flickering? 
If this turned out to be the easiest way forward not affecting many, how long are you going to keep the patches? Since it doesn't make sense to break this again in a few months, during stable release. It would be nice to give virt-manager+boxes+mutter devs some time to adjust to this, if we could keep this patches until Fedora 28. If not, it's probably best to deal with it now.

I'm not sure how QXL driver is related to upstream kernel development. The response you posted (comment 6), does that include QXL devs looking into this, or would it be worth to contact them?

Comment 20 Justin M. Forbes 2017-10-04 12:22:34 UTC
There is a chance of hang, but this is more me guessing by looking at the code. I don't have a whole lot of insight into exactly how QXL interacts with the spice server.

QXL devs are looking into this, that is the upstream we have been dealing with. You can see the conversations in the linked bug, and as of last night we now have a thread on the spice-devel mailing list:

https://lists.freedesktop.org/archives/spice-devel/2017-October/040310.html

As for time frame in keeping the patch, I don't have an issue with carrying it until F28. My concern is that it will stop working at some point.

Comment 21 Kamil Páral 2017-10-04 16:44:34 UTC
Felipe is said to be a good point of contact for gnome-boxes, adding. Felipe, please see comment 9, thanks.

Comment 22 Victor Toso 2017-10-05 09:31:32 UTC
Ongoing discussion on spice list:
https://lists.freedesktop.org/archives/spice-devel/2017-October/040310.html

Comment 23 Felipe Borges 2017-10-05 13:48:39 UTC
Thanks for cc'ing me here, Kamil.

I am already running F27 and I am able to reproduce the flickering while having a F27 guest in GNOME Boxes as well.

By enabling virgl in the guest (when it is available) I see the flickering go away (works for me™).

This build includes the virgl changes mentioned above, but it requires:
spice-gtk >= 0.33.5 and libvirt-gconfig >= 0.2.4

https://koji.fedoraproject.org/koji/taskinfo?taskID=22266979

Comment 24 Bill Gianopoulos 2017-10-05 14:00:44 UTC
I see extensive flickering with fedora 27 on an hp 4545s after sleeping and then re-awakening the flickering happens when scrolling in a gnome terminal window and actually occurs outside that window.  It also occurs very severely just before the screen blanking timeout form power same settings.

Comment 25 Debarshi Ray 2017-10-05 14:19:59 UTC
(In reply to Debarshi Ray from comment #4)
> Well, my F26 VM doesn't even boot in Boxes with kernel-4.12.12-300.fc26 (bug
> 1462381).

Now that's out of the way, I can see the flickering even on an F25 host. That's not surprising because it has kernel-4.12.14-200.fc25.x86_64.

Comment 26 Kamil Páral 2017-10-05 14:50:08 UTC
(In reply to Felipe Borges from comment #23)
> By enabling virgl in the guest (when it is available) I see the flickering
> go away (works for me™).

You mean virtio-gpu, right? virgl is I believe accelerated OpenGL support, which we don't strictly need.

> This build includes the virgl changes mentioned above, but it requires:
> spice-gtk >= 0.33.5 and libvirt-gconfig >= 0.2.4
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22266979

I'm getting this error when I create the VM and try to display it (the VM is running and I see a thumbnail, but can't open up the whole screen):

gnome-boxes[3091]: machine.vala:615: Failed to connect to Fedora-Workstation-Live-x86_64-27_Beta-1: unsupported display of type 

(Also adding back the rest of needinfos)

Comment 27 Bill Gianopoulos 2017-10-05 14:54:57 UTC
(In reply to Bill Gianopoulos from comment #24)
> I see extensive flickering with fedora 27 on an hp 4545s after sleeping and
> then re-awakening the flickering happens when scrolling in a gnome terminal
> window and actually occurs outside that window.  It also occurs very
> severely just before the screen blanking timeout form power same settings.

So my point here is that extreme screen flickering IS NOT confined to qxl+spice VM!

Comment 28 Paul W. Frields 2017-10-05 15:17:17 UTC
(In reply to Bill Gianopoulos from comment #27)
> (In reply to Bill Gianopoulos from comment #24)
> > I see extensive flickering with fedora 27 on an hp 4545s after sleeping and
> > then re-awakening the flickering happens when scrolling in a gnome terminal
> > window and actually occurs outside that window.  It also occurs very
> > severely just before the screen blanking timeout form power same settings.
> 
> So my point here is that extreme screen flickering IS NOT confined to
> qxl+spice VM!

Bill, issues on a baremetal install are not relevant to this bug. Please search for a relevant bug, or file a new one.

Comment 29 Bill Gianopoulos 2017-10-05 15:24:38 UTC
(In reply to Paul W. Frields from comment #28)
> (In reply to Bill Gianopoulos from comment #27)
> > (In reply to Bill Gianopoulos from comment #24)
> > > I see extensive flickering with fedora 27 on an hp 4545s after sleeping and
> > > then re-awakening the flickering happens when scrolling in a gnome terminal
> > > window and actually occurs outside that window.  It also occurs very
> > > severely just before the screen blanking timeout form power same settings.
> > 
> > So my point here is that extreme screen flickering IS NOT confined to
> > qxl+spice VM!
> 
> Bill, issues on a baremetal install are not relevant to this bug. Please
> search for a relevant bug, or file a new one.

I realize this in rather unlikely to be related but wanted to raise the possibility here that it might be.

Comment 30 Justin M. Forbes 2017-10-06 11:15:12 UTC
(In reply to Bill Gianopoulos from comment #29)
> (In reply to Paul W. Frields from comment #28)
> > (In reply to Bill Gianopoulos from comment #27)
> > > (In reply to Bill Gianopoulos from comment #24)
> > > > I see extensive flickering with fedora 27 on an hp 4545s after sleeping and
> > > > then re-awakening the flickering happens when scrolling in a gnome terminal
> > > > window and actually occurs outside that window.  It also occurs very
> > > > severely just before the screen blanking timeout form power same settings.
> > > 
> > > So my point here is that extreme screen flickering IS NOT confined to
> > > qxl+spice VM!
> > 
> > Bill, issues on a baremetal install are not relevant to this bug. Please
> > search for a relevant bug, or file a new one.
> 
> I realize this in rather unlikely to be related but wanted to raise the
> possibility here that it might be.

It's not

Comment 31 Felipe Borges 2017-10-11 15:02:03 UTC
(In reply to Kamil Páral from comment #26)
> I'm getting this error when I create the VM and try to display it (the VM is
> running and I see a thumbnail, but can't open up the whole screen):
> 
> gnome-boxes[3091]: machine.vala:615: Failed to connect to
> Fedora-Workstation-Live-x86_64-27_Beta-1: unsupported display of type 

This should be fixed in spice-gtk 0.33.5.

Comment 32 František Zatloukal 2017-10-12 10:56:10 UTC
I was able to reproduce the GNOME Boxes error when trying to open virtual machine:
gnome-boxes[3013]: machine.vala:615: Failed to connect to Fedora-Workstation-Live-x86_64-27_Beta-1: unsupported display of type

gnome-boxes-3.26.0-2.fc27.x86_64
spice-gtk3-0.34-1.fc27.x86_64
spice-gtk-0.34-1.fc27.x86_64

Comment 33 Lukas Brabec 2017-10-12 10:57:18 UTC
(In reply to František Zatloukal from comment #32)
> I was able to reproduce the GNOME Boxes error when trying to open virtual
> machine:
> gnome-boxes[3013]: machine.vala:615: Failed to connect to
> Fedora-Workstation-Live-x86_64-27_Beta-1: unsupported display of type
> 
> gnome-boxes-3.26.0-2.fc27.x86_64
> spice-gtk3-0.34-1.fc27.x86_64
> spice-gtk-0.34-1.fc27.x86_64

reproduced here as well, same error, same package versions

Comment 34 Kamil Páral 2017-10-17 14:30:10 UTC
This gnome-boxes build fixes the flickering for me:
https://koji.fedoraproject.org/koji/taskinfo?taskID=22503855
Felipe is working on submitting a proper update.

Comment 35 Fedora Update System 2017-10-17 15:09:12 UTC
gnome-boxes-3.26.1-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6db5c0829b

Comment 36 Adam Williamson 2017-10-17 17:37:52 UTC
I'm not sure that changing the defaults is really sufficient, personally. For a start we'd at least need to ship an F26 update that changed the defaults too, as we have the criterion that VMs must boot on the previous stable release. And then there are still existing VMs, VMs on non-Fedora systems. I'd really like to have the GNOME fix; from what I understand it *ought* to be possible, there already is a point in the GNOME startup flow which checks various conditions and falls back to X11 in some cases, I'd think we could add one more check there (probably as a downstream patch).

Comment 37 Cole Robinson 2017-10-17 22:53:16 UTC
So just to summarize since there's a bunch of tangents in the above comments:

- Latest kernels on f25, f26, f27 in a VM + qxl video + wayland cause massive unusable UI flicker
- There isn't any known kernel workaround (that doesn't cause worse issues elsewhere, comment #19)
- kernel/qxl devs are discussing options but there's no fix yet: https://lists.freedesktop.org/archives/spice-devel/2017-October/040310.html
- the gnome-boxes update changes the video default but that only avoids the issue for VMs created with gnome-boxes on f27

(In reply to Adam Williamson from comment #36)
> I'm not sure that changing the defaults is really sufficient, personally.
> For a start we'd at least need to ship an F26 update that changed the
> defaults too, as we have the criterion that VMs must boot on the previous
> stable release. And then there are still existing VMs, VMs on non-Fedora
> systems. I'd really like to have the GNOME fix; from what I understand it
> *ought* to be possible, there already is a point in the GNOME startup flow
> which checks various conditions and falls back to X11 in some cases, I'd
> think we could add one more check there (probably as a downstream patch).

I agree with all of this. Changing the defaults is only one piece of the puzzle even if we push it to all supported fedora branches.

IMO the main concern for f27 release is making sure that the livecd will work in VMs since we don't update it after the fact. So if the kernel fix/workaround isn't going to be timely then a gnome side workaround like suggested above and by kamil in comment #9 is needed

(felipe, the gnome-boxes bodhi update should probably drop this bug so it isn't autoclosed)

Comment 38 Philip Prindeville 2017-10-17 23:53:34 UTC
(In reply to Cole Robinson from comment #37)
> So just to summarize since there's a bunch of tangents in the above comments:
> 
> - Latest kernels on f25, f26, f27 in a VM + qxl video + wayland cause
> massive unusable UI flicker
> - There isn't any known kernel workaround (that doesn't cause worse issues
> elsewhere, comment #19)

It's anecdotal only, of course, but I amended my /etc/default/grub file as:

% sed -i -e 's/^GRUB_CMDLINE_LINUX=/{s/"$/ nomodeset&/}' /etc/default/grub

then ran:

% grub2-mkconfig -o /boot/grub2/grub.cfg

and rebooted.  Not seeing the problem any more.

Yes, I'm having to fix the guest to fix issues in the host, so it's obviously suboptimal... but it's workable for now.

Comment 39 Kamil Páral 2017-10-18 08:21:30 UTC
(In reply to Philip Prindeville from comment #38)
nomodeset avoids the issue because if forces X11. It's a workaround, yes, but not something we want to set by default.

Comment 40 Cole Robinson 2017-10-18 20:48:04 UTC
ccing gerd from the spice discussion.

gerd, any update on a kernel fix/workaround in the short term? the flicker issue is set as a blocker for fedora 27 final release, we are trying to come up with a game plan

Comment 41 Cole Robinson 2017-10-18 20:48:56 UTC
(In reply to Cole Robinson from comment #40)
> ccing gerd from the spice discussion.
> 
> gerd, any update on a kernel fix/workaround in the short term? the flicker
> issue is set as a blocker for fedora 27 final release, we are trying to come
> up with a game plan

actually ccing and setting needinfo

Comment 42 Cole Robinson 2017-10-18 20:49:46 UTC
Settings status to NEW since the gnome-boxes build won't fully fix this

Comment 43 Dave Airlie 2017-10-19 02:11:21 UTC
https://patchwork.freedesktop.org/series/32259/

seems to work around it.

Comment 44 Gerd Hoffmann 2017-10-19 05:58:06 UTC
See also: https://bugzilla.kernel.org/show_bug.cgi?id=196777

Comment 46 Ray Strode [halfline] 2017-10-19 14:34:33 UTC
sounds like there's a way forward here (comment 45), but I just wanted to point out another potential option… (don't know if it's viable, don't know if it will have the same problem, but i'm throwing it out there)

If drmModePageFlip leads to flickering, change the kernel driver to fail with ENOSYS for drmModePageFlip instead of proceeding.  That will make mutter fall back to using drmModeSetCrtc instead…

Comment 47 Ray Strode [halfline] 2017-10-19 15:51:32 UTC
jforbes threw the drm-qxl-atomic branches fixes into git, so I started a scratch build here.

kparal, when it finishes mind giving it a try?

https://koji.fedoraproject.org/koji/taskinfo?taskID=22552293

Comment 48 Ray Strode [halfline] 2017-10-19 16:02:09 UTC
actually, i'm duplicating effort here, use this scratch build instead:

https://koji.fedoraproject.org/koji/taskinfo?taskID=22552020

Comment 49 Cole Robinson 2017-10-19 20:39:29 UTC
(In reply to Ray Strode [halfline] from comment #48)
> actually, i'm duplicating effort here, use this scratch build instead:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22552020

This build (4.13.8) stops the flickering for me. kernel 4.13.5 reliably produces the flicker. This is an f27 VM running on f26

That said I just tested f27 VM on f27 host with latest 4.13.8 kernel from updates-testing and it seemed to fix the flicker too... are the qxl patches in the bodhi build too? If so we should attach this bug I think

Comment 50 Justin M. Forbes 2017-10-19 21:57:32 UTC
They are not, the piece in 4.13.8 in bodhi will cause other issues. I dropped the patch that introduced the flicker, but that patch fixed another issue.

Comment 51 Cole Robinson 2017-10-19 22:05:52 UTC
(In reply to Justin M. Forbes from comment #50)
> They are not, the piece in 4.13.8 in bodhi will cause other issues. I
> dropped the patch that introduced the flicker, but that patch fixed another
> issue.

Oh, is that the bit that causes bug 1462381 to reappear?

I can't seem to trigger that at all, so if someone who could previous trigger that hang could test the scratch build, that would be best (Debarishi maybe but he was on f26)

Comment 52 Joachim Frieben 2017-10-22 07:02:41 UTC
(In reply to Ray Strode [halfline] from comment #48)
The scratch build works great for me both with respect to graphical boot and GNOME-on-Wayland desktop use.

Comment 53 Kamil Páral 2017-10-23 13:28:51 UTC
(In reply to Ray Strode [halfline] from comment #48)
> actually, i'm duplicating effort here, use this scratch build instead:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22552020

I don't see any flicker, but sadly the mouse cursor is invisible once again in gdm (happens always for me). The cursor is fine once logged in.

Comment 54 Joachim Frieben 2017-10-23 15:00:03 UTC
(In reply to Kamil Páral from comment #53)
I do frequently observe an invisible mouse pointer in gnome-boxes; usually it is sufficient to close the application window and to relaunch gnome-boxes. The running VM is then restored, and one can continue using it.
I do not think that the described behaviour has to do with the present issue.

Comment 55 Kamil Páral 2017-10-23 15:13:03 UTC
(In reply to Joachim Frieben from comment #54)
I'm using virt-manager and I can consistently see missing cursor in gdm using kernel from comment 48, and consistently see cursor working fine using standard F27 kernels.

Comment 56 Kamil Páral 2017-10-23 15:14:51 UTC
Joachim, please also note that recent gnome-boxes build has replaced qxl with virtio vga, so gnome-boxes can no longer be used for reproducing the flicker issue.

Comment 57 Joachim Frieben 2017-10-23 19:34:07 UTC
(In reply to Kamil Páral from comment #56)
My comment 52 was based on using the successful scratch build kernel-4.13.8-300.fc27 (no flicker) instead of the normal package kernel-4.13.8-300.fc27 (flicker), and indeed, the Fedora 27 VM running under gnome-boxes on a Fedora 27 host was doubtlessly using the QXL driver.
By the way, the latest koji build gnome-boxes-3.26.1-3.fc27 which you seem to refer to has not even surfaced in updates-testing yet. Moreover, the standard use of virtio-vga only applies to newly created VMs, and even then, it is still possible to switch back to QXL by editing the VM's config file.
Given the positive result with scratch build kernel-4.13.8-300.fc27, I do not see any reason to switch to default video device virtio-vga unless upstream decides to do so.

Comment 58 Fedora Update System 2017-10-24 07:20:47 UTC
kernel-4.13.9-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-35a8ab46d9

Comment 59 Fedora Update System 2017-10-24 07:23:19 UTC
kernel-4.13.9-200.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e8390ff6c3

Comment 60 Fedora Update System 2017-10-24 07:24:42 UTC
kernel-4.13.9-100.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-af9174446e

Comment 61 Kamil Páral 2017-10-24 08:46:18 UTC
(In reply to Fedora Update System from comment #58)
> kernel-4.13.9-300.fc27 has been submitted as an update to Fedora 27.
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-35a8ab46d9

Same as in comment 53, in virt-manager I have consistently an invisible cursor in gdm after boot (once logged in, the cursor is fine, and when logged out, the cursor is also fine in gdm). I also tried gnome-boxes-3.26.1-3.fc27 and I don't reproduce the invisible cursor in there.

Comment 62 Joachim Frieben 2017-10-24 10:44:36 UTC
(In reply to Kamil Páral from comment #61)
It might then be sensible to file a bug for virt-manager. Anyway, gnome-boxes is the default virtualization frontend delivered with Fedora. In this respect kernel-4.13.9-300.fc27 appears to resolve the blocker issue successfully.

Comment 63 Adam Williamson 2017-10-24 21:56:18 UTC
We generally consider virt-manager and gnome-boxes to both be part of the 'blocking' virt stack for Fedora, give or take a handwave or two.

In any case, the difference is likely down to virtio vs. qxl, not really boxes vs. virt-manager: note that Kamil tested with the gnome-boxes build which changes the default to virtio. We are not necessarily going to accept the switch to virtio by default for Boxes any more, given that we're now attempting to fix the qxl bugs at the kernel level. So the cursor issue could still do with looking at.

Kamil, I've seen 'disappearing cursor' in a few recent attempts too, for me it seems like the cursor is actually missing in the *entire VM window* (not just the actual guest display, but also the virt-manager chrome around it), and quitting virt-manager, restarting it and reopening the VM window makes the cursor work again...is that what you're seeing too?

Comment 64 Joachim Frieben 2017-10-25 04:09:14 UTC
(In reply to Adam Williamson from comment #63)
When the mouse pointer turns invisible in gnome-boxes, it already disappears when merely hitting the window decoration. The issue thus seems to be very similar or identical to that of virt-manager. As mentioned earlier, destroying the window and launching gnome-boxes again usually restores the mouse pointer for the VM running in the background.

Comment 65 Kamil Páral 2017-10-25 13:11:09 UTC
(In reply to Adam Williamson from comment #63)
> Kamil, I've seen 'disappearing cursor' in a few recent attempts too, for me
> it seems like the cursor is actually missing in the *entire VM window* (not
> just the actual guest display, but also the virt-manager chrome around it),
> and quitting virt-manager, restarting it and reopening the VM window makes
> the cursor work again...is that what you're seeing too?

Nope. For me, the cursor is missing only in the VM content area. In the VM window chrome I see the cursor just fine. Reopening the VM window, virt-manager window, and even restarting libvirtd doesn't help.

(In reply to Joachim Frieben from comment #64)
Your actual testing feedback is appreciated, but please limit the noise regarding the blocker processes or assessing other people's feedback, because you're completely off the mark, and this is not a good place to discuss that. This bug report needs to stay readable.

Comment 66 Fedora Update System 2017-10-25 15:24:07 UTC
kernel-4.13.9-300.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-35a8ab46d9

Comment 67 Joachim Frieben 2017-10-25 18:20:07 UTC
(In reply to Kamil Páral from comment #65)
Stop posting nonsense like in comment 56 (not the first time indeed) and the noise level will drop significantly, thanks.

Comment 68 Adam Williamson 2017-10-25 18:58:36 UTC
So, we really need to decide what the plan is, here.

To summarize, we have two proposed changes at present. 

* https://bodhi.fedoraproject.org/updates/FEDORA-2017-6db5c0829b - gnome-boxes-3.26.1-3.fc27 - changes the Boxes default video adapter for new VMs to virtio, on F27.
* https://bodhi.fedoraproject.org/updates/FEDORA-2017-35a8ab46d9 - kernel-4.13.9-300.fc27 - appears to fix the flickering, but Kamil reports that it causes an issue with the cursor in GDM.

Also note that we need a gnome-boxes build with a change to address another blocker bug, #1164492 . There is an update for that - https://bodhi.fedoraproject.org/updates/FEDORA-2017-fc8a65f619 - which is gnome-boxes-3.26.1-4.fc27, including the virtio default change.

So we need to decide, do we really want to go ahead with the Boxes change to virtio by default? If not, we need someone to withdraw the 3.26.1-3.fc27 and 3.26.1-4.fc27 updates, and submit a 3.26.1-5.fc27 which removes the virtio change but keeps the libvirt-daemon-config-network dependency change.

Also, we need to find out if other people see the cursor issue that Kamil sees, with a VM using qxl and the 4.13.9-300.fc27 kernel.

Thanks folks!

Comment 69 Fedora Update System 2017-10-26 01:10:43 UTC
kernel-4.13.9-100.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-af9174446e

Comment 70 Fedora Update System 2017-10-26 01:32:03 UTC
kernel-4.13.9-200.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e8390ff6c3

Comment 71 Joachim Frieben 2017-10-26 04:52:38 UTC
No mouse pointer issue here with Fedora 27 virtual guest running in virt-manager on Fedora 27 host (both systems: GNOME (on Wayland) session, kernel-4.13.9-300.fc27) with AMD Radeon RV620 video device.

Comment 72 Fedora Update System 2017-10-26 11:52:13 UTC
kernel-4.13.9-200.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 73 Fedora Update System 2017-10-30 01:52:52 UTC
kernel-4.13.9-300.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 74 František Zatloukal 2017-10-30 11:32:34 UTC
I've experienced the mouse pointer issue with QXL and kernel-4.13.9 in gdm. However, clicking on username fixed the issue and mouse pointer was working just fine from that point (even in gdm).

Comment 75 Fedora Update System 2017-10-30 14:01:17 UTC
kernel-4.13.10-100.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ebab38baf6

Comment 76 Fedora Update System 2017-10-30 16:42:41 UTC
kernel-4.13.10-100.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ebab38baf6

Comment 77 Adam Williamson 2017-10-30 21:42:50 UTC
I think we have pretty solid info now that the F27 update has indeed fixed the bug reported here. As we're still waiting on the F25 update I won't close this report, but I am dropping the blocker metadata.

The cursor issue should probably be reported - and, if appropriate, submitted and considered for blocker / FE status - separately. Kamil, could you do that? Thanks!

Comment 78 František Zatloukal 2017-10-31 13:09:39 UTC
I've created a small patch[0] for virt-manager to use virtio by default. 

You can try koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=22825614

[0] https://github.com/frantisekz/virt-manager/commit/280a30b5c87ed54cfb3368525d0412c3d6904b0e

Comment 79 Fedora Update System 2017-11-03 13:45:13 UTC
kernel-4.13.10-100.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 80 Fedora Update System 2017-11-11 02:56:01 UTC
gnome-boxes-3.26.1-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 81 Joachim Frieben 2017-12-01 05:53:13 UTC
When booting Fedora 27 with kernel-4.14.2-300.fc27, the flicker issue is back which indicates that the recent QXL fixes are missing in the test-day kernel.


Note You need to log in before you can comment on or make changes to this bug.