RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1153377 - Guest displays are not always arranged in the order requested by the client
Summary: Guest displays are not always arranged in the order requested by the client
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xorg-x11-drv-qxl
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 7.2
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On: 1166320
Blocks: 1166298 1166319 1269918
TreeView+ depends on / blocked
 
Reported: 2014-10-15 21:56 UTC by Jonathon Jongsma
Modified: 2016-06-30 10:43 UTC (History)
13 users (show)

Fixed In Version: xorg-x11-drv-qxl-0.1.1-15
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1166298 1166319 1269918 (view as bug list)
Environment:
Last Closed: 2016-06-30 10:43:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
qxl log while connecting with a fullscreen virt-viewer session (32.82 KB, text/plain)
2014-10-21 15:38 UTC, Jonathon Jongsma
no flags Details
gnome-desktop3 patch #1 (2.98 KB, patch)
2014-11-18 20:49 UTC, Jonathon Jongsma
no flags Details | Diff
gnome-desktop3 patch #2 (6.98 KB, patch)
2014-11-18 20:50 UTC, Jonathon Jongsma
no flags Details | Diff
gnome-settings-daemon patch #1 (2.37 KB, patch)
2014-11-18 20:51 UTC, Jonathon Jongsma
no flags Details | Diff
gnome-settings-daemon patch #2 (2.16 KB, patch)
2014-11-18 20:52 UTC, Jonathon Jongsma
no flags Details | Diff
remote-viewer --debug --spice-debug (81.81 KB, text/plain)
2015-10-07 15:11 UTC, David Jaša
no flags Details
Xorg.0.log (64.78 KB, text/plain)
2015-10-07 15:11 UTC, David Jaša
no flags Details

Description Jonathon Jongsma 2014-10-15 21:56:33 UTC
When connecting to a guest with virt-viewer using the custom monitor mapping feature, guest displays can be swapped incorrectly. Issue noted by David Jasa in bug 1129477 comment 29 (copied here):

> 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 client sends down the correct arrangement, but it apparently gets swapped somehow by either the host or the guest.

Comment 2 Jonathon Jongsma 2014-10-21 15:38:34 UTC
Created attachment 949035 [details]
qxl log while connecting with a fullscreen virt-viewer session

debug output enabled with

echo 0x4 > /sys/module/drm/parameters/debug

At the top of the log, you can see that it reads the configuration correctly (pay attention to the x offsets):

[584886.586655] [drm:qxl_display_copy_rom_client_monitors_config] read 1600x900+1680+0
[584886.586660] [drm:qxl_display_copy_rom_client_monitors_config] read 1680x1050+0+0

But later on, it sets the display config to the wrong values. For display 0:

[584887.126824] [drm:qxl_monitors_config_set] 0:1600x900+0+0

and display 1:

[584887.129141] [drm:qxl_monitors_config_set] 1:1680x1050+1600+0

Comment 3 Jonathon Jongsma 2014-10-22 20:59:12 UTC
In fact, it appears that when using the new method of display configuration (i.e. hotplug events instead of the vdagent, introduced in RHEL 7, Fedora 19 (or 20?), etc), the monitors appear to always be arranged left-to-right by display ID rather than using the coordinates passed down by the client. Still investigating...

Comment 4 Christophe Fergeau 2014-10-23 08:08:12 UTC
In fedora 20, the way hotplug events are handled in mutter could cause that as the position from the config is not used, but rather we let mutter do the layout through make_default_config() in src/core/monitor-config.c (mutter 3.10.4). I have started some patches to bypass this and directly use the monitor config we got, but it's not finished yet (only taking into account resolution, not position).
RHEL7 did not have that code in mutter though, so I don't know if something equivalent is done, and this has changed in f21 too.

Comment 5 Jonathon Jongsma 2014-10-23 15:00:05 UTC
yeah, I've been looking at this in rhel7. I suspect a similar thing is happening within gnome-settings-daemon xrandr plugin.

Comment 6 Jonathon Jongsma 2014-10-23 21:51:24 UTC
So, it appears that it's not currently possible control layouts with this hotplug method. There's no real way to communicate a desired position for a display from the kernel to userspace. So the guest simply arranges the displays as it sees fit. Some comments from Dave Airlie on IRC:

<airlied> we probably just want to expose a couple of new properties from the kernel
<airlied> with a suggested x/y position then change userspace to take notice of them
<airlied> rather than doing something too spice specific

Comment 7 Jonathon Jongsma 2014-11-18 20:40:31 UTC
upstream patches to mutter are attached to https://bugzilla.gnome.org/show_bug.cgi?id=740069.

Comment 8 Jonathon Jongsma 2014-11-18 20:49:39 UTC
Created attachment 958757 [details]
gnome-desktop3 patch #1

Adds ability to determine whether output has hotplug_mode_update property

Comment 9 Jonathon Jongsma 2014-11-18 20:50:23 UTC
Created attachment 958759 [details]
gnome-desktop3 patch #2

