For example, when GPU 1 has adapter 1 and GPU 2 has adapter 2, without this fix, the `adapter` variable in the for loop is always zero when forming GDI display names \.\DISPLAY* because these two adapters are on different GPUs. Thus "\.\DISPLAY1" is incorrectly passed to xrandr14_get_id() for the second adapter and eventually gets the wrong current display mode for the second adapter.
From: Zhiyi Zhang zzhang@codeweavers.com
For example, when GPU 1 has adapter 1 and GPU 2 has adapter 2, without this fix, the `adapter` variable in the for loop is always zero when forming GDI display names \.\DISPLAY* because these two adapters are on different GPUs. Thus "\.\DISPLAY1" is incorrectly passed to xrandr14_get_id() for the second adapter and eventually gets the wrong current display mode for the second adapter.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57610 --- dlls/winex11.drv/display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/dlls/winex11.drv/display.c b/dlls/winex11.drv/display.c index 8d1a1dfd414..357e434ac5e 100644 --- a/dlls/winex11.drv/display.c +++ b/dlls/winex11.drv/display.c @@ -404,10 +404,10 @@ BOOL X11DRV_DisplayDevices_SupportEventHandlers(void)
UINT X11DRV_UpdateDisplayDevices( const struct gdi_device_manager *device_manager, void *param ) { + INT gpu_count, adapter_count, monitor_count, current_adapter_count = 0; struct x11drv_adapter *adapters; struct gdi_monitor *monitors; struct x11drv_gpu *gpus; - INT gpu_count, adapter_count, monitor_count; INT gpu, adapter, monitor; DEVMODEW *modes; UINT mode_count; @@ -448,7 +448,7 @@ UINT X11DRV_UpdateDisplayDevices( const struct gdi_device_manager *device_manage host_handler.free_monitors( monitors, monitor_count );
/* Get the settings handler id for the adapter */ - snprintf( buffer, sizeof(buffer), "\\.\DISPLAY%d", adapter + 1 ); + snprintf( buffer, sizeof(buffer), "\\.\DISPLAY%d", current_adapter_count + adapter + 1 ); asciiz_to_unicode( devname, buffer ); if (!settings_handler.get_id( devname, is_primary, &settings_id )) break;
@@ -460,6 +460,7 @@ UINT X11DRV_UpdateDisplayDevices( const struct gdi_device_manager *device_manage } }
+ current_adapter_count += adapter_count; host_handler.free_adapters( adapters ); }
Hi,
It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=150863
Your paranoid android.
=== debian11b (64 bit WoW report) ===
Report validation errors: d3d11:d3d11 has no test summary line (early exit of the main process?) d3d11:d3d11 has unaccounted for todo messages d3d11:d3d11 returned a non-zero exit code despite reporting no failures
Ah yeah, this makes much more sense! IIUC, XRRGetOutputPrimary always returns 0 but this is a bug caused by the current mode cache and not that it's not suddenly working?
On Sun Jan 12 09:05:23 2025 +0000, Rémi Bernon wrote:
Ah yeah, this makes much more sense! IIUC, XRRGetOutputPrimary always returns 0 but this is a bug caused by the current mode cache and not that it's suddenly working?
XRRGetOutputPrimary() always returns 0 because no primary monitor is set and the cached modes are also correct. The reason why we didn't see get_primary_rect() warnings for the xrandr14_get_current_mode() call for the second adapter is because "\\.\DISPLAY1" gets passed to the xrandr14_get_current_mode(), and because the current mode for the first adapter is already loaded, the mode is retrieved from the cache, skipping getting the current mode and calling get_primary_rect().
This merge request was approved by Rémi Bernon.
-
Marvin -
Rémi Bernon (＠rbernon) -
Zhiyi Zhang
-
Zhiyi Zhang (＠zhiyi)