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

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

Oct. 16, 2025

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) Oct. 16, 2025

Oct. 16, 2025

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 Oct. 16, 2025

Oct. 16, 2025

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) Oct. 16, 2025

Oct. 16, 2025

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

[PATCH 0/3] MR9185: winex11: Simplify WindowPosChanged a bit more.
by Rémi Bernon Oct. 16, 2025

Oct. 16, 2025

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

1 4

Re: [PATCH v3 0/4] MR8958: win32u: Fixes for the OpenGL drawables mess.
by Rémi Bernon Oct. 16, 2025

Oct. 16, 2025

On Thu Oct 16 07:05:06 2025 +0000, li xiao wrote: > thinks , How to debug issues related to win32u: opengl_drawable when > encountering a deadlock。 > for example： > <table> > <tr> > <td> > `01a0:err:sync:RtlpWaitForCriticalSection section > 00007F4A4ACC5570 "?"` `wait timed out in thread 01a0, blocked by 0134, > retrying (60` `sec).` > </td> > </tr> > </table> > This issue is caused by opengl_drawable lifetime. 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118684

1 0

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

Oct. 16, 2025

On Mon Oct 13 10:09:28 2025 +0000, Rémi Bernon wrote: > Hi, sorry if this has caused some more issues but if there's a bug > please submit a bug report to https://bugs.winehq.org with some more > details about it happens and how to reproduce it. > Regarding the `opengl_drawable` member in the DC structure, it's still > being used for non-Window DCs, like memory DCs, which need to keep a > reference on their eventual OpenGL surface. thinks , How to debug issues related to win32u: opengl_drawable when encountering a deadlock。 This issue is caused by opengl_drawable lifetime. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118683

1 0

[PATCH 0/4] MR9174: ole32: Move CoTreatAsClass() to combase.
by Nikolay Sivov (＠nsivov) Oct. 16, 2025

Oct. 16, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9174

3 5

[PATCH v2 0/1] MR9169: include: Add missing AddrBStore to STACKFRAME in imagehlp.h
by Alistair Leslie-Hughes (＠alesliehughes) Oct. 16, 2025

Oct. 16, 2025

-- v2: include: Correct STACKFRAME for 64bits in imagehlp.h https://gitlab.winehq.org/wine/wine/-/merge_requests/9169

2 1

[PATCH v2 0/2] MR9171: win32u, server: Use rational numbers to track mouse cursor location.
by Conor McCarthy (＠cmccarthy) Oct. 16, 2025

Oct. 16, 2025

When scaling applies, after a call to SetCursorPos(), a subsequent call to GetCursorPos() may not return the exact coordinates set, which an app may interpret as mouse movement. -- v2: win32u, server: Use float values to track mouse cursor location. https://gitlab.winehq.org/wine/wine/-/merge_requests/9171

3 8