Verified fail with following build:

virt-viewer-0.5.2-18.el6_4.1.x86_64
spice-glib-0.14-7.el6.x86_64
spice-vdagent-0.12.0-4.el6_4.1.x86_64(both host and guest)
spice-server-0.12.0-12.el6.x86_64
spice-gtk-0.14-7.el6.x86_64
spice-gtk-python-0.14-7.el6.x86_64
kernel-2.6.32-358.2.1.el6.x86_64(both host and guest)
qemu-kvm-0.12.1.2-2.356.el6_4.2.x86_64

Common steps:
1. Prepared a machine with 2 physical monitors with different resolutions.
2. Install a spice guest and update spice-vdagent and kernel

Specific Steps:

Scenario I
3. Connect to guest with virt-viewer.
4. Click view->displays->display2 to enable 2nd display.
5. Click view->full screen.(normally, this step will be OK)
6. Leave full screen and disable 2nd display.
7. Resize form of display 1 to make it change resolution.
8. Re-enable display 2.
9. Go to full screen.
10. Repeat 4-9 several times.

Result of scenario I:
1. Over 10%, 2 displays will have same resolution

Scenario II
3. Connect to guest with virt-viewer.
4. Click view->displays->display2 to enable 2nd display.
5. Click view->full screen.(normally, this step will be OK)
6. In guest, click System->Preferences->Display
7. Do nothing, just click apply and then choose keep this configuration.
8. Close virt-viewer.
9. Reconnect to the guest.
10. Go to full-screen

Result of scenario I:
1. At least 70%, 2 displays will have same resolution

So change status to ASSIGNED

Hi,

Can you try again please, and this time make sure that the window for the 2nd monitor is completely on the second monitor before you go fullscreen?

Note you will need to re-do this every time before you go fullscreen as the window-manager may place
it somewhere else.

Thanks,

Hans

I tried this bug again and found something different. List steps here

Common steps:
1. Got a machine with 2 physical monitors, 1st is 1280x1024, 2nd is 1920X1080
2. Start the guest and connect to it through virt-viewer
3. Start 2nd console.
4. Drag 2nd form to 2nd(1920X1080) monitor, leave 1st form on 1st(1280X1024) one
5. Go to full screen. (Everything is OK for now)
6. In guest, click System->Preferences->Display
7. Do nothing, just click apply and then choose keep this configuration.
8. Close virt-viewer.
9. Reconnect to the guest.

After step 9, window-manager will place 1st form on 2nd(1920X1080) monitor, 2nd form on 1st(1280X1024) monitor.

Specific steps:

Scenario I:
10. Do nothing, just go to full-screen.
Result of scenario I:
1. Bug will reappear, 2 forms are placed on 2 monitors in full screen mode. But all have 1920X1080 resolution.

Scenario II:
10. Drag 2nd form to 2nd(1920X1080) monitor, 1st form to 1st(1280X1024) monitor.
11. Go to full-screen.
Result of scenario II:
1. Everything is OK.

(In reply to comment #8)

<snip>

> After step 9, window-manager will place 1st form on 2nd(1920X1080) monitor,
> 2nd form on 1st(1280X1024) monitor.

Ultimately windows get placed by the window-manager, we tell it to restore the original window coordinates when leaving fullscreen, but it is free to ignore this :|

> Scenario I:
> 10. Do nothing, just go to full-screen.
> Result of scenario I:
> 1. Bug will reappear, 2 forms are placed on 2 monitors in full screen mode.
> But all have 1920X1080 resolution.
> 
> Scenario II:
> 10. Drag 2nd form to 2nd(1920X1080) monitor, 1st form to 1st(1280X1024)
> monitor.
> 11. Go to full-screen.
> Result of scenario II:
> 1. Everything is OK.

Ok, this confirms what I already was afraid of, when we go fullscreen we move window 1 to monitor 1, window 2 to monitor 2, etc. Then when we get a configure event we query the monitor the window is on, and apparently sometimes we get the configure event before the window has actually been moved to the right monitor.

So what you're seeing now really is another (related bug). Before the fixed build we would always use the resolution of the 1st monitor for all guest-monitors, now we do the right thing, but sometimes we hit this race...

I've tried to reproduce the with the latest spice-gtk + remote-viewer on F-18, and I could not reproduce it there. So this is likely gtk2 and/or metacity specific. I'll try to reproduce it with a RHEL-6 client machine next.

I already have an idea how to fix this, but being able to reproduce myself would certainly be helpful to fixing this.

I can reproduce the new problem with the sizes sometimes still being wrong under 6.4, and have written a patchset fixing this. This patchset is included in virt-viewer-0.5.2-18.el6_4.2 -> MODIFIED.

Verified pass with following build:
virt-viewer-0.5.2-18.el6_4.1.x86_64

Steps:
Same as comment 8

Actual result:
Virt-viewer could always work well, both screen have their own resolutions.

So mark this bug as VERIFIED.

(In reply to comment #13)
> Verified pass with following build:
> virt-viewer-0.5.2-18.el6_4.1.x86_64
> 
> Steps:
> Same as comment 8
> 
> Actual result:
> Virt-viewer could always work well, both screen have their own resolutions.
> 
> So mark this bug as VERIFIED.

Sorry, something wrong, build number should be virt-viewer-0.5.2-18.el6_4.2.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0684.html

argh, those patches break --full-screen=auto-conf,

with the new version the windows end up on the first monitor. There is plenty of warnings/critical, so I guess it is related. All work fine with upstream virt-viewer though...