On Fri Feb 2 04:53:23 2024 +0000, myownfriend wrote:
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.
Well, just to make it clear I only gave my view of how this should be going, it's always possible that someone else feels differently and feels like reviewing this and approve as it is. Alexandre will in the end also decides what he feels would be best.
Then my opinion is based on the time I spent moving virtualized display modes *out* of winex11, in the hope that other drivers could build upon it, and as it's been merged I can only assume Alexandre thought the same. Adding back virtualized modes in a different driver simply feels like going backwards that's all.