Adds the ability to get the suggested position for an output

Comment 10 Jonathon Jongsma 2014-11-18 20:51:45 UTC
Created attachment 958761 [details]
gnome-settings-daemon patch #1

Uses the suggested position for an output to arrange displays

Comment 11 Jonathon Jongsma 2014-11-18 20:52:24 UTC
Created attachment 958764 [details]
gnome-settings-daemon patch #2

don't apply stored configuration for outputs with hotplug_mode_update

Comment 12 Jonathon Jongsma 2014-11-18 20:54:23 UTC
I've attached patches required to backport this feature to rhel 7.1. The upstream code for handling monitor configuration has changed considerably since RHEL 7.1. It now happens exclusively in mutter, whereas in RHEL 7.1, it is distributed between libgnome-desktop and gnome-settings-daemon.

Comment 14 David Blechter 2014-11-20 18:41:47 UTC
Resetting the devel_ack to ?,  as the bug was moved to the new component

Comment 15 Jonathon Jongsma 2014-11-20 19:51:19 UTC
Sorry, moving this bug back to qxl, since there is a patch needed for qxl as well. Will clone a new bug for gnome-settings-daemon

Comment 16 Jonathon Jongsma 2014-11-20 20:07:43 UTC
Required patch for qxl driver: http://lists.x.org/archives/xorg-devel/2014-November/044559.html

Comment 17 Jonathon Jongsma 2014-11-20 23:10:31 UTC
Moving to 7.2. It's too close to 7.1 and involves too many different components.

Comment 20 Jonathon Jongsma 2015-05-20 14:53:57 UTC
Note that this fix can't easily be tested without the kernel changes in Bug 1166320.

Comment 23 David Jaša 2015-10-07 15:09:03 UTC
Not fixed in:
3.10.0-322.el7.x86_64
mutter-3.14.4-15.el7.x86_64
xorg-x11-drv-qxl-0.1.1-18.el7.x86_64

I don't know which component is failing however. I'll attach logs from remote-viewer and Xorg.

Comment 24 David Jaša 2015-10-07 15:11:30 UTC
Created attachment 1080736 [details]
remote-viewer --debug --spice-debug

relevant part .config/virt-viewer/settings:
[7905b260-af2a-40e0-a3c2-8a9f5309f57e]
monitor-mapping=1:3;2:2

client has three 1920x1080 displays side-by-side, 1, 2, 3.

client/guest mapping is correct but guest layout not (as found in original bug).

Comment 25 David Jaša 2015-10-07 15:11:58 UTC
Created attachment 1080737 [details]
Xorg.0.log

