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 1166298 - 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 DUPLICATE of bug 1166319
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:
Depends On: 1153377 1166319 1166320 1267184 1269918 1278016 1309234
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-20 18:32 UTC by Jonathon Jongsma
Modified: 2016-02-17 10:00 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1153377
Environment:
Last Closed: 2015-06-04 19:26:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jonathon Jongsma 2014-11-20 18:32:24 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.

--- Additional comment from RHEL Product and Program Management on 2014-11-20 13:31:09 EST ---

This bug report previously had all acks and release flag approved.
However since at least one of its acks has been changed, the
release flag has been reset to ? by the bugbot (pm-rhel).  The
ack needs to become approved before the release flag can become
approved again.

Comment 1 Jonathon Jongsma 2014-11-20 18:33:06 UTC
see bug 1153377 for patches required for libgnome-desktop

Comment 2 Ray Strode [halfline] 2014-11-20 19:05:44 UTC
Pasting the comments here so the attachments linkify:

Jonathon Jongsma 2014-11-18 15:49:39 EST

Created attachment 958757 [details]
gnome-desktop3 patch #1

Adds ability to determine whether output has hotplug_mode_update property

[reply] [−]
Private
Comment 9 Jonathon Jongsma 2014-11-18 15:50:23 EST

Created attachment 958759 [details]
gnome-desktop3 patch #2

Adds the ability to get the suggested position for an output

Comment 4 Ray Strode [halfline] 2015-06-04 18:52:55 UTC
for 7.2, given the rebase, we need to backport some patches into mutter 3.14 I think.

Comment 5 Jonathon Jongsma 2015-06-04 19:26:54 UTC
Hi Ray, bug #1166319 is the mutter bug (patches already backported). I guess this one can just be closed for now since this component is no longer relevant in rhel 7.2

*** This bug has been marked as a duplicate of bug 1166319 ***


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