I've encountered this with virt-manager too.

it is ok with virt-viewer / remote-viewer

The issue is related to the 'resize-guest' property of the spice display widget. Attempts to resize only happen when the spice-vdagent is running, that's why the issue disappears.

Patch posted: http://lists.freedesktop.org/archives/spice-devel/2015-October/022730.html

Heavy flickering for (current) Fedora 23 Wayland guest in a (current) Fedora 23 host making the desktop completely unusable.

Pavel, did this patch ever make it upstream? I don't see it in git

It didn't. I will look into it again..

scratch build containing the patch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13408204

(In reply to Pavel Grunt from comment #7)
The patched package works as extended, thanks! Please ship a build for Fedora 24, too.

(In reply to Pavel Grunt from comment #7)
The patched package works as intended, thanks! Please ship a build for Fedora 24, too.

Created attachment 1139230 [details]
Patch for spice-gtk-0.31-1.fc24 in order to avoid wayland guest flickering

Wayland guest flickering likewise affects current Fedora 24 with package spice-gtk3-0.31-1.fc24. The attached patch applies the changes from comment 4 to the latter.

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

spice-gtk-0.30-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-88264ad5cc

spice-gtk-0.31-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c7ad5f2566

spice-gtk-0.31-2.fc24 has been pushed to the Fedora 24 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-2016-c7ad5f2566

Are we supposed to update the guest or the host (or both)? Updating the host to spice-gtk-0.30-2.fc23 didn't cause any improvements. Guest is currently using latest rawhide.

The patch added in spice-gtk-0.31-2.fc24 differs from that applied in the koji sratch build with task ID 13408204 introduced in comment 7, and unlike the former, it has -no- effect.

(In reply to J. Haas from comment #15)
Updating the host system is both necessary and sufficient. Alas, the working scratch build from comment 7 has been removed from koji in the meantime.

spice-gtk-0.30-2.fc23 has been pushed to the Fedora 23 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-2016-88264ad5cc

spice-gtk-0.30-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Bug is not fixed in spice-gtk-0.30-2.fc23.

Issue has reported anew as bug 1330824 for Fedora 24 (should also cover Fedora 23).

Yeah, sorry about that, I pushed the update to stable by mistake, I thought I cancelled, but apparently this failed ;)

Unless I am wrong, it is not correct to reopen a bug report closed with resolution ERRATA. Therefore, I have filed bug 1330824, albeit for Fedora 24.

(In reply to Pavel Grunt from comment #4)

Please keep in mind that the -successful- scratch build

  http://koji.fedoraproject.org/koji/taskinfo?taskID=13408204

did -not- include the faulty patch committed upstream at

  https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=ec6bfc00f81afddbdcc0fac86d7039385d89c6b6

but rather the modification suggested in message http://lists.freedesktop.org/archives/spice-devel/2015-October/022730.html.

spice-gtk-0.31-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Reopened again, as spice-gtk-0.31-2.fc24 is still affected. If you want to use the other bug feel free to close this again.

*** This bug has been marked as a duplicate of bug 1330824 ***

*** Bug 1330824 has been marked as a duplicate of this bug. ***

FWIW I can still reproduce with virt-manager and spice-gtk3-0.31-2.fc24.x86_64, so like Joachim said there must be something wrong with the backport

FYI, I cannot reproduce the issue, using Fedora 22 (spice-gtk3-0.30-1.fc22.x86_64) or either RHEL7.2 (spice-gtk3-0.26-5.el7.x86_64) hosts with Fedora 24 guest (spice-vdagent-0.16.0-3.fc24.x86_64).

I can report it's still happening on Fedora 24 (just-released) guest on CentOS/RHEL7.2 host.

Issue still present for the latest rawhide update spice-gtk-0.32-1.fc25.

Still seeing this with a Fedora 24 guest.

Hi, I took a look into DRM_QXL help:
 QXL virtual GPU for Spice virtualization desktop integration.
 Do not enable this driver unless your distro ships a corresponding 
 X.org QXL driver that can handle kernel modesetting.

So has Fedora running GNOME on Wayland X.org QXL driver that can handle kernel modesetting ?

workaround (solution?):
I also found out that virtio graphic doesn't have this flickering problem and support features like automatic resizing. Please switch from Video QXL to Video virtio. You can use `virsh edit` or virt-manager for it.

Component xorg-x11-drv-qxl is clearly not the right one, because it is used by Xorg alone and -never- by Xwayland. Kernel modesetting in both cases is provided by the kernel DRM modules, here

  /usr/lib/modules/`uname -r`/kernel/drivers/gpu/drm/qxl/qxl.ko.xz .

I would rather think that the default graphics device in QEMU needs to be set to virtio-gpu.

(In reply to Pavel Grunt from comment #34)
Using virgl instead of QXL indeed suppresses screen flicker. Instructions can be found at http://www.spice-space.org/spice-user-manual.html. To summarize:

"You need to add a virtio-gpu video device to your virtual machine instead of QXL.

<video>
  <model type='virtio' heads='1'>
    <acceleration accel3d='yes'/>
  </model>
</video>

Then you need to enable OpenGL on your SPICE graphics node:

<graphics type='spice' autoport='no'>
  <gl enable='yes'/>
</graphics>".

Running a Fedora 24 guest on a Fedora 25 host, the machine fails to start up in enforcing mode because of bug 1364075. After switching to permissive mode, the virtual machine starts up as expected, and virgl direct rendering is enabled:

"..
 Extended renderer info (GLX_MESA_query_renderer):
     Vendor: Red Hat (0x1af4)
     Device: virgl (0x1010)
     Version: 12.0.1
     Accelerated: yes
 .."

However, as long as QXL is configured as the default device, comment 34 provides nothing more than a workaround. I do recall that the flicker issue -was- successfully settled as per comment 7, but the patch was not applied correctly upstream. 
With a private patched build of spice-gtk-0.31, I have been able to run flicker-free GNOME on Wayland guest sessions with QXL on Fedora 24 and Fedora 25 host systems ever since.

(In reply to Pavel Grunt from comment #34)
Using virgl with direct rendering seems to be fairly unstable and resizing also does not seem to work. The results reported in comment 34 may rather refer to virgl w/o direct rendering. This mode can be obtained by setting <gl enable=no'/>.

(In reply to Joachim Frieben from comment #37)
> (In reply to Pavel Grunt from comment #34)
> Using virgl with direct rendering seems to be fairly unstable and resizing
> also does not seem to work. 
Works fine in my system
> The results reported in comment 34 may rather
> refer to virgl w/o direct rendering. This mode can be obtained by setting
> <gl enable=no'/>.

I didn't mention virgl in my comment.

Changing video node (using `virsh edit`) to:

    <video>
      <model type='virtio' heads='1' primary='yes'/>
    </video>

is enough

Proposed as a Blocker for 25-final by Fedora user jonha using the blocker tracking app because:

 Violates the following criterion for the Gnome Boxes app:

"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. "

I'd consider creating and using a Fedora 25 guest the most basic functionality test and if the screen is flickering every second or so, it's clearly not usable at all.

Alternatively could block on the " Guest on current stable release " beta criterion.

FWIW I agree with the blocker status: this bug makes it extremely difficult to use Fedora in Boxes VMs. Good luck so much as launching an app, because the shell overview gets dismissed every second when the flicker occurs, so you need to be very fast with the mouse in order to launch anything from favorites with the mouse. I haven't been able to start any app not in favorites, because it's too far to go with the mouse and I can't type a search quickly enough.

(In reply to Michael Catanzaro from comment #40)
I have resorted to either switching to virtio-gpu or simply launching the virtual machine in "basic graphics mode" which amounts to adding "nomodeset" to the kernel boot options.

Boxes can/should create vms with the virtio graphics which works fine with wayland and (compared to qxl) it supports 3D.

There are patches upstream for that, see https://bugzilla.gnome.org/show_bug.cgi?id=762727

(In reply to Pavel Grunt from comment #42)
Video device QXL is a valid choice which needs to be supported even in the hypothetic case where virtio-gpu became the default virtual video device. Currently, using video device virtio-gpu requires manual editing of some XML file which can only be considered a workaround for advanced users.

In current Fedora 24, VirGL 3D is inhibited by gnome-boxes which has been reported in bug 1367660; because of bug 1337333, VirGL 3D can only be used in permissive SELinux mode in both of Fedora 24 and Fedora 25 which is definitely a showstopper.

*** Bug 1372434 has been marked as a duplicate of this bug. ***

Discussed during the 2016-09-12 blocker review meeting: [1]

The decision to delay the classification of this as a bug was made as we're not entirely clear on the circumstances in which this bug happens or the difficulty of the workaround(s); more information is required before any classification can be made.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-09-12/f25-blocker-review.2016-09-12-16.01.txt

To clarify a few points from the blocker meeting:

- It doesn't matter if the host uses Wayland or X11, what's important is that the guest uses Wayland.

- Still reproducible using a F25 Alpha 2 Workstation (Wayland) guest on a standard up-to-date F24 Workstation (X11) host.

- Still reproducible using a live F25 Alpha 2 Workstation (Wayland) guest on a live F25 Alpha 2 Workstation host (Wayland)

Tried on multiple systems, not sure why you couldn't reproduce this.

Bad screencast: http://webm.land/w/cZJP/

The flickering isn't really visible and it's subtle anyway, but it will "defocus" all applications and close the application launcher (if it's open) every second or so.

(In reply to J. Haas from comment #46)
This issue is easily reproducible as outlined in muliple comments to this bug report. Now that Fedora 25 is launching a "GNOME" (on Wayland) session by default, it has essentially become inescapable. It is sufficient to boot from a Fedora 25 live image prior or equal to Fedora-Workstation-Live-x86_64-25-20160909.n.0.
Because of bug 1374028 which causes a failure of Xwayland and Xorg to be used forcibly instead in a virtual machine using the QXL video device, live images equal or later than Fedora-Workstation-Live-x86_64-25-20160910.n.0 do -not- exhibit any flicker. This may currently mislead a thoughtless observer.

(In reply to Joachim Frieben from comment #47)
> Because of bug 1374028 which causes a failure of Xwayland and Xorg to be
> used forcibly instead in a virtual machine using the QXL video device, live
> images equal or later than Fedora-Workstation-Live-x86_64-25-20160910.n.0 do
> -not- exhibit any flicker. This may currently mislead a thoughtless observer.

This was the critical piece of information. I tried with Fedora-Workstation-Live-x86_64-25-20160907.n.0.iso, and yes, the flicker is there and gnome overview is unusable (can be reproduced just booting the livecd).

Assignee: this appears to be a QXL/KMS issue showing up in a Wayland session, and the Xorg driver package xorg-x11-drv-qxl has simply nothing to do with it.
What about eventually setting the component to package kernel then?

(In reply to Kamil Páral from comment #48)
> This was the critical piece of information. I tried with
> Fedora-Workstation-Live-x86_64-25-20160907.n.0.iso, and yes, the flicker is
> there and gnome overview is unusable (can be reproduced just booting the
> livecd).

Where would I get this image? I tried installing the latest one, and then downgrading mutter/gnome-shell to avoid bug #1374028, I think my session is a wayland one (gnome-shell is running as a child of /usr/libexec/gdm-wayland-session gnome-session) but I'm not seeing flickering (f24 host).

(In reply to Christophe Fergeau from comment #50)
You can grab the latest working image at https://kojipkgs.fedoraproject.org/packages/Fedora-Workstation-Live/25/20160909.n.0/images/Fedora-Workstation-Live-x86_64-25-20160909.n.0.iso unless you prefer to use the live media of Fedora Workstation 25 Alpha which should also do the job.
Once the live session is running, check whether a process Xwayland or a process Xorg is running - that is all you need to know ..

(In reply to Christophe Fergeau from comment #50)
> Where would I get this image? 

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-25-20160907.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-25-20160907.n.0.iso

> I tried installing the latest one, and then
> downgrading mutter/gnome-shell to avoid bug #1374028, I think my session is
> a wayland one (gnome-shell is running as a child of
> /usr/libexec/gdm-wayland-session gnome-session) but I'm not seeing
> flickering (f24 host).

You can identify the type of session like this:
https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Identifying_the_session_type_in_runtime

Discussed at 2016-09-19 blocker review meeting: [1]. 

We decided to punt the decision: Currently F25 uses X11 in Boxes, but should the switch to Wayland be made in the future, this will inhibit the user from launching applications. If Wayland is confirmed, we will classify this bug as an AcceptedBlocker, but until then we will wait on any decision.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-09-19/

(In reply to Petr Schindler from comment #53)
> If Wayland is confirmed, we will classify this bug
> as an AcceptedBlocker, but until then we will wait on any decision.

We haven't announced this anywhere besides the Workstation meeting notes yet, but the final vote was made last Wednesday and it was unanimous to stick with Wayland. So: confirmed.

(In reply to Michael Catanzaro from comment #54)
> We haven't announced this anywhere besides the Workstation meeting notes
> yet, but the final vote was made last Wednesday and it was unanimous to
> stick with Wayland. So: confirmed.

This was not about the default display stack overall, but the display stack used *in Boxes*. Currently Boxes default to X11 probably due to 1374028. If that gets resolved and Boxes start booting F25 under wayland, this will be a blocker.

Changing component to something more appropriate per comment 49.

(In reply to Kamil Páral from comment #55)
With the latest bunch of GNOME updates from a few days ago including mutter-3.21.92-1.fc25, Fedora 25 defaults again correctly to session type "GNOME" (on Wayland) when launched in "Boxes" (gnome-boxes). I had added a corresponding comment in bug 1374028.

*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.

Reassigning to F25 since this is a proposed F25 blocker.

*** Bug 1377566 has been marked as a duplicate of this bug. ***

Since bug 1374028 got resolved, this is now the default behavior in Boxes (tested with Fedora-Workstation-Live-x86_64-25-20160925.n.0.iso). Setting as AcceptedBlocker per comment 53.

Can somebody confirm or deny that this bug is not only causing flicker, but also a blurness? I'm seeing one on a F24→F25 upgraded physical machine (no virtual machine).

(In reply to Christian Stadelmann from comment #61)
That will likely be a different bug, please file a new one and attach screenshots and logs. Thanks.

From reading the comments here, I am confused as to how this is kernel, comment #24 this was working with the scratch build to spice, but the patch in that build is not the patch that got into the release. Reassigning to spice-gtk.

(In reply to Justin M. Forbes from comment #63)
This issue can be attacked from either side: it is correct that there was a patch for an older version of spice-gtk which solved the issue; on the other hand, the virtio-gpu device appears to be completely unhampered and resizing works like a charm. This indicates that the root issue is actually related to the KMS properties of the video kernel module. For that reason it seems more appropriate to look at the QXL kernel module and how kernel mode setting is implemented. Tinkering with spice-gtk is possibly rather a workaround than a true solution.

(In reply to Kamil Páral from comment #62)
> (In reply to Christian Stadelmann from comment #61)
> That will likely be a different bug, please file a new one and attach
> screenshots and logs. Thanks.

Ok, see bug #1379959.

Pavel sent patches to upstream spice list, but they are still under discussion: https://lists.freedesktop.org/archives/spice-devel/2016-October/032555.html

(In reply to Cole Robinson from comment #66)
Can anybody push a koji build of package spice-gtk applying said patch? This does not need approval by upstream, thanks.

*** Bug 1381040 has been marked as a duplicate of this bug. ***

*** Bug 1384036 has been marked as a duplicate of this bug. ***

I finally have a good grasp of what's going on, and have a QEMU patch
and a kernel patch, each of these fixing (or avoiding) this bug.

The short version of it is that nothing host/guest-side is checking
whether a monitors config message received from the client is specifying
a new configuration, and resolution changes done by mutter trigger the
blinking and the sending of a monitors config message, so we get in a
monitors config message -> resolution change -> monitors config message
-> ... loop


Long version:
- a monitors config message is received from the client
- spice-server tells QEMU about it witout looking at its content
- QEMU raises an interrupt to let the guest know about the new config,
  and once again, does not make sure it's different from the current
  one
- the kernel QXL driver gets the new monitors configuration from QEMU
  and notifies userspace about it (as usual, no check whether there were
  actual changes)
- mutter (part of gnome-shell) gets this notification, and reconfigures
  its resolution/monitors (and you already know I'm going to mention
  that it does not check if it's the same as the existing one ;)

This could be all fine and not cause any problems at all, except that
the way mutter/clutter/cogl handle the resolution change does not play
nice with the above.

The resolution change in mutter will be done with calls to drmModeRmFB,
drmModeAddFB, and drmModeSetCrtc.
The drmModeRmFB call will cause the drmModeSetCrtc call to
notify the client about a destroy/create of the primary surface, which
will schedule the sending of a monitors config message one second
later, which will cause the infinite loop with flickering.

I've written a kernel patch for the qxl driver, and a qemu patch, each
of these patches fixes the bug on its own. They only make sure not to
notify userspace or the guest about changes in the monitor configuration
if nothing changed. This avoids this annoying loop.

Now, I don't know whether the way mutter uses the drm API is correct, or
if a fix belongs there too. I also don't know whether there is another
bug to fix in the QXL driver which would avoid this destruction/creation
of the primary surface in qxl_crtc_mode_set(). Any input there would be
welcome :)


I'm planning to send these patches upstream unless there is strong disagreement
against them. In the mean time, they can probably be added to the f25
packages to avoid this annoying regression (I'd go with the kernel
patch).

Created attachment 1210590 [details]
Patch for the QXL kernel driver

Created attachment 1210592 [details]
QEMU patch

(In reply to Christophe Fergeau from comment #71)
Thanks a lot for your great work!

1. The patch from comment 71 applies cleanly and solves the issue successfully.
2. This seems to confirm my comment 64 that the root cause was in the QXL kernel driver (remember that the virtio-gpu video device was not hampered by this issue at all), and that tinkering with spice-gtk etc. was rather a workaround than a proper solution. I therefore strongly recommend dropping the QEMU patch altogether and retaining the kernel patch from comment 71 alone.

I'll do a qemu build tomorrow to pull in Christophe's qemu patch. I've filed a separate bug to track pulling in the kernel fix:

https://bugzilla.redhat.com/show_bug.cgi?id=1385956

qemu-2.7.0-6.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-2016-190e517826

After the last update, I've booted F25 Alpha to GNOME Boxes and it finally works without flickering.

qemu-2.7.0-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

hi, thank for your work, but the issue isn't fixed for me. Host and guest are up to date. Here is a short video:
https://jibecfed.fedorapeople.org/partage/Capture%20d'%c3%a9cran%20vid%c3%a9o%20de%2022-10-2016%2017:57:54.webm

(In reply to jibecfed from comment #78)
> hi, thank for your work, but the issue isn't fixed for me. Host and guest
> are up to date. Here is a short video:
> https://jibecfed.fedorapeople.org/partage/
> Capture%20d'%c3%a9cran%20vid%c3%a9o%20de%2022-10-2016%2017:57:54.webm

The problem is not in qemu which is inside the guest, it's in the qemu of the host.

> The problem is not in qemu which is inside the guest,
> it's in the qemu of the host.

I have a fully updated fedora 24 host with a fully updated fedora 25 guest in gnome-boxes, and the problem still occurs. Why was it closed if there was only an update to the qemu package in "fc25" (from what it seems in comment 77)?

I also want to ask if this fix can be included in Fedora 24. Launching F25 on a F24 host seems to be a common use case for testing the new release for example.

There seems to be an update for F24 claiming to fix this in updates-testing repo:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5fc14b30

Can you try, and add karma if it fixes the problem for you? Thanks.

(In reply to Cole Robinson from comment #74)
> I'll do a qemu build tomorrow to pull in Christophe's qemu patch. I've filed
> a separate bug to track pulling in the kernel fix:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1385956

For the record, the QEMU patched is on its way upstream https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg00018.html
It's a revised version of the patch which was attached to this bug/added to the package though https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07483.html

(In reply to Christophe Fergeau from comment #83)
> (In reply to Cole Robinson from comment #74)
> > I'll do a qemu build tomorrow to pull in Christophe's qemu patch. I've filed
> > a separate bug to track pulling in the kernel fix:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1385956
> 
> For the record, the QEMU patched is on its way upstream
> https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg00018.html
> It's a revised version of the patch which was attached to this bug/added to
> the package though
> https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07483.html

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1392239 to track backporting/replacing the patch when it lands upstream

Since this bug is fixed, how about removing the CommonBugs and Wiki entry https://fedoraproject.org/wiki/Common_F25_bugs#boxes-flickering ?

@Christian: Done.

(In reply to Christian Stadelmann from comment #85)
> Since this bug is fixed, how about removing the CommonBugs and Wiki entry

We always go through the wiki and update it between Go/No-Go and official release. Of course feel free to update it any time, no problem, just make sure the update has been pushed stable.