On Thu Feb 1 09:24:02 2024 +0000, Rémi Bernon wrote:
I am thinking that the process that owns the wl_surface (the desktop
process in the design described above) is the one that receives all input and must handle all output for it and all this involves some per-process state. So, either the desktop process handles all that state, making the processes owning the HWND much leaner, or we somehow forward that state to the HWND process to handle (BTW, this seems quite painful, would not recommend). In any case, Wine has to dispatch input sometimes differently from where it is received from the host point of view. We use the host window mostly as a hint, and I think we try to not send input to another window unless necessary but in the end it doesn't make much different which window really received it, and the receiver -if that's a dedicated process- could simply hint wineserver about the target HWND.
For DirectComposition would the idea be that the host system handles
the composition completely (through host child surfaces), or do you expect that Wine would also grow a full-fledged compositor (performing full input handling at the "root" level, compositing to a final surface that is the handed to the host etc)? I don't really know what it would involve. I hope that we can always keep a fast path where a process can render and present its client surface directly.
I’m not as familiar with X11, Wayland, DWM, or Wine as either of you but it sounds like what’s being described is something similar to XWayland but with four back-ends: X11, Wayland, Android, macOS.
XWayland is obviously a complicated effort all by itself and that’s _just_ a backwards compatibility layer for running X11 clients on Wayland. That’s despite the fact that XWayland has the advantage of having some integration with the host Wayland compositor. I can only imagine how much more complicated it would be to come up a common front-end for a DWM compatibility layer that connects two (to four) backends that use very dissimilar protocols ans can work as a normal Wayland client.
Obviously that doesn’t mean a common frontend shouldn’t be pursued. I’m just wondering if it’s maybe too early in the development of winewayland to try to find commonalities between it and winex11. Considering that the virtual desktop mode only works on winex11 right now and its possible future as a multi-back-end nested compositor is only in the idea phases, maybe some “convoluted driver specific mechanisms” (CDSM) should be allowed for now so that all the intricate little problems of adapting DWM to Wayland can be better understood first. From there, the process of creating a common front-end might be easier to figure out. As you said about this specific CDSM, the changes aren’t that large anyway so it’s not like it’s adding a bunch of code that’s going to be difficult to work around, change, or remove later on.
About the idea of one virtual monitor for each real monitor, here’s what I can imagine would happen if an application tries to change the display resolution:
**X11**
The Wine app changes the actual display’s resolution. All applications on that monitor, Wine or native, will run at that resolution. If the app doesn’t change the resolution back, the user can set it back with their display settings. There's no real difference from how it works now except that Wine would also have to keep the virtual monitor resolutions in sync with the real monitors.
**Wayland with winewayland**
The Wine app only changes the virtual monitor’s resolution. Due to the mismatch between virtual and physical monitor resolutions, Wine apps on that monitor would think they’re working at a different screen resolution than native apps and probably be scaled up to emulate the mode change. If the app doesn’t change the virtual resolution back, the user would need to use a Windows app to set it back since winewayland wouldn't be synced with the display resolution anyway.
**Wayland with winex11**
The wine compositor would be running within XWayland. Winex11 would try to change the virtual resolution and make a request from XWayland to change the display resolution. XWayland can’t change the display resolution so it does whatever it does to safely ignore that request. Right now if you change resolution with winex11 in XWayland, nothing happens. There’s no scaling or anything, it’s just as if the button doesn’t work. I’m not sure how that would change if virtual monitors and another nested compositor get introduced though. It may actually end up with a worse result, assuming you'd want to support use under XWayland at all at that point.