https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #13 from Rémi Bernon rbernon@codeweavers.com --- Thank you! From the log it looks like there might some sort of hot-plugging that happens with one of the monitor.
These messages are being printed when the first monitor and its mode is enumerated:
158096.748:0050:0054:warn:xrandr:get_primary_rect Primary is set to a disconnected XRandR output.
But they stop being printed right before the second active monitor is enumerated:
158096.755:0050:0054:trace:x11drv:X11DRV_UpdateDisplayDevices adapter: 0xc9, monitor count: 1 158096.755:0050:0054:trace:system:add_monitor 0 (1920,0)-(3840,1080) (1920,31)-(3840,1080) 158096.758:0050:0054:trace:system:add_modes current 1920x1080 32bits 60Hz rotated 0 degrees unstretched non-interlaced at (0,0), modes_count 996, modes 0x55558214e740, param 0x7ffffe0fe090
My understanding is that the second monitor is the primary one, and it is seen as being disconnected at first, and the first one is used to compute the virtual screen origin which causes the first monitor modes to be located at 0x0.
When the second monitor is enumerated, and now actually detected as the primary monitor, its origin is the used instead of its own modes, and they end up at 0x0 too, but no update is done to fix the previously enumerated monitors.
It's not completely clear if this is some sort of hotplugging, or an effect of a lazy enumeration, but we also register for XRandR change events *after* the enumeration:
158096.794:0050:0054:trace:event:X11DRV_register_event_handler registered handler 0x7f11b24e7b10 for event 89 "XRandR CrtcChange" 158096.794:0050:0054:trace:event:X11DRV_register_event_handler registered handler 0x7f11b24e7b10 for event 90 "XRandR OutputChange" 158096.794:0050:0054:trace:event:X11DRV_register_event_handler registered handler 0x7f11b24e7b10 for event 92 "XRandR ProviderChange"
This should probably be done before the enumeration as if there's any hotplug happening we would be missing it.
It's also possible that something is lazily enumerated, and we should perhaps avoid calling XRandR enumeration functions over and over, and instead invoke and enumerate every device upfront, them populate win32u devices and display settings from that. This is probably going to need some larger changes though.