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 1166319 - 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 WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mutter
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Florian Müllner
QA Contact: Desktop QE
URL:
Whiteboard:
: 1166298 1249469 (view as bug list)
Depends On: 1153377 1166320 1267184 1269918 1278016 1309234
Blocks: 1166298
TreeView+ depends on / blocked
 
Reported: 2014-11-20 19:53 UTC by Jonathon Jongsma
Modified: 2020-12-08 12:31 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1153377
Environment:
Last Closed: 2020-12-08 12:30:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
first backported commit (9.22 KB, patch)
2015-05-20 21:34 UTC, Jonathon Jongsma
no flags Details | Diff
second backported commit (3.31 KB, patch)
2015-05-20 21:35 UTC, Jonathon Jongsma
no flags Details | Diff
third backported commit (7.25 KB, patch)
2015-05-20 21:36 UTC, Jonathon Jongsma
no flags Details | Diff
fourth (last) backported commit (2.37 KB, patch)
2015-05-20 21:36 UTC, Jonathon Jongsma
no flags Details | Diff

Description Jonathon Jongsma 2014-11-20 19:53:40 UTC
+++ This bug was initially created as a clone of Bug #1153377 +++

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.

--- Additional comment from RHEL Product and Program Management on 2014-10-15 18:07:05 EDT ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Jonathon Jongsma on 2014-10-21 11:38:34 EDT ---

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

--- Additional comment from Jonathon Jongsma on 2014-10-22 16:59:12 EDT ---

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...

--- Additional comment from Christophe Fergeau on 2014-10-23 04:08:12 EDT ---

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.

--- Additional comment from Jonathon Jongsma on 2014-10-23 11:00:05 EDT ---

yeah, I've been looking at this in rhel7. I suspect a similar thing is happening within gnome-settings-daemon xrandr plugin.

--- Additional comment from Jonathon Jongsma on 2014-10-23 17:51:24 EDT ---

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

--- Additional comment from Jonathon Jongsma on 2014-11-18 15:40:31 EST ---

upstream patches to mutter are attached to https://bugzilla.gnome.org/show_bug.cgi?id=740069.

--- Additional comment from Jonathon Jongsma on 2014-11-18 15:49:39 EST ---

Adds ability to determine whether output has hotplug_mode_update property

--- Additional comment from Jonathon Jongsma on 2014-11-18 15:50:23 EST ---

Adds the ability to get the suggested position for an output

--- Additional comment from Jonathon Jongsma on 2014-11-18 15:51:45 EST ---

Uses the suggested position for an output to arrange displays

--- Additional comment from Jonathon Jongsma on 2014-11-18 15:52:24 EST ---

don't apply stored configuration for outputs with hotplug_mode_update

--- Additional comment from Jonathon Jongsma on 2014-11-18 15:54:23 EST ---

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.




Required patches:

attachment 958761 [details]
attachment 958764 [details]

Comment 3 Bastien Nocera 2015-03-31 12:34:19 UTC
gnome-settings-daemon just talked to XRandR through gnome-desktop, and in RHEL 7.2, setting up the default configuration will be moved to mutter (as it was in F20). Reassigning to mutter.

Comment 4 Jonathon Jongsma 2015-03-31 13:46:21 UTC
For what it's worth, I already fixed this upstream in mutter, so if 7.2 contains a new enough mutter, it should just work.

Comment 5 Jonathon Jongsma 2015-05-15 14:48:00 UTC
https://git.gnome.org/browse/mutter/commit/?id=f6f5f624d4e1bf13a8368110f695a393bc47c739 is the relevant patch. It looks like this went in after 3.15, so it probably needs to be backported for 7.2

Comment 6 Jonathon Jongsma 2015-05-20 21:33:38 UTC
I've backported the required patches to 3.14.4. Will post patches here.

Comment 7 Jonathon Jongsma 2015-05-20 21:34:33 UTC
Created attachment 1027876 [details]
first backported commit

Comment 8 Jonathon Jongsma 2015-05-20 21:35:32 UTC
Created attachment 1027877 [details]
second backported commit

Comment 9 Jonathon Jongsma 2015-05-20 21:36:07 UTC
Created attachment 1027878 [details]
third backported commit

Comment 10 Jonathon Jongsma 2015-05-20 21:36:57 UTC
Created attachment 1027879 [details]
fourth (last) backported commit

Comment 11 Tomas Pelka 2015-05-26 11:54:57 UTC
Reacking

Comment 12 Jonathon Jongsma 2015-06-04 19:26:54 UTC
*** Bug 1166298 has been marked as a duplicate of this bug. ***

Comment 14 Jonathon Jongsma 2015-08-04 15:16:52 UTC
*** Bug 1249469 has been marked as a duplicate of this bug. ***

Comment 16 David Jaša 2015-10-07 15:12:48 UTC
see bug 1153377 comment 25.


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