After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783073 - MetaMonitorManager: ignore hotplug_mode_update at startup
MetaMonitorManager: ignore hotplug_mode_update at startup
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2017-05-25 06:16 UTC by Marco Trevisan (Treviño)
Modified: 2017-05-25 09:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
MetaMonitorManager: ignore hotplug_mode_update at startup (1.24 KB, patch)
2017-05-25 06:16 UTC, Marco Trevisan (Treviño)
none Details | Review
MetaMonitorManager: ignore hotplug_mode_update at startup (1.27 KB, patch)
2017-05-25 08:46 UTC, Marco Trevisan (Treviño)
committed Details | Review

Description Marco Trevisan (Treviño) 2017-05-25 06:16:15 UTC
Using experimental configuration in VMs (such as VMware) where hotplug_mode_update
is set causes the saved monitor settings not to be properly recovered.
Comment 1 Marco Trevisan (Treviño) 2017-05-25 06:16:21 UTC
Created attachment 352553 [details] [review]
MetaMonitorManager: ignore hotplug_mode_update at startup

hotplug_mode_update is used (mostly by VMs nowadays, and
VMware has implemented it) to inform that modes list (including
the preferred one) might change after an uevent.

However, we might ignore this value at initialization level,
or mutter won't restore the configured values at startup.

Further explainations are available at https://is.gd/lFFW6O
Comment 2 Jonas Ådahl 2017-05-25 07:14:15 UTC
Review of attachment 352553 [details] [review]:

Could be good to mention that this only affects MeatMonitorConfigManager, and that the legacy configuration already does this. Also, you should link to the gnome bugzilla report in the bottom of the commit message  not use URL shorteners.

Otherwise lgtm.
Comment 3 Marco Trevisan (Treviño) 2017-05-25 08:41:47 UTC
(In reply to Jonas Ådahl from comment #2)
> Review of attachment 352553 [details] [review] [review]:
> 
> Could be good to mention that this only affects MeatMonitorConfigManager,
> and that the legacy configuration already does this. Also, you should link
> to the gnome bugzilla report in the bottom of the commit message  not use
> URL shorteners.


For some reasons git-bz didn't do that for me, however let me paste the description from the Ubuntu bug given bt VMWare people, for further reference on this element (original link was https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1670713/comments/1 and that's the reason for the shortner...).

---

Description of interfaces for automatic resolution change and desktop layout
(multimon) in a virtualized environment:

Note that these properties were first implemented by the qxl driver and have just
recently been implemented also by VMware but in any case they could probably be
viewed as some type of evolving standard for virtualized environments.
Gnome-shell works with the below interfaces both in the Xorg- and in the
wayland / DRM configurations.

The DRM KMS interface:
Each connector exposes the following properties:

*) hotplug_mode_update - if 1 indicates that the mode list and preferred mode may
change following an uevent.
*) suggested X, suggested Y - (note the spaces instead of underscore). In a multimon
environment, suggests the X and Y desktop coordinate for a connector.

Following a uevent, the client should, for all connectors
- Check if the connector is connected, in that case enable the connector, read the
preferred mode, set the mode and set the connector to scan out starting at the
suggested desktop origin.
- Disable the connector if not connected.

Future extensions: The above interface is racy as a new uevent may be triggered and
values updated while the client is reading the values. With atomic modesetting it
should be possible to assign each suggested configuration a sequence number and
have the modesetting operation back off if the sequence numbers don't match.
Similar to how XRandR works. This has not been discussed yet on the DRM list, though,
and in practice races are more theorectial than they seem to have an effect on the
user's experience.

The Xorg interface:

The Xorg XRandR interface (if Xorg is used as a backend for the compositor) is pretty
identical except that the sequence is triggered by (IIRC) an
XRRScreenChangeNotifyEvent.

