October 2025 - Wine-gitlab - list.winehq.org

[PATCH v2 0/7] MR9189: mmdevapi/tests: Add a lot of capturing tests.
by Giovanni Mascellani (＠giomasce) 16 Oct '25

16 Oct '25

-- v2: mmdevapi/tests: Test extensible wave formats when capturing. https://gitlab.winehq.org/wine/wine/-/merge_requests/9189

2 7

[PATCH v2 0/2] MR9178: ntdll: Use ReadPointerAcquire to get pointer value in RtlRunOnceBeginInitialize
by Luca Bacci (＠lb90) 16 Oct '25

16 Oct '25

The `RtlRunOnce` family of functions are implemented using (a variant of) the Double Checked Locking Pattern (DCLP). The DCLP requires memory fences for correctness, on both the writer and reader sides. It's pretty obvious why it's needed on the writer side, but quite surprising that any is needed on the reader side! On strong memory model architectures (x86 and x86_64), only compiler-level fences are required. On weak memory model architectures like ARM64, instead, you need both CPU and compiler fences. That's explained well in books like _Concurrent Programming on Windows_ by Joe Duffy and in online resources like [1]. The Wine implementation has fences on the writing side (`RtlRunOnceComplete`). That's because `InterlockedCompareExchangePointer` inserts a full memory fence. However some code paths on the reader side (`RtlRunOnceBeginInitialize`) are missing fences, specifically the (`RTL_RUN_ONCE_CHECK_ONLY`) branch and the (`!RTL_RUN_ONCE_CHECK_ONLY && (val & 3) == 2`) branch. ~~Add the missing fences using GCC's atomic builtins [2]~~ **EDIT:** using `ReadPointerAcquire` now Note: with this MR, the generated code should change only for ARM64 ### References: 1. [Double-Checked Locking is Fixed In C++11](https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp… 2. [GCC's Built-in Functions for Memory Model Aware Atomic Operations](https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.ht… -- v2: ntdll: Use ReadPointerAcquire to get pointer value in RtlRunOnceBeginInitialize include: add atomic read/write of pointers https://gitlab.winehq.org/wine/wine/-/merge_requests/9178

4 4

[PATCH v3 0/4] MR9155: d3dx10: Handle all D3DX10_IMAGE_LOAD_INFO fields.
by Connor McAdams (＠cmcadams) 16 Oct '25

16 Oct '25

This finishes up the handling of `D3DX10_IMAGE_LOAD_INFO` fields. :) The default filter values were confirmed using a test locally that I've pushed to a branch here: https://gitlab.winehq.org/cmcadams/wine/-/commits/d3dx10-filter-test -- v3: d3dx10: Pass D3DX10_IMAGE_LOAD_INFO texture creation arguments through in load_texture_data(). d3dx10: Handle FirstMipLevel argument in load_texture_data(). d3dx10: Add support for generating mipmaps to load_texture_data(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9155

3 5

[PATCH 0/1] MR9186: uxtheme: Add stub for GetThemeBitmap.
by Louis Lenders (＠xe) 16 Oct '25

16 Oct '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58747 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9186

3 2

[PATCH 0/7] MR9189: mmdevapi/tests: Add a lot of capturing tests.
by Giovanni Mascellani (＠giomasce) 16 Oct '25

16 Oct '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9189

2 7

[PATCH 0/3] MR9188: win32u: Use local handles in D3DKMT_ESCAPE_UPDATE_RESOURCE_WINE.
by Rémi Bernon 16 Oct '25

16 Oct '25

And some misc fixes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9188

1 3

[PATCH v2 0/4] MR9155: d3dx10: Handle all D3DX10_IMAGE_LOAD_INFO fields.
by Connor McAdams (＠cmcadams) 16 Oct '25

16 Oct '25

This finishes up the handling of `D3DX10_IMAGE_LOAD_INFO` fields. :) The default filter values were confirmed using a test locally that I've pushed to a branch here: https://gitlab.winehq.org/cmcadams/wine/-/commits/d3dx10-filter-test -- v2: d3dx10: Pass D3DX10_IMAGE_LOAD_INFO texture creation arguments through in load_texture_data(). d3dx10: Handle FirstMipLevel argument in load_texture_data(). d3dx10: Add support for generating mipmaps to load_texture_data(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9155

2 4

[PATCH 0/4] MR9155: d3dx10: Handle all D3DX10_IMAGE_LOAD_INFO fields.
by Connor McAdams (＠cmcadams) 16 Oct '25

16 Oct '25

This finishes up the handling of `D3DX10_IMAGE_LOAD_INFO` fields. :) The default filter values were confirmed using a test locally that I've pushed to a branch here: https://gitlab.winehq.org/cmcadams/wine/-/commits/d3dx10-filter-test -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9155

3 10

[PATCH v3 0/5] MR9128: Draft: win32u: Process internal hardware messages while waiting.
by Rémi Bernon 16 Oct '25

16 Oct '25

They don't produce any window messages and should be processed as soon as possible, without returning to the client side. -- v3: server: Don't set QS_RAWINPUT for internal hardware messages. win32u: Process internal hardware messages while waiting. server: Clear QS_RAWINPUT | QS_HARDWARE in get_rawinput_buffer. win32u: Keep waiting on the queue until it gets signaled. win32u: Use an absolute wait timeout in wait_message. https://gitlab.winehq.org/wine/wine/-/merge_requests/9128

1 6

Re: [PATCH v3 0/4] MR8958: win32u: Fixes for the OpenGL drawables mess.
by li xiao (＠xiaolizai) 16 Oct '25

16 Oct '25

On Thu Oct 16 07:06:10 2025 +0000, Rémi Bernon wrote: > Sorry, there's no general method to debug this and there's many possible > root causes. This indicates that one thread is waiting on a critical > section forever as another thread didn't release it (possibly crashed > while holding it, but could be something else). The missing name > indicates that it's probably a critical section created by the application. > You can open a bug report on the website above, with details about the > application you are trying to run if you can, and log file of Wine > output with `WINEDEBUG=+wgl` environment variable set for instance, this > might give some clue, or someone (including myself) can then try to > reproduce the issue and debug it. thinks，I have another question. Window DC calls the function set_dc_opengl_drawable( dce-\>hdc, NULL ) to release opengl-drawable through release_dce or release_dc. After this submission:[**win32u: Don't store the window OpenGL drawables on the DCs.**](https://gitlab.winehq.org/wine/wine/-/merge_requests/8958/diffs?com… where is the resource release for opengl-drawable? I don't seem to have seen it in this submission. The release of opengl_drawable should be done by the window. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118688

1 0