Can reproduce. Tested on R9 380X mesa-git

I have made a trace with wined3d, but it replays fine with dxvk.
Does not contain any NSFW
rorolog_try.trace.tar.gz

Edit: i just realized OP trace actually works. The zip file was just so small i didn't think it would run.

Game does start with DXVK on Windows, this seems to be a Wine bug somewhere.

In particular, it gets stuck in audio initialization, waiting for an input event in MsgWaitForMultipleObjects.

Audio thread is initialized roughly as follows:

DirectSoundCreate(NULL, &device, NULL)
event = CreateEventA(NULL, TRUE, FALSE, NULL);
thread = CreateThread(NULL, 0, audio_thread_proc, &device, 0, &thread_id);
do
    ret = MsgWaitForMultipleObjects(1, &event, TRUE, 1, QS_ALLEVENTS)
while (ret != 0)

DWORD WINAPI audio_thread_proc(void *device)
{
    ...
    SetEvent(event);
    while (...)
    {
        ...
    }
}

MSDN says this about third argument, fWaitAll, for MsgWaitForMultipleObjects:

If this parameter is TRUE, the function returns when the states of all objects in the pHandles array have been set to signaled and an input event has been received.

Event gets signaled, but input event isn't received, so it keeps returning WAIT_TIMEOUT (258), instead of expected WAIT_OBJECT_0 (0).

WineD3D happens to send such input event, comment out update_window_state( hwnd ) in dlls/win32u/window.c:set_window_pixel_format() and it will run into the same issue.

Uses same engine as koikake and has the same bug so it is probably the same issue. https://github.com/doitsujin/dxvk/issues/2104

I took a closer look at it. WineD3D calls SetPixelFormat from within Direct3DCreate9, when it creates a fake window for a GL context. SetPixelFormat calls update_window_state.

