Open emersion opened 4 years ago
We may also want to decide to NACK the whole KMS VM support. The whole thing is pretty hacky.
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.
@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:
Currently, i.e. without these abilities, using sway on a VM is a poor experience, because:
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):
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.
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?
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
.
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.
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.
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