- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/2] MR9369: wininet: Return correct errors and put handle into invalid state when seeking beyond end of file.
by Torge Matthies (＠tmatthies) Nov. 12, 2025

Nov. 12, 2025

On Wed Nov 5 15:17:58 2025 +0000, Jacek Caban wrote: > Do we need a separate mechanism for that? Could we use `hdr->dwError` > for this? You mean determining that we are in this invalid state by looking at the last returned error? Since there are multiple different error values, and there may be other calls that return these errors for different conditions, we shouldn't really determine whether we're in this invalid handle state by looking at the last returned error, I'd say. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9369#note_121637

1 0

[PATCH 0/5] MR9437: win32u, vulkan-1: Test D3DKMT fence signal / wait / Vulkan interop.
by Rémi Bernon Nov. 12, 2025

Nov. 12, 2025

This adds D3DKMT sync object monitored fence tests, showing that the fences can be rewound when requested explicitly. Also adds some interop tests between D3D11 / D3D12 / Vulkan. The vulkan-1 tests show that timeline semaphores are rewindable on Windows even when not shared (at least with NVIDIA GPU), which is forbidden by spec but useful if not required for D3D12 fence interop. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9437

1 5

[PATCH 0/1] MR9435: comctl32/ipaddress: Use the system window text color to draw dots.
by Zhiyi Zhang (＠zhiyi) Nov. 12, 2025

Nov. 12, 2025

Manual tests on XP show that ipaddress controls don't use the text colors in the theme file to draw dots and the system window text color should be used instead. In fact, there is no text color property for the ETS_NORMAL state in the theme file. This fixes the wrong color for the dots in ipaddress controls. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9435

3 4

[PATCH 0/4] MR9433: comctl32/status: Refactor STATUSBAR_DrawSizeGrip() to take an HWND instead.
by Zhiyi Zhang (＠zhiyi) Nov. 12, 2025

Nov. 12, 2025

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

3 5

[PATCH 0/1] MR9432: win32u: Fill some GPU info in HKLM\Software\Microsoft\DirectX.
by Paul Gofman (＠gofman) Nov. 12, 2025

Nov. 12, 2025

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

3 3

[PATCH v3 0/4] MR9382: win32u: Keep internal pixel format and surfaces on the DCs.
by Rémi Bernon Nov. 12, 2025

Nov. 12, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58846 Wine D3D resets the window pixel format to its original value when an internal pixel format was requested and the context done being used, and requests the internal pixel format again before it is used again. When internal pixel format and window pixel format don't match this causes any previously created OpenGL surface with a different format to be released (and destroyed as no context is current with it), creating a new one with the new format, back and forth. What we actually need here, is to keep the wined3d OpenGL client surface, with the internal pixel format, alive as long as it is being referenced by wined3d, as well as any OpenGL client surface that may have been created, with the window pixel format, by the application itself. It's not possible to rely on DCs for application-created OpenGL surfaces, as the application is free to release its DC and retrieve another one later on for the same window while still expecting it to use the same OpenGL surface. However with wined3d, we know that the DCs are being kept referenced until the context is being destroyed so we can safely use them to store the wined3d OpenGL surface. -- v3: wined3d: Remove now unnecessary pixel format restoration. win32u: Get rid of window internal pixel format. win32u: Keep internal pixel format and surfaces on the DCs. wined3d: Call wglSetPixelFormatWINE before releasing context DC. https://gitlab.winehq.org/wine/wine/-/merge_requests/9382

2 6

[PATCH 0/4] MR9434: winex11: Flush requests in systray functions.
by Rémi Bernon Nov. 12, 2025

Nov. 12, 2025

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

1 4

Re: [PATCH v3 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Jiajin Cui (＠jin-king1) Nov. 12, 2025

Nov. 12, 2025

@madewokherd I have made modifications according to your prompt and resubmitted. Are there any other issues that need to be modified? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_121619

1 0

Re: [PATCH v3 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Jiajin Cui (＠jin-king1) Nov. 12, 2025

Nov. 12, 2025

On Wed Nov 12 06:32:42 2025 +0000, Jiajin Cui wrote: > changed this line in [version 2 of the diff](/wine/wine/-/merge_requests/9418/diffs?diff_id=223155&start_sha=4b2a4af1fe5aa70c3e7b3b1ce0c96622a663c212#a4b3319efe38a02579dc31608fc2e67efc79219d_1923_1910) The new modification is no longer using `__wine_timestamp` atom. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_121617

1 0

Re: [PATCH v3 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Jiajin Cui (＠jin-king1) Nov. 12, 2025

Nov. 12, 2025

On Wed Nov 12 06:32:41 2025 +0000, Jiajin Cui wrote: > changed this line in [version 2 of the diff](/wine/wine/-/merge_requests/9418/diffs?diff_id=223155&start_sha=4b2a4af1fe5aa70c3e7b3b1ce0c96622a663c212#a4b3319efe38a02579dc31608fc2e67efc79219d_1941_1910) Changed the clipboard timestamp handling to use the actual X11 server timestamp from selection requests, the new modification will not remove any events from the queue. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_121615

1 0