Add support for hotplug_mode_update

emersion commented 4 years ago

This is set by VM software when user-space is supposed to modeset with the preferred mode on hotplug.

https://drmdb.emersion.fr/properties/3233857728/hotplug_mode_update

Related: the "suggested X" and "suggested Y" props.

wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2188

emersion commented 4 years ago

We may also want to decide to NACK the whole KMS VM support. The whole thing is pretty hacky.

emersion commented 3 years ago

With https://github.com/swaywm/wlroots/pull/2645, regardless of whatever wlroots chooses to support, compositors should be able to handle these properties if they want to.

hedgepigdaniel commented 3 years ago

@emersion I'm curious how you see this stuff working out (especially in terms of what Sway can support).

My goal: to make Sway (and perhaps other wlroots compositors) work in the way you would expect when running in a virtual machine. IMO that means that it should:

use the preferred mode for each output, including if it changes (as it does if the host window is resized)
layout multiple outputs in the same way that they are on the host system, in the case that this information is provided, and including if it changes for a particular output (as it sometimes does if other outputs are added/removed from the VM)

Currently, i.e. without these abilities, using sway on a VM is a poor experience, because:

if a host window is resized, Sway does not mode set to match the new preferred mode, so the output dimensions become incorrect (aspect ratio, resolution, and scale)
if the host displays the VM in full screen on multiple outputs, their relative position is incorrect by default.
a configuration that solves either of the above problems is specific to a particular window/output arrangement on the host. A correct configuration becomes wrong if a window is resized, full screen mode is toggled, or a screen is added/removed.

As best as I understand the suggested X/Y props, they are useful if and only if the user wants the outputs to be configured as they are on the host system. In this case, the host system is responsible for choosing output modes, rotation, position, and relative scale. The chosen configuration is made visible in the VM with the preferred mode and suggested X/Y props (in pixels).

If the user wants to choose their own rotation, relative scale, or position for any of the outputs, then they are choosing not to use the host configuration, and therefore the suggested X/Y positions are irrelevant.

The positions are in pixels, so there is an assumption that all pixels are the same size. This assumption is consistently made based on all the testing I've done (VMware Fusion on OSX and Virtualbox on a Sway host):

the output physical size props are not set in the VM (they are always 0x0)
the pixels presented to the VM are scaled according to the host configuration. For example on VMware Fusion with a high and low resolution display, each VM pixel corresponds to 1 pixel on the high resolution display and 2x2 pixels on the low resolution display.

I'm not really sure what's wrong with this API? I would guess that the idea is to have a simple output configuration concept that can be implemented on many different host/guest systems. So it's simple/limited - there are no physical distances and all pixels are the same size.

emersion commented 3 years ago

Let me be clear: I haven't NACKed your pull requests adding upstream support for VM props. This issue is just an example of how #2645 could be useful. wlroots policy has always been not to be in the way of compositors.

each VM pixel corresponds to 1 pixel on the high resolution display and 2x2 pixels on the low resolution display.

OK, that's interesting. How do we know whether a display is high-resolution or low-resolution?

hedgepigdaniel commented 3 years ago

Sure no problem, I'm just trying to explain what I'm trying to achieve and my understanding so hopefully we can come up with the best solution.

For the goal of not being in the way of compositors, I wonder if it would also be useful to have a generic "DRM connector changed" signal in wlroots? Since there seem to be an unlimited number of driver specific props that might change, a compositor that uses props that wlroots doesn't explicitly support may also want to know if they change.

OK, that's interesting. How do we know whether a display is high-resolution or low-resolution?

I can't see a way to tell - there are no DRM props on the output that seem relevant for that and the mmWidth/mmHeight are zero. So even with those patches, I have to add a config for each output (which are all high res within the VM) with scale 2.

emersion commented 3 years ago

I can't see a way to tell - there are no DRM props on the output that seem relevant for that and the mmWidth/mmHeight are zero. So even with those patches, I have to add a config for each output (which are all high res within the VM) with scale 2.

OK, thanks for investigating. Maybe we should open a kernel driver issue to discuss this. I believe the bug tracker is now: https://gitlab.freedesktop.org/drm/misc.

emersion commented 3 years ago

For the goal of not being in the way of compositors, I wonder if it would also be useful to have a generic "DRM connector changed" signal in wlroots? Since there seem to be an unlimited number of driver specific props that might change, a compositor that uses props that wlroots doesn't explicitly support may also want to know if they change.

Yeah, I wonder. Physical outputs can't just change any property though. For instance we don't expect the EDID or physical size to change without an unplug/replug. Similarly I don't know of physical outputs that add new modes without unplug/replug.

swaywm / wlroots

Add support for hotplug_mode_update #2188