Bug 1129477

Support is upstream.

Relevant commits:
b684a76fa4147ecf5c241476d9c362cfff404c29
539e6724374f22194d38bcab876e48e97517b843
0ca9959f00d4970b4398d48b77fd3f08f78a1855

I test with virt-viewer-0.6.0-5.el7.x86_64:

1. Prepare a spice guest with qxl
#virsh dominfo test
Id:             5
Name:           test
UUID:           d004a4c8-9d71-46d3-9bcc-28ad9eed8df5
OS Type:        hvm
...
2. edit ~/.config/virt-viewer/settings
# vim ~/.config/virt-viewer/setting
[d004a4c8-9d71-46d3-9bcc-28ad9eed8df5]
monitor-mapping=1:3;2:4;3:2

3. start the guest and login it, configure it with only one display
# virsh start test
#virt-viewer test
Click View -> Display -> just enable display

4. reconnect the guest with -f
# virt-viewer test -f

Result:
Only monitor 3 and 4 have display, but the resolution is small, and two displays are same, the displays are mirror screens.
Click "Leave full screen" button, check the display list:
View -> Displays. only display 1 and display 3 are enabled.

The result is not expected as the settings file.
There should be 3 displays on monitor 3, 4, 2.

I will add the screen shot later.

Xrandr for host:
Screen 0: minimum 320 x 200, current 5520 x 1050, maximum 16384 x 16384
DisplayPort-0 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
HDMI-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1152x864       75.0  
   1280x720       60.0     50.0     59.9  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   720x480        60.0     59.9  
   640x480        75.0     60.0     59.9  
   720x400        70.1  
DVI-0 connected 1680x1050+2560+0 (normal left inverted right x axis y axis) 474mm x 296mm
   1680x1050      60.0*+   74.9  
   1600x1000      60.0  
   1280x1024      75.0     72.0     60.0  
   1440x900       75.0     59.9  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0  
   800x600        72.2     75.0     60.3  
   640x480        75.0     72.8     66.7     60.0  
   720x400        70.1  
DVI-1 connected 1280x1024+4240+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1

Created attachment 938735 [details]
screen shot when connect the guest

Created attachment 938737 [details]
click leave fullscreen with display list

Created attachment 938738 [details]
virt-viewer with spice-debug log

CongDong, I wonder if you're hitting another problem (possibly bug 1046458?).

If you remove monitor-mapping configuration for this guest, and then re-run 

  virt-viewer test -f

What is the behavior? Does it successfully enable fullscreen windows for all 4 displays?

According to the log, it appears that virt-viewer is behaving correctly:

(virt-viewer:7567): virt-viewer-DEBUG: Fullscreen config: mapping guest display 0 to monitor 2
(virt-viewer:7567): virt-viewer-DEBUG: Fullscreen config: mapping guest display 1 to monitor 3
(virt-viewer:7567): virt-viewer-DEBUG: Fullscreen config: mapping guest display 2 to monitor 1

...

(virt-viewer:7567): GSpice-DEBUG: channel-main.c:1176 main-1:0: monitor config: #0 1680x1050+2560+0 @ 32 bpp
(virt-viewer:7567): GSpice-DEBUG: channel-main.c:1176 main-1:0: monitor config: #1 1280x1024+4240+0 @ 32 bpp
(virt-viewer:7567): GSpice-DEBUG: channel-main.c:1176 main-1:0: monitor config: #2 1280x1024+1280+0 @ 32 bpp


So I think that the issue is that the guest is not being configured correctly due to some other bug. I'm interested in your results if you only define 1 or 2 displays.  For example:

monitor-mapping=1:3
monitor-mapping=1:3;2:4


(note that the display indices in the log are 0-based, whereas the indices in the config file are 1-based)

