Automatic screen resizing for virtual machines

[Pete Woods]

Currently when you resize the virtual display in qemu (with QXL/spice display) the unity8 screen resolution stays the same. However in e.g. Gnome3, the shell is informed of a suggestion to change size, and complies.

There appears to be an emerging de-facto standard in virtual display resizing, as described below by Thomas Hellstrom <email address hidden> from VMware, which is supported by both qemu and VMware.

[Pete Woods (pete-woods)]

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 <email address hidden>

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

[Gerry Boland (gerboland)]

Mir needs to support whatever API VMs use to communicate the "display" size changed. QtMir supporta display sizes changing already (can been seen by changing resolution)

[Daniel van Vugt (vanvugt)]

Resizing of native Mir servers in a VM already works (last tested in VirtualBox).

It appears you're just suffering from bug 1669034.