Comment 27 Jonathon Jongsma 2015-10-07 22:14:02 UTC
(In reply to David Jaša from comment #23)
> Not fixed in:
> 3.10.0-322.el7.x86_64
> mutter-3.14.4-15.el7.x86_64
> xorg-x11-drv-qxl-0.1.1-18.el7.x86_64
> 
> I don't know which component is failing however. I'll attach logs from
> remote-viewer and Xorg.

It looks like all of these components are actually working correctly, but there is a bug in virt-viewer that is causing the client to send down the wrong coordinates.

Comment 28 Tomas Pelka 2015-10-08 11:35:33 UTC
(In reply to Jonathon Jongsma from comment #27)
> (In reply to David Jaša from comment #23)
> > Not fixed in:
> > 3.10.0-322.el7.x86_64
> > mutter-3.14.4-15.el7.x86_64
> > xorg-x11-drv-qxl-0.1.1-18.el7.x86_64
> > 
> > I don't know which component is failing however. I'll attach logs from
> > remote-viewer and Xorg.
> 
> It looks like all of these components are actually working correctly, but
> there is a bug in virt-viewer that is causing the client to send down the
> wrong coordinates.

OK in that case lets move to 7.3 as we wouldn't be able to verify unless we can get some scratch build with fixed virt-viewer.

Johnaton any objections?

Comment 29 Tomas Pelka 2015-10-08 13:39:12 UTC
I had a chat with Johanton and we both agree this is not a show stopper even if the virt-viewer issue is regression or not. So I'm going to remove from 7.2 erratum and set proper flags.

Also the virt-viewer issue was cloned as separated bz 1269918.

Tom

Comment 31 Whitney Chadwick 2016-04-12 15:33:57 UTC
Set PM ack to +

Comment 32 Radek Duda 2016-05-17 14:16:30 UTC
What exactly is CLIENT-MONITOR-ID (man virt-viewer)? 
I have three monitors on my client. When I open Settings-> Displays they are numbered like this:
1 - Built-in
2 - NEC
3 - Acer.
I turned off Built-in display, so 
2 - NEC
3 - Acer.
are active.
If I map the monitors e.g. like this:

1) ~/.config/virt-viewer:
[rhel7.3]
monitor-mapping=1:3;2:2
then I get warning message:
remote-viewer-WARNING **: Initial monitor #3 for display #1 does not exist, skipping...
remote-viewer-WARNING **: display 0 should not be enabled, disabling
and guest display is only on 2 - NEC monitor.
* in this configuration mouse sometimes (~10% reproducibility) doesn't work in guest (cursor appears, but cannot interact) and I must leave full-screen mode and go back to enable it
* sometimes (~30% reproducibility) blank screen appears on the monitor 3 - Acer with message: Connecting to graphic server (debug :(remote-viewer:26905): GSpice-DEBUG: channel-main.c:1164 main-1:0: sending new monitors config to guest
 and no guest display appears


2) If I map monitors like this:
monitor-mapping=1:2;2:3
then I get warning message:
remote-viewer-WARNING **: Initial monitor #3 for display #2 does not exist, skipping...
and guest display is again on 2 - NEC monitor. (no problem with mouse)

3) In the case of
monitor-mapping=1:1;2:2
both guest displays are spread over two client monitors, but if I get display IDs in guest (setting -> Displays), 2 - NEC monitor is guest display 2 and 3 - Acer is guest display 1. 

So from my third test I assume that ID of Acer monitor is 1 instead of 3. But I still don't understand why is guest display shown on the same monitor in the case of my first two tests.

tested on client rhel 7.3 nightly
virt-viewer-2.0-7.el7.x86_64

Comment 33 Radek Duda 2016-05-18 08:25:48 UTC
(In reply to Radek Duda from comment #32)
> What exactly is CLIENT-MONITOR-ID (man virt-viewer)? 
> I have three monitors on my client. When I open Settings-> Displays they are
> numbered like this:
> 1 - Built-in
> 2 - NEC
> 3 - Acer.
> I turned off Built-in display, so 
> 2 - NEC
> 3 - Acer.
> are active.
> If I map the monitors e.g. like this:
> 
> 1) ~/.config/virt-viewer:
> [rhel7.3]
> monitor-mapping=1:3;2:2
> then I get warning message:
> remote-viewer-WARNING **: Initial monitor #3 for display #1 does not exist,
> skipping...
> remote-viewer-WARNING **: display 0 should not be enabled, disabling
> and guest display is only on 2 - NEC monitor.
> * in this configuration mouse sometimes (~10% reproducibility) doesn't work
> in guest (cursor appears, but cannot interact) and I must leave full-screen
> mode and go back to enable it
> * sometimes (~30% reproducibility) blank screen appears on the monitor 3 -
> Acer with message: Connecting to graphic server (debug
> :(remote-viewer:26905): GSpice-DEBUG: channel-main.c:1164 main-1:0: sending
> new monitors config to guest
>  and no guest display appears
> 
> 
> 2) If I map monitors like this:
> monitor-mapping=1:2;2:3
> then I get warning message:
> remote-viewer-WARNING **: Initial monitor #3 for display #2 does not exist,
> skipping...
> and guest display is again on 2 - NEC monitor. (no problem with mouse)
> 
> 3) In the case of
> monitor-mapping=1:1;2:2
> both guest displays are spread over two client monitors, but if I get
> display IDs in guest (setting -> Displays), 2 - NEC monitor is guest display
> 2 and 3 - Acer is guest display 1. 
> 
> So from my third test I assume that ID of Acer monitor is 1 instead of 3.
> But I still don't understand why is guest display shown on the same monitor
> in the case of my first two tests.
> 
> tested on client rhel 7.3 nightly
> virt-viewer-2.0-7.el7.x86_64

bug 1337068 report created

Comment 34 Jonathon Jongsma 2016-06-29 15:36:07 UTC
hello Radek,

This bug is for the QXL component. The important part is described in comment #0: when the client arranges the first display to the right of the second display, the guest configuration should also match. 

There's no need to test all virt-viewer monitor mapping configurations here. You just need to find *one* monitor-mapping configuration that will achieve the appropriate guest configuration, and then you should be able to verify that this QXL bug has been fixed. There may well be various corner cases that exist with the client configuration, but that is not relevant for this bug.

From the comments above, this QXL bug has been fixed since RHEL 7.2, but it was removed from the errata because an additional bug in virt-viewer prevented QA from verifying the fix at all. Now that virt-viewer has supposedly been fixed (see above-mentioned bug #1269918 that was closed as a duplicate of bug #1267184), it should be possible to verify this bug. Then we can probably just close this bug as CURRENTRELEASE.

Comment 35 Radek Duda 2016-06-30 08:57:39 UTC
ok I verified it for monitor mapping configurations:
1:1;2:2, 2:1;1:2 and 1:2;2:1
with client rhel7.3
virt-viewer-2.0-8.el7.x86_64
and guest rhel 7.3
xorg-x11-drv-qxl-0.1.1-18.el7-x86_64
and it seems ok. left-right client displays were correctly adjusted to left-right guest monitors.

Comment 36 David Blechter 2016-06-30 10:43:33 UTC
closing as CURRENTRELEASE based on #35 verification


Note You need to log in before you can comment on or make changes to this bug.