(In reply to comment #0)
> Steps to Reproduce:
> 1. Connect to a machine 
> 2. Open a second display
> 3. Start gnome-display-properties
> 4. Select 1280x768 on primary display, apply
> 5. Select 1280x760 on primary display, apply

I tried this but I cannot reproduce. Can you please retry on a freshly booted vm ? If you can then
still reproduce we need to figure out what is going on...

Created attachment 678157 [details]
log from the VM

Sometimes it doesn't even reduce the size, but keeps flickering, trying to change the resolution somehow. You can see at the end of log when it tried to go from 1280x768 to 1280x760 several times per second.

Created attachment 678158 [details]
Output from remote-viewer.

(In reply to comment #3)
> Created attachment 678157 [details]
> log from the VM
> 
> Sometimes it doesn't even reduce the size, but keeps flickering, trying to
> change the resolution somehow. You can see at the end of log when it tried
> to go from 1280x768 to 1280x760 several times per second.

Hmm, it seems as if gnome-display-settings is fighting with itself, here is what
I believe is happening:

1) gnome-display-settings changes the size from 1280x768 to 1280x760
2) Something (likely gnome-display-settings) asks the driver for a new modelist
3) gnome-display-settings sees this new modelist as a new monitor, and
has remembered that the setting for this monitor is 1280x768
4) gnome-display-settings changes the setting back to 1280x760
5) rince repeat with 1280x768 <-> 1280x760 swapped

Is this with the client full-screen or maximized, or just regular windowed?

After doing the following in gnome-display-settings:
1) select 1280x768 => apply
2) select 1280x760 => apply
3) select 1280x768 => apply

I can make the switch between the 2 happen by running "xrandr" from the
cmdline, as calling "xrandr" cause the driver to be asked for an updated
modelist.

But by default neither gnome-display-setting nor the agent will ask the
driver for an updated modelist. So this should not be happening ...

Ah, ok I can reproduce now. To reproduce this requires:
1) open a second display
2) In gnome-display-settings do;
 1) select 1280x768 => apply
 2) select 1280x760 => apply
 3) select 1280x768 => apply

And then I get the rapid changing between the 2 settings. Will investigate
this further.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

(In reply to comment #5)
> Ah, ok I can reproduce now. To reproduce this requires:
> 1) open a second display
> 2) In gnome-display-settings do;
>  1) select 1280x768 => apply
>  2) select 1280x760 => apply
>  3) select 1280x768 => apply

Ok, so what is happening here is the following:

1) When making changes on a *dual* monitor setup gnome-display-settings calls
XRRGetScreenResources rather then XRRGetScreenResourcesCurrent, causing a
call to xf86-video-qxl's modelist update function

2) xf86-video-qxl's modelist update function function gives a modelist for the monitor with
all standard modes from the rom header + the current mode with the preferred mode flag set

3) What happens now is:

a) Running at 1280x768, modelist is standard + preferred 1280x768, lets call this modelist1
b) change mode to 1280x760, gnome-settings-daemon remembers this as the user-selected mode for the monitor with modelist1
c) modelist gets updated, gnome-settings-daemon now sees a modelist of standard + preferred 1280x760, sees this as a new monitor with modelist2
d) change mode to 1280x768, gnome-settings-daemon remembers this as the user-selected mode
    for the monitor with modelist2
e) modelist gets updated, gnome-settings-daemon now sees a modelist of standard + preferred 1280x768, sees this as the return of the monitor with modelist1, has a user set mode of 1280x760 for this
f) gnome-settings-daemon changes to the user set mode for this monitor of 1280x760
g) modelist gets updated, gnome-settings-daemon now sees a modelist of standard + preferred 1280x760, sees this as the return of the monitor with modelist2, has a user set mode of 1280x768 for this
f) gnome-settings-daemon changes to the user set mode for this monitor of 1280x768, goto
   e) and loop infinitely

I propose to fix this by not adding the current-mode as preferred mode. Instead always set 1024x768 as preferred mode to stop the initial mode too big problem for which the patch, adding the setting the current-mode as preferred mode, was added.

This is fixed by this patch which has been posted upstream:
http://lists.freedesktop.org/archives/spice-devel/2013-January/012137.html
Note that upstream will likely go for this, more complete, patch which also fixes some other issues:
http://lists.freedesktop.org/archives/spice-devel/2013-January/012125.html

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

I tried the scratch build you posted. Thought you might to be interested in knowing, that it introduces some more problems. It doesn't flicker permanently now, but instead messes up resolutions settings at a few places (so far found two)
  -- opening a second display resizes the first display (opening/closing channels in general)
  -- following the original reproducer results in a resolution that user never intended to set.

Strangely though, the problems aren't permanent, but can be reproduced just once per session (or VM power cycle).

Won't open any new bugs just yet as that wasn't a "serious" build.

(In reply to comment #11)
> I tried the scratch build you posted. Thought you might to be interested in
> knowing, that it introduces some more problems. It doesn't flicker
> permanently now, but instead messes up resolutions settings at a few places
> (so far found two)
>   -- opening a second display resizes the first display (opening/closing
> channels in general)

Yes I've seen this too, but if we want to fix the flickering problem, there is not much we can do here, for some reason sometimes when a new monitor shows up, or one goes away, gnome-settings-daemon decides to also re-init the existing ones. Quite annoying I agree, once we have an official build with the fix we should file a bug against gnome-settings-daemon for this.

Note that if your windows have a fixed size, ie they are maximized or fullscreen, the agent will correct the mode after gnome-settings-daemon has done its damage. But with "floating" windows, the gnome-settings-daemon re-init of existing displays will cause the window to resize, and then the agent won't make any changes since the new window size matches the new resolution set by g-s-d.

>   -- following the original reproducer results in a resolution that user
> never intended to set.

I cannot reproduce this one, there also have been quite a few fixes elsewhere, notably in
the agent, spice-gtk and virt-viewer, Possibly one of the fixes there fixes this.

commit beccf8e81ea6bb4c86bcaf3cd4aac5e18f6d3f0d claims to have fixed this.

(In reply to Alon Levy from comment #13)
> commit beccf8e81ea6bb4c86bcaf3cd4aac5e18f6d3f0d claims to have fixed this.

This commit is part of xf86-video-qxl 0.1.1 which we rebased to for rhel 6.6