Also, why should update_display_cache() concern itself with whether to use the current display mode?
This was mostly because the sources were previously reusing the same registry key. I forgot about it but I think it can now be dropped since they now have unique name and the "Virtual" source will keep its display settings separately.
And calling is_virtual_desktop() in xrandr14_get_adapters() seems weird. I am afraid that you have to simplify it a bit more.
Right, I changed it to handle everything on the win32u side.
I feel like this patch is making things more convoluted and difficult to review. For example, the line between virtual desktop display devices and real display devices was clearer before this patch.
Well, I don't think it's more convoluted that the current way, which redirects the display device manager callbacks in an awkward way and has to make sure the virtual desktop mode is properly handled as it could have been activated by the UpdateDisplayDevices call.
Then, yes, it blurs the lines a bit between physical and virtual display devices, and that's actually on purpose, as described in https://gitlab.winehq.org/wine/wine/-/merge_requests/5057. I think it would be a nice feature to have if we could emulate virtual monitors through dedicated windows. It also makes it easier to partially virtualize a physical output, which would be needed for wayland and if we want to upstream winex11 fullscreen hack (which I actually do).
It also more properly fixes the incorrectness of having separate desktops expose different display settings to their respective threads. Even though we now have a workaround using some sort of "inherited" virtual desktop mode, it's still incorrect.