(In reply to Jonathon Jongsma from comment #7)
> CongDong, I wonder if you're hitting another problem (possibly bug 1046458?).
> 
> If you remove monitor-mapping configuration for this guest, and then re-run 
> 
>   virt-viewer test -f
> 
> What is the behavior? Does it successfully enable fullscreen windows for all
> 4 displays?

Ah, it's just one display.
So I re-configure the vm:
# virsh edit $vm
<domain type='kvm' id='5' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <qemu:commandline>
    <qemu:arg value='-global'/>
    <qemu:arg value='qxl-vga.vgamem_mb=32'/>
  </qemu:commandline>
</domain>

It shows 4 displays when I disable monitor-mapping this time.

I enable monitor-mapping again:
[d004a4c8-9d71-46d3-9bcc-28ad9eed8df5]
monitor-mapping=1:3;2:4;3:2

# virt-viewer test -f
Three displays come out, display 1 on monitor 3, but display 2 and 3 are all on monitor 4.

If configure monitor-mapping with two displays:
monitor-mapping=1:3;2:4
It works well.

After that I configure monitor-mapping with only one display:
monitor-mapping=1:3

Only one display comes out, but with a very large resolution(but I think the resolution is another problem)

Additional related commits:

f317e950969738783919ea7d7f3a2fa9ddd44c3b
f26a5fe16cc5d71a3edad17026ab35411286b140

Hi CongDong,

Can you get a new spice debug log for the latest package (and describe exactly what happens when you're collecting the log)?

(In reply to Jonathon Jongsma from comment #15)
> Hi CongDong,
> 
> Can you get a new spice debug log for the latest package (and describe
> exactly what happens when you're collecting the log)?

Steps:

 - # virsh start $vm
 - # virt-viewer $vm  and enable 4 displays
     Click "View-> displays -> check on (1,2,3,4) display"
     Close virt-viewer
 - # edit settings file like this
     [9a38373c-bc18-407a-9468-39eb4b1ca9a5]
     monitor-mapping=1:3;2:4
 - # virt-viewer -f $vm --debug --spice-debug

Result:
monitor 3 and monitor 4 are used.
But display 3 and display 1 are at monitor 3
display 4 and display 2 are at monitor 4.

I'll add the spice log and screenshot later

Created attachment 941931 [details]
log for comment 16

Created attachment 941932 [details]
screenshot for comment 16

which version of spice-gtk3 are you testing with?

OK, after some more extensive testing, I have the following observations:

A. I am not ever able to reproduce the behavior described by CongDong (e.g. display 3 and display 1 on monitor 3, display 2 and display 4 on monitor 4)

B. I am able to reproduce something slightly similar  *if and only if* the guest has more monitors enabled than are specified in the config file: display 1 fullscreen on monitor 3, display 2 fullscreen on monitor 4, displays 3&4 on monitor 1 (but not in fullscreen). The frequency of occurrence depends partly on the spice-gtk version. With spice-gtk 0.20, it happens quite often, but with spice-gtk 0.22, it happens perhaps 5% of the time that the conditions mentioned above are met (enabled guest displays > configured displays).

C. When the issue mentioned in (B) occurs, I cannot see any difference in the behavior of the client compared to the times when the issue does not occur. So it seems to be a bug or race condition in the guest/server rather than a bug in the client.

D. I am not able to reproduce the issue *at all* with a windows guest, which suggests that it is probably a bug in the RHEL guest.


Based on my observations, the following seems to be true: with spice-gtk 0.22, the bug only occurs quite rarely, and only when we connect to a rhel guest that currently has more displays enabled than are specified in the config file. If your experience is different than this, please let me know. Otherwise it seems that we should file a new bug to track the race condition in the guest where displays fail to get configured properly

(In reply to Jonathon Jongsma from comment #20)
> which version of spice-gtk3 are you testing with?

spice-gtk3-0.22-2.el7.x86_64

I'll do more test with the latest version.

BTW, what's the OS of your rhel guest?

Created attachment 944945 [details]
virt-viewer + spice-gtk debug log

Scratch build is not available anymore so testing just with what is in nightlies:
virt-viewer-0.6.0-7.el7.x86_64
spice-gtk3-0.22-2.el7.x86_64

The guest display 2 and 3 are on client monitor 4 where only guest display 2 should be (guest 3 should be on client 2 where there is no virt-viewer window).

Created attachment 944946 [details]
screenshot

(In reply to David Jaša from comment #23)
> Created attachment 944945 [details]
> virt-viewer + spice-gtk debug log
> 
> Scratch build is not available anymore so testing just with what is in
> nightlies:
> virt-viewer-0.6.0-7.el7.x86_64
> spice-gtk3-0.22-2.el7.x86_64
> 
> The guest display 2 and 3 are on client monitor 4 where only guest display 2
> should be (guest 3 should be on client 2 where there is no virt-viewer
> window).

picture is worth 1000s of words

Created attachment 944989 [details]
irt-viewer + spice-gtk debug log (better)

(In reply to David Jaša from comment #23)
> Created attachment 944945 [details]
> virt-viewer + spice-gtk debug log

better log (with cleared irrelevant top)

(In reply to David Jaša from comment #26)
> Created attachment 944989 [details]
> irt-viewer + spice-gtk debug log (better)
> 
> (In reply to David Jaša from comment #23)
> > Created attachment 944945 [details]
> > virt-viewer + spice-gtk debug log
> 
> better log (with cleared irrelevant top)

OK, so David's issue is a bit different as well. The guest is enabling the correct number of displays, and (apparently) sizing them correctly, but apparently the client is not placing them on the correct client monitor. I think I need some better logging to figure out why. Is this 100% reproducible?

(In reply to CongDong from comment #22)
> (In reply to Jonathon Jongsma from comment #20)
> > which version of spice-gtk3 are you testing with?
> 
> spice-gtk3-0.22-2.el7.x86_64
> 
> I'll do more test with the latest version.
> 
> BTW, what's the OS of your rhel guest?

I've tested with both rhel6 and rhel7 guests. Both of them behave basically as I've mentioned in comment #21, although rhel7 seems to exhibit the issue mentioned in (B) more often, even with spice-gtk 0.22 (but still, only when extra displays are enabled in the guest when connecting)...

> but apparently the client is not placing them on the correct client monitor.
> I think I need some better logging to figure out why. Is this 100%
> reproducible?

Yes.



Jonathon, would it be able to rearrange guest monitor layout as well to match client layout? E.g.:

monitor-mapping=1:2;2:1 with client layout:

+---+---+
| 1 | 2 |
+---+---+

will produce also guest layout:

+---+---+
| 1 | 2 |
+---+---+

leading to non-contiguous guest desktop in fullscreen:

+------------+-----------+
|------+     |  +--------|
|INDOW |     |  | GUEST W|
|------+     |  +--------|
+------------+-----------+

so the guest layout should be:

+---+---+
| 2 | 1 |
+---+---+


The fix to this issue shouldn't however make bug 1018180 regress.

Hello David,

I was not able to reproduce your non-contiguous guest desktop mentioned above. I tested this configuration and I did find a bug that was initially causing both client windows to end up on the same monitor. I've posted a patch to the virt-tools mailing list to fix this issue [1]. After fixing this issue, It behaves as you expect it to: 

+---+---+
| 2 | 1 |
+---+---+


[1] https://www.redhat.com/archives/virt-tools-list/2014-October/msg00069.html

(In reply to Jonathon Jongsma from comment #30)
> Hello David,
> 
> I was not able to reproduce your non-contiguous guest desktop mentioned
> above. I tested this configuration and I did find a bug that was initially
> causing both client windows to end up on the same monitor. I've posted a
> patch to the virt-tools mailing list to fix this issue [1]. After fixing
> this issue, It behaves as you expect it to: 
> 
> +---+---+
> | 2 | 1 |
> +---+---+
> 
> 
> [1]
> https://www.redhat.com/archives/virt-tools-list/2014-October/msg00069.html

Sorry, it turns out that I was testing with upstream virt-viewer, rather than the rhel7 version, which is why I didn't reproduce your issue. I will investigate further. Some additional patches from upstream may need to be backported.

> Sorry, it turns out that I was testing with upstream virt-viewer, rather
> than the rhel7 version, which is why I didn't reproduce your issue. I will
> investigate further. Some additional patches from upstream may need to be
> backported.

I should clarify that this comment only applies to the testing I did in comment #30. Previously I was testing with the rhel7 build.

I retest with virt-viewer-0.6.0-7.el7.x86_64
spice-glib-0.22-2.el7.x86_64
spice-gtk3-0.22-2.el7.x86_64

Steps:
1. Prepare a rhel7 guest
# virsh dominfo rhel7.0
Id:             4
Name:           rhel7.0
UUID:           b87cc000-5725-4830-b201-602ce1ea8d6f
OS Type:        hvm
State:          running
...

2. Edit setting file:
# cat settings
#rhel7.0

[b87cc000-5725-4830-b201-602ce1ea8d6f]
monitor-mapping=1:3;2:4;3:2

3. # virt-viewer rhel7.0 -f

Result:
Display 1 is on Monirot 3, display 2 and 3 are on monitor 4, can check in screenshot.

As the result, assigned

Created attachment 945527 [details]
Screenshot for comment 33

Created attachment 945529 [details]
virt-viewer log with spice-debug for comment 33

(In reply to David Jaša from comment #29)
> > but apparently the client is not placing them on the correct client monitor.
> > I think I need some better logging to figure out why. Is this 100%
> > reproducible?
> 
> Yes.
> 
> 
> 
> Jonathon, would it be able to rearrange guest monitor layout as well to
> match client layout? E.g.:
> 
> monitor-mapping=1:2;2:1 with client layout:
> 
> +---+---+
> | 1 | 2 |
> +---+---+
> 
> will produce also guest layout:
> 
> +---+---+
> | 1 | 2 |
> +---+---+
> 
> leading to non-contiguous guest desktop in fullscreen:
> 
> +------------+-----------+
> |------+     |  +--------|
> |INDOW |     |  | GUEST W|
> |------+     |  +--------|
> +------------+-----------+
> 
> so the guest layout should be:
> 
> +---+---+
> | 2 | 1 |
> +---+---+
> 
> 
> The fix to this issue shouldn't however make bug 1018180 regress.


Hi David,

I've looked into this particular issue a little bit, but haven't come up with a solution yet. The one thing that I have concluded is that this does not appear to be a virt-viewer/remote-viewer issue. We are sending down the right configuration, but for some reason the guest is not being configured properly. 

Sent by client:

(remote-viewer:14047): GSpice-DEBUG: ../../gtk/channel-main.c:1078 main-1:0: monitor config: #0 1280x720+1280+0 @ 32 bpp
(remote-viewer:14047): GSpice-DEBUG: ../../gtk/channel-main.c:1078 main-1:0: monitor config: #1 1280x720+0+0 @ 32 bpp

Received from guest:

(remote-viewer:14047): GSpice-DEBUG: ../../gtk/channel-display.c:1734 display-2:0: monitor id: 0, surface id: 0, +0+0-1280x720
(remote-viewer:14047): GSpice-DEBUG: ../../gtk/channel-display.c:1734 display-2:0: monitor id: 1, surface id: 0, +1280+0-1280x720


Notice the difference in x-offsets. In the request, display 0 is +1280 and display 1 is +0. In the response, display 0 is +0 and display 1 is +1280. Somehow these got swapped. 

Can you open a new bug for this issue?

This might be a mutter issue I've been spending some time in the last weeks.

There seem to be 2 or 3 different bugs being discussed here, and only one of them is a client bug. I've filed new bugs for the non-client bugs.

1. windows don't get placed on the correct monitor (this bug)

2. extra displays don't get disabled on the guest (filed new Bug 1153372)

3. guest displays are not aligned properly as mentioned in comment 29 (filed new Bug 1153377)


Unfortunately, I've so far been unable to reproduce issue #1...

virt-viewer-0.6.0-10 works for me.

VERIFIED with virt-viewer-0.6.0-10.el7

Steps:
1. prepare a spice guest, and configure the guest :
# virsh dumpxml $vm
<domain type='kvm' id='5' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <qemu:commandline>
    <qemu:arg value='-global'/>
    <qemu:arg value='qxl-vga.vgamem_mb=32'/>
  </qemu:commandline>
</domain>

2. edit setting file
# cat ~/.config/virt-viewer/settings
[e022993f-2ec3-4de3-8806-75e9dc6bde63]
monitor-mapping=1:4
3. #virt-viewer -f
4, repeat with setting file like:
 - 1:4;2:3;
 - 1:3;2:4;3:2
 - 1:2;2:4;3:1;4:3
 - 1:1;2:1(invalid)
 - 1:2;2:b(invalid)
 - 1:3;a:2(invalid)

Result:
display can be placed to the right monitor with right resolution.
For invalid setting, can report the warning msg:
 - 1:1;2:1
(virt-viewer:22598): virt-viewer-WARNING **: Invalid monitor-mapping configuration: a display or monitor id was specified twice
 - 1:2;a:2
(virt-viewer:20886): virt-viewer-WARNING **: Invalid monitor-mapping configuration: display id is invalid: a 0x143fdf0='a'
 - 1:3;2:b
(virt-viewer:22258): virt-viewer-WARNING **: Invalid monitor-mapping configuration: monitor id 'b' is invalid


Also test with two monitors. 

As the result, VERIFIED this bug.

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.

https://rhn.redhat.com/errata/RHBA-2015-0295.html