=>0 0x0000007cfa4aa0 wgl_wglSetPixelFormat(args=000000006DAA61F2) [Z:\home\fbx\w
ine\dlls\opengl32\unix_thunks.c:69] in opengl32.so (0x0000000065f9e8)
  1 0x0000006daa61f2 SetPixelFormat+0x32(hdc=<couldn't compute location>, fmt=<c
ouldn't compute location>, pfd=<couldn't compute location>) [Z:\home\fbx\wine\dl
ls\gdi32\opengl.c:95] in gdi32 (0x0000000065fa28)
  2 0x00000004a08cd4 wined3d_caps_gl_ctx_create+0x2d4(adapter=0000000000791880, 
ctx=000000000065FB60) [Z:\home\fbx\wine\dlls\wined3d\adapter_gl.c:352] in wined3
d (0x0000000065fab8)
  3 0x00000004a108b9 wined3d_adapter_gl_init+0x1df1(wined3d_creation_flags=<inte
rnal error>, ordinal=<internal error>, adapter_gl=<internal error>) [Z:\home\fbx
\wine\dlls\wined3d\adapter_gl.c:5323] in wined3d (0x0000000065fc08)
  4 0x00000004a108b9 wined3d_adapter_gl_create+0x1e39(ordinal=0, wined3d_creatio
n_flags=0x7ecc) [Z:\home\fbx\wine\dlls\wined3d\adapter_gl.c:5426] in wined3d (0x
0000000065fc08)
  5 0x00000004a7c20b wined3d_init+0x4b(wined3d=000000000078E468, flags=0x7ecc) [
Z:\home\fbx\wine\dlls\wined3d\directx.c:3516] in wined3d (0x0000000065fc68)
  6 0x00000004b12372 wined3d_create+0x62(flags=<couldn't compute location>) [Z:\
home\fbx\wine\dlls\wined3d\wined3d_main.c:146] in wined3d (0x0000000065fca8)
  7 0x000000048b1955 d3d9_init+0x35(d3d9=000000000078E648, extended=0) [Z:\home\
fbx\wine\dlls\d3d9\directx.c:701] in d3d9 (0x0000000065fcf8)
  8 0x000000048a3af1 Direct3DCreate9+0x5c(sdk_version=<couldn't compute location
>) [Z:\home\fbx\wine\dlls\d3d9\d3d9_main.c:44] in d3d9 (0x0000000065fd28)

Maybe X11DRV_vkCreateWin32SurfaceKHR should send the event to update window, but then it would be outside of Direct3DCreate9 call. I don't know.

It looks like the winex11 changes in 9.22 happened to "fix" these issues for winex11. It still occurs on winewayland, so I'd recommend to keep patching wine to post WM_WINE_UPDATEWINDOWSTATE to the hwnd during wine_vkCreateWin32SurfaceKHR upon a special envvar, and in case it regresses again in the future.

It looks like the winex11 changes in 9.22 happened to "fix" these issues for winex11. It still occurs on winewayland, so I'd recommend to keep patching wine to post WM_WINE_UPDATEWINDOWSTATE to the hwnd during wine_vkCreateWin32SurfaceKHR upon a special envvar, and in case it regresses again in the future.

Is there any instructions about this?

Use wine 9.22 or later, or put NtUserPostMessage(create_info->hwnd, WM_WINE_UPDATEWINDOWSTATE, 0, 0); wherever vkCreateWin32SurfaceKHR is implemented

diff --git a/dlls/win32u/vulkan.c b/dlls/win32u/vulkan.c
index c676ae10e54..75a3d1b8ee2 100644
--- a/dlls/win32u/vulkan.c
+++ b/dlls/win32u/vulkan.c
@@ -140,6 +140,10 @@ static VkResult win32u_vkCreateWin32SurfaceKHR( VkInstance client_instance, cons
         surface->hwnd = dummy;
     }
 
+    const char *softpal_hack = getenv("WINE_KISARA");
+    if (softpal_hack && atoi(softpal_hack))
+        NtUserPostMessage(create_info->hwnd, WM_WINE_UPDATEWINDOWSTATE, 0, 0);
+
     if ((res = driver_funcs->p_vulkan_surface_create( surface->hwnd, instance->host.instance,
                                                       &host_surface, &surface->driver_private )))
     {

Thanks, will try it out when free.
But idk why my new wine 9.22 installation does not seem to be affected by the unupdated winewayland problems?

At 2024年12月29日 GMT+08:00 AM, 8:45:47，Attila Fidan @.***> Wrote：

Use wine 9.22 or later, or put NtUserPostMessage(create_info->hwnd, WM_WINE_UPDATEWINDOWSTATE, 0, 0); wherever vkCreateWin32SurfaceKHR is implemented

Like for current wine:

diff --git a/dlls/win32u/vulkan.c b/dlls/win32u/vulkan.c
index c676ae10e54..75a3d1b8ee2 100644
--- a/dlls/win32u/vulkan.c
+++ b/dlls/win32u/vulkan.c
@@ -140,6 +140,10 @@ static VkResult win32u_vkCreateWin32SurfaceKHR( VkInstance client_instance, cons
        surface->hwnd = dummy;
    }

+    const char *softpal_hack = getenv("WINE_KISARA");
+    if (softpal_hack && atoi(softpal_hack))
+        NtUserPostMessage(create_info->hwnd, WM_WINE_UPDATEWINDOWSTATE, 0, 0);
+
    if ((res = driver_funcs->p_vulkan_surface_create( surface->hwnd, instance->host.instance,
                                                      &host_surface, &surface->driver_private )))
    {

--
Reply to this email directly or view it on GitHub:
https://github.com/doitsujin/dxvk/issues/3207#issuecomment-2564571256
You are receiving this because you commented.

Message ID: @.***>

But idk why my new wine 9.22 installation does not seem to be affected by the unupdated winewayland problems?

It's possible to trigger messages to get posted to the window handle via external factors through the windowing system driver. E.g. updating output configuration on the compositor via hotplug/settings change will send updated output information and wl_output.done to winewayland.drv, which through posting to the desktop window WM_WAYLAND_INIT_DISPLAY_DEVICES -> WM_DISPLAYCHANGE leads wine into calling update_window_state for child windows. Similar happens when starting/stopping an IME on winex11. It's possible that different compositors behaving slightly differently might cause the outcome to be different, maybe some are causing messages to be posted while the engine gets into the loop. On sway at least, this doesn't happen, but the loop can be manually broken by changing the setting of an output.

@Nekotekina Friendly ping. Can you do a restest of this?

@Nekotekina Friendly ping. Can you do a restest of this?

I think it just works for me on wine 10 rc something, I'm on XWayland. Should I close the issue? But I may be forgetting something.

Maybe you should do that since overall it's a wine issue not affiliated with dxvk.

On February 1, 2025 5:51:45 AM GMT+08:00, Ivan @.***> wrote:

@.***(https://github.com/Nekotekina) Friendly ping. Can you do a restest of this?

I think it just works for me on wine 10 rc something, I'm on XWayland. Should I close the issue? But I may be forgetting something.

--
Reply to this email directly or view it on GitHub:
https://github.com/doitsujin/dxvk/issues/3207#issuecomment-2628460496
You are receiving this because you commented.

Message ID: @.***>