On Fri Mar 24 16:01:45 2023 +0000, Alexandre Julliard wrote:
Since the Wayland output state of different clients/processes can be
(transiently) out of sync, we effectively treat the Wayland output state of the desktop window process as the authoritative one, and all other processes use that state (through that shared memory region) when reporting back information, in order to be consistent both among them **and** with the Wine monitor information.
There are some other benefits to the shared memory approach, which
will become important in the future. For example, the ability to consistently apply/simulate application initiated mode changes (i.e., `ChangeDisplaySettings`) across all processes (since Wayland doesn't allow normal clients to actually change the compositor mode). I should note that using shared memory that way is not allowed in Wine. It's not considered acceptable that one crashing app can take down the entire session. Shared state has to be stored in the Wine server.
Fwiw regarding display settings, the default (nulldrv) implementation should already be able to share current display settings and display changes across all processes through the registry. It's currently guarded by `ChangeDisplaySettings` returning `E_NOTIMPL`, but could perhaps be done unconditionally.
Of course that's not necessarily in sync with the host settings, and needs to be updated on external changes.