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.
Oh I agree in the aspect that code for virtualized modes should be shared by drivers as much as possible. Obviously the easiest stuff to share would be a list of display modes as is evident by this MR and sysparams having similar lists. I was under the impression that you were suggesting that this whole MR is a CDSM. That's my fault because you did specify that it was only from commits 8b38be18 and later.
I'm still pretty confused as to what's being proposed with this compositor idea though. I was initially under the impression that it would somehow work like a rootless XWayland. That felt like it would be un-managable to do in a way that supports four backends without becoming very messy. Upon re-reading everything, it sounds like you're suggesting that the future VDM would still create a monitor in a window but it can more than one monitor and each can be full-screened. Is that right? You guys are talking about supporting the current virtual desktop mode on top of winewayland while discussing what the future one could work like and I think I'm just getting the conversations crossed.
If you ARE talking about something that works like the current one but expanded to allow multiple monitors and scaling then I feel like implementing the current VDM onto other drivers would be a waste of time because the implementation for each back-end would be highly dependent on the back-end work. For example, my understanding is that, like Wayland, macOS also can't have applications within another application window so Wayland isn't the odd one out there.
I personally feel like implementing VDM as a full-on nested compositor would really be the only correct way to do it for two big reasons. The first is that, it could potentially run as the host compositor, a Wayland client, an X11 client, etc. with a vast majority of it's code being back-end agnostic. The second is that it would also be able to use any protocol it wants so it could just use a custom protocol that understands WDM natively to maximize compatibility. It wouldn't be of any obvious benefit outside of VDM besides sharing some virtual monitor state stuff, but I feel like the level of compatibility it would provide and the ways that it could run would make it far more useful and interesting.
Obviously like you said you'd want a fast path where the host compositor handles the composition, and that's what I'd prefer most of the time, but I feel that's always gonna be a very separate, driver-specific path. I feel like the goal outside of VDM (lets call it host mode or HM) should be to make Wine apps feel as much like native apps as possible and not always expect maximum compatibility. Wayland is still in active development so while it may never be ideal to translate WDM to, it's going to get new protocols which will likely make things a little more compatible over time. In the meantime Windows applications might get forced to work a little more like Wayland apps but that might not always be a bad thing.
I'm thinking of it kind of like video game console emulators. They generally have an interpreter which is slow but very compatible and portable. When they bring the emulator to a new platform, this is always the first thing they get running. That's VDM. Then they have their fast back-ends, the dynamic re-compilers that are very quick but are less likely to be completely accurate and require separate backends for each host architecture. That's each HM driver.
Of course like I said, I don't know anywhere near as much about this stuff as you guys do so feel free to tell me if what I'm saying is dumb or misinformed. I won't take offense. I just wanted to chime in lol