OK this seems to be caused by mutter failing to set the mode, so the mode gets set again, mutter fails again ...

If I try to set the mode while running in virt-manager it does not show an error but does not set the mode (keeps the current one) and asks me whether I want to keep the changes ... which makes no sense because it did not change anything.

Ok so...

Do you see a warning in the logs, something like
Configuring CRTC %d with mode %d (%d x %d @ %f) at position %d, %d and transfrom %u failed
?

Do we get an error from X or qxl (-EINVAL maybe? -ENODEV?), or some indication that modesetting is impossible?

Failing that, can we have qxl only add one mode to the list, and fake CRTCs in a way we don't try impossible configurations?

(In reply to comment #2)
> Ok so...
> 
> Do you see a warning in the logs, something like
> Configuring CRTC %d with mode %d (%d x %d @ %f) at position %d, %d and
> transfrom %u failed
> ?

No.

> Failing that, can we have qxl only add one mode to the list, and fake CRTCs in
> a way we don't try impossible configurations?

Seems like the driver on F20 is broken. Even setting a mode with xrandr has no effect.

<airlied_> drago01: probably me
<drago01> airlied_: https://bugzilla.gnome.org/show_bug.cgi?id=706735 and https://bugzilla.redhat.com/show_bug.cgi?id=1001175
<Services> Bug 706735: normal, Normal, ---, mutter-maint, UNCONFIRMED, Flickerfest in boxes
<Services> Bug 1001175: unspecified, unspecified, ---, alevy, NEW , Cannot change mode
<airlied_> drago01: attach and Xorg log after you tried a change
<drago01> airlied_: ok
<drago01> airlied_: http://fpaste.org/34928/54665613/
<drago01> airlied_: seems like something resizes it back to the other mode
<airlied_> drago01: yeah I thought that might happen
<airlied_> care to try without g-s-d running :-)
<drago01> maybe gnome-settings-daemon and mutter both try to handle it now
* drago01 disables the xrandr plugin
<drago01> airlied_: no it is not gnome-settings-deamon
* drago01 tries with metacity
<drago01> airlied_: yes works
<drago01> airlied_: so gcampax is the one to blame not you ;)

<airlied_> drago01: well its kinda complicated
<airlied_> we used to have a licence violating hack in qxl to workaround it, but we had to remove it
<airlied_> virtual graphics devices don't interact well with desktop environments
<drago01> airlied_: what did the hack do?
<airlied_> http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=96e6be278896ea6ecb43984d7e6fe8eea3b75ab1
<airlied_> scroll down to where it explains itself
<airlied_> I threw up a little when I discovered it, that and nobody had though to fix it properly
* airlied_ ist jetzt bekannt als airlied
<drago01> oh
<drago01> so should reopen the qxl bug then?
<airlied> the thing is I think we should fix it on the client side but I'm not 100% sure
<airlied> the spice guys were meant to investigate more, but seemed to have dropped it on the floor
<drago01> ok, which brings us back to the blame question ;)
<airlied> I'll see if I can take another look today, but I was going to suggest for Virtual outputs g-s-d does something different
<airlied> but I'm not 100% sure what exactly is going wrong
<drago01> g-s-d is not handling it anymore
<drago01> code moved to mutter to add a wayland abstraction
<drago01> maybe something broke here
<drago01> that's why I started by filing a mutter bug
<airlied> nah I suspect its just as broken as before,
<airlied> I just find it wierd if both qxl and vbox need the same driver hacks

For the record, I tried ostree today in gnome-boxes master, and it worked normally.

It was using the qxl driver and reporting a number of semi-standard modes, of which it picked 1024x768. Data exposed by mutter looked correct.

(In reply to comment #6)
> For the record, I tried ostree today in gnome-boxes master, and it worked
> normally.
> 
> It was using the qxl driver and reporting a number of semi-standard modes, of
> which it picked 1024x768. Data exposed by mutter looked correct.

Did you try to change the mode? Does it change the mode when you resize boxes? Also which version of the qxl driver? The hack that has been copied from vbox had to be dropped because it is GPL (and the qxl driver is MIT). So if you have an older driver it should work.

After trying this more, in ostree, without spice-vdagent, I can change the mode from the control center, and it has the expected effect.
Also, resizing the boxes window does not change the mode.

I'm tempted to say this is a spice-vdagent problem, but I need to test F20, which will take a while (my F20 vm is busted and won't start...)