VMware implementation:
For this to work with VMware a relatively new kernel version is needed, an
xf86-video-vmware driver 13.2.1 or later needs to be installed (but not
necessarily running) and a patched version of open-vm-tools present (the patch is
to appear on the open-vm-tools GitHub webpage quite soon, or can be obtained from me
on request.

Note that if running Xorg, the xf86-video-vmware driver 13.2.1 and later will, if
running, try to perform the automatic screen resizing and output placement if it
detects a uevent from DRM, so any Xorg client trying to do the same thing will
actually try to race with the Xorg driver. However XRandR will make sure that the
client will see the configuration set by the Xorg driver before it reacts on the
new property values.

/Thomas <thellstrom@vmware.com>

Below is a typical output of running xrandr --props on a VMware VM with the new
interface active:

xrandr --props
Screen 0: minimum 1 x 1, current 3200 x 1200, maximum 16384 x 16384
Virtual1 connected primary 1600x1200+1600+0 (normal left inverted right x axis y axis) 0mm x 0mm
 _MUTTER_PRESENTATION_OUTPUT: 0
 implicit_placement: 0
  range: (0, 1)
 suggested Y: 0
  range: (0, -1)
 suggested X: 1600
  range: (0, -1)
 hotplug_mode_update: 1
  range: (0, 1)
   1600x1200 60.00*+ 60.00
   2560x1600 59.99
   1920x1440 60.00
   1856x1392 60.00
   1792x1344 60.00
   1920x1200 59.88
   1680x1050 59.95
   1400x1050 59.98
   1280x1024 60.02
   1440x900 59.89
   1280x960 60.00
   1360x768 60.02
   1280x800 59.81
   1152x864 75.00
   1280x768 59.87
   1024x768 60.00
   800x600 60.32
   640x480 59.94
Virtual2 connected 1600x900+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
 implicit_placement: 0
  range: (0, 1)
 suggested Y: 0
  range: (0, -1)
 suggested X: 0
  range: (0, -1)
 hotplug_mode_update: 1
  range: (0, 1)
   1600x900 60.00*+
   2560x1600 59.99
   1920x1440 60.00
   1856x1392 60.00
   1792x1344 60.00
   1920x1200 59.88
   1600x1200 60.00
   1680x1050 59.95
   1400x1050 59.98
   1280x1024 60.02
   1440x900 59.89
   1280x960 60.00
   1360x768 60.02
   1280x800 59.81
   1152x864 75.00
   1280x768 59.87
   1024x768 60.00
   800x600 60.32
   640x480 59.94
Virtual3 disconnected (normal left inverted right x axis y axis)
 implicit_placement: 0
  range: (0, 1)
 suggested Y: 0
  range: (0, -1)
 suggested X: 0
  range: (0, -1)
 hotplug_mode_update: 1
  range: (0, 1)
Virtual4 disconnected (normal left inverted right x axis y axis)
 implicit_placement: 0
  range: (0, 1)
 suggested Y: 0
  range: (0, -1)
 suggested X: 0
  range: (0, -1)
 hotplug_mode_update: 1
  range: (0, 1)
Virtual5 disconnected (normal left inverted right x axis y axis)
 implicit_placement: 0
  range: (0, 1)
 suggested Y: 0
  range: (0, -1)
 suggested X: 0
  range: (0, -1)
 hotplug_mode_update: 1
  range: (0, 1)
Virtual6 disconnected (normal left inverted right x axis y axis)
 implicit_placement: 0
  range: (0, 1)
 suggested Y: 0
  range: (0, -1)
 suggested X: 0
  range: (0, -1)
 hotplug_mode_update: 1
  range: (0, 1)
Virtual7 disconnected (normal left inverted right x axis y axis)
 implicit_placement: 0
  range: (0, 1)
 suggested Y: 0
  range: (0, -1)
 suggested X: 0
  range: (0, -1)
 hotplug_mode_update: 1
  range: (0, 1)
Virtual8 disconnected (normal left inverted right x axis y axis)
 implicit_placement: 0
  range: (0, 1)
 suggested Y: 0
  range: (0, -1)
 suggested X: 0
  range: (0, -1)
 hotplug_mode_update: 1
  range: (0, 1)
[thomas@vmf25template ~]$
Comment 4 Marco Trevisan (Treviño) 2017-05-25 08:46:33 UTC
Created attachment 352558 [details] [review]
MetaMonitorManager: ignore hotplug_mode_update at startup

hotplug_mode_update is used (mostly by VMs nowadays, and
VMware has implemented it) to inform that modes list (including
the preferred one) might change after an uevent.

However, when using MetaMonitorConfigManager we should
ignore this value at initialization level, or mutter
won't restore the configured values at startup.
Comment 5 Jonas Ådahl 2017-05-25 08:47:51 UTC
Review of attachment 352558 [details] [review]:

lgtm!