https://bugs.winehq.org/show_bug.cgi?id=52508
--- Comment #4 from Zhiyi Zhang zzhang@codeweavers.com --- (In reply to Zeb Figura from comment #3)
(In reply to Zhiyi Zhang from comment #1)
We can't just let explorer.exe manage them since there are console applications that call EnumDisplayDevices() but don't launch explorer.exe, as Alexandre mentioned.
Do you have a link to this conversation?
Eh, I can't find it. I vaguely remember it was during an IRC conversation.
I think with the PE work going on, we are moving in the direction of initializing these registries only on the 64-bit side. Jacek knows more about this. And obviously, some error prompt when Vulkan is missing wouldn't hurt.
Are we planning to make the WoW64 path required? That seems questionable to me, but...
Could we initialize and query monitor information from some other centralized location? wineserver, perhaps (I know you had patches for this), or just let the first process initialize it while others query? Maybe I've had a particularly rough time of it, but it just seems too easy for different processes to get different results, in one way or another.
I think monitors are probably initialized in monitor.sys in kernel mode at startup. Since wine doesn't have a kernel mode, wineserver is probably the way to go. My wineserver patches only move part of the monitor information, most of them are and should still be in SetupAPI. Actually, there is a mechanism to let only the first process initialize monitors. That's what the force parameter in X11DRV_DisplayDevices_Init() is for. Maybe recent win32u work changed its behavior or the first process to create windows isn't always 64-bit.