Created attachment 253738 [details]
Screencast

As you can see in that video just booting live is enough to trigger it ...

F19 Host - F20 guest

OK after some debugging we found out that this happens when qemu emulates "machine pc-0.15" (older vm) but works fine with "machine pc-i440fx-1.4" (newly created VM). 

In the former case it falls back to use user mode qxl while the later uses kms.

The former fails with:
Sep 02 07:18:18 localhost kernel: [drm:qxl_pci_probe] *ERROR* qxl too old, doesn't support client_monitors_config, use xf86-video-qxl in user mode
Sep 02 07:18:18 localhost kernel: qxl: probe of 0000:00:02.0 failed with error -22

Created attachment 253843 [details] [review]
MonitorXrandr: check the event timestamps before reconfiguring

If, checking the event timestamps, we see that a new configuration
was explicitly requested by an another XRandR client, don't proceed to
apply the intended configuration again, even if looking at the
EDIDs it appears that the outputs changed.
This works around some buggy Xorg drivers (qxl, vbox) that generate
a new serial number everytime the user resizes the host window.

Review of attachment 253843 [details] [review]:

Looks good and seems to work fine here (no more flicker). Didn't test it on real hw though.

For the record:

<gcampax> drago01, found the problem: broken driver is generating a new edid for every monitor, faking a new serial number all the time
<gcampax> we're actually handling it like an hotplug, and generating a default config for it
<gcampax> weird gnome-settings-daemon did not have the same behaviour in the past
<drago01> oh
<drago01> gcampax: well there has been a hack inside the driver in tze
<drago01> the past
<gcampax> drago01, yes, but the thing is, g-s-d should have done the same in a f19 guest, see the hotplug event and prepare a new default config, choosing the preferred mode
<drago01> gcampax: err isn't that commit doing exactly what you said was broken?
<drago01> gcampax: it creates a new edit with a new serial for a mode change
<drago01> gcampax: so the revert would fix it? or am I mssing something
<gcampax> drago01, which commit?
<drago01> gcampax: http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=96e6be278896ea6ecb43984d7e6fe8eea3b75ab1
<drago01> gcampax: see qxl_output_edid_set
<gcampax> drago01, yeah, so the thing is, when we see a different (vendor, product, serial) triple, we think an hotplug happened, and we try to set the mode to the preferred one
<gcampax> which is 1024x768
<gcampax> then someone else (spice-vdagent?) sets the mode again to the window size
<gcampax> and this in a loop
<drago01> gcampax: yeah but that commit got reverted so a recent qxl shouldn't be doing that right?
<gcampax> that commit removed all the edid code, so that commit fixed the issue, because we no longer think that ever randr event we get is an hotplug
<gcampax> drago01, but the driver in f20 is definitely exposing an edid, so that commit is not in the f20 pkg
<drago01> gcampax: indeed http://koji.fedoraproject.org/koji/buildinfo?buildID=453962
<drago01> gcampax: the commit is from 2013-07-08
<drago01> gcampax: the package is a snapshot from jul 03

Review of attachment 253843 [details] [review]:

Seems to break the previously working case ...

<drago01> gcampax: ok, so your patch fixes the flicker here
<gcampax> drago01, does it also resize properly?
<drago01> gcampax: yes
<drago01> gcampax: it works like expected
<gcampax> drago01, cool
<gcampax> does it work with kms-qxl too?
<drago01> let me test
<drago01> gcampax: seems not ...
<drago01> gcampax: installed the new mutter
<drago01> gcampax: logout flicker and then black screen
* drago01 tries again
<gcampax> drago01, let me look at it...
<drago01> gcampax: alt-f2 r works
<drago01> gcampax: seems to die at gdm

After further investigation, we concluded the crashes with qxl-kms
were unrelated. Still needs some work to get resizes in qxl, but
doesn't necessarily belong to mutter.

Attachment 253843 [details] pushed as 9678a41 - MonitorXrandr: check the event timestamps before reconfiguring