On Wed Jan 31 12:21:14 2024 +0000, Rémi Bernon wrote:
Then I don't like very much commits 8b38be18592fb0538efee64a46e4de9a7321d34b and later, as I feel they are introducing a convoluted driver-specific mechanism for a feature that IMO would be nice to have common. The changes are not so large, *but* still I feel it's not going in the right direction, and having something that works early might make later refactoring more complicated. What I think instead, though I haven't really explored it, is that this should be built upon, extending and perhaps even superseding, the virtual desktop mode:
- It lives in win32u and is usable by any driver (although for the
moment only winex11 still implements the necessary dedicated desktop windows).
- It already implements fake modes enumeration over host current modes.
- Is already enumerates host gpus / adapters / monitors and should be
able to keep a separate list and map the virtual monitors / modes to the hosts ones without an additional callback. The virtual desktop mode is also currently diverging from how Windows behaves [*], and evolving it to emulate monitors instead could fix that. I can imagine that instead of emulating desktops displayed separately, we could have a feature that would emulate and virtualize monitors. Eventually displaying some in separate windows, themselves possibly windowed or fullscreen with virtual modesetting. or mapping them to host monitors directly with direct modesetting, or backend scaling or whatever the driver decides to do for best results. This is of course a much larger feature to implement, and it will require changes in win32u and elsewhere, but IMO it is better and would benefit all drivers. So my advice here, is to start instead by implementing the necessary things for virtual desktop mode to work with winewayland, which could help users get something usable more quickly (could even perhaps provide a fix for window positioning assuming you would then have more control over them, if they can be made a child of the virtual desktop windows). [*] https://gitlab.winehq.org/wine/wine/-/merge_requests/4786 for instance shows one of the broken assumption: on Windows all the desktops of the same windowstation expect to have the same adapters and monitors, on Wine with virtual desktop mode this is not true, and additional desktops may see the host monitors instead.
Thanks for the feedback!
I am trying to imagine, very roughly and at high level, how such a virtualized monitor approach would work:
1. win32u requests the host monitor information (i.e., `UpdateDisplayDevices`) 2. win32u uses the host information and the current virtualized configuration to synthesize the new virtualized configuration, with some extra input from the driver and/or registry options (e.g., to decide the mapping to host monitors or windows). Perhaps we want the driver to have complete control over the final virtualized configuration? 3. win32u notifies all processes of the new virtualized configuration. This includes the mapping to host monitors or windows, and/or we will provide a way to query such information.
A ChangeDisplaySettings call would update the current virtualized configuration internally and notify about the update (i.e., steps (2)-(3)).
Is the above in the direction you are envisioning?
So my advice here, is to start instead by implementing the necessary things for virtual desktop mode to work with winewayland, which could help users get something usable more quickly (could even perhaps provide a fix for window positioning assuming you would then have more control over them, if they can be made a child of the virtual desktop windows).
Unfortunately, implementing a (rooted) virtual desktop mode is not possible with the current set of Wayland protocols. The root/desktop wl_surface would be owned by the desktop process and other processes would not be able to refer to it to establish a wl_subsurface relationship (which is what would allow relative positioning), since all Wayland client objects are per-connection.
Note that there is the xdg-foreign protocol which allows a limited form of cross-process relationships, but only in the xdg_toplevel parent/child sense, so it's inadequate for our needs.