July 2025 - wine-gitlab

[PATCH 0/1] MR8236: dxcore/tests: Skip tests when there is no display available.
by Bernhard Übelacker (＠bernhardu) 03 Jul '25

03 Jul '25

[Test pattern page.](https://test.winehq.org/data/patterns.html#dxcore:dxcore) [Testbot run with this patch.](https://testbot.winehq.org/JobDetails.pl?Key=158548) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8236

3 2

[PATCH 0/1] MR8406: wined3d: Make sure swapchain can't be used after being released.
by Yuxuan Shui (＠yshui) 03 Jul '25

03 Jul '25

In wined3d_swapchain_cleanup, before decrementing the reference counts of each of the back/front buffers, we first set their swapchain to NULL, presumably to stop the current under-destruction swapchain from being used through them. But there is an oversight. When we call wined3d_texture_decref on the front_buffer, the back_buffers still have their swapchains pointing to the swapchain being destroyed. In texture_resource_unload, we call context_acquire(device, NULL, 0), note the NULL texture parameter here. When the texture parameter is NULL, wined3d_context_gl_acquire (in turn called by context_acquire) will default to using the first back buffer from the implicit swapchain of "device", which, as previously stated, has not had their swapchain set to NULL yet. From here, we reach wined3d_context_gl_activate with a texture whose swapchain is currently being destroyed. This swapchain is then assigned to "context_gl" here before being freed, leaving a dangling pointer. When this context_gl is acquired again later, we will try to access context_gl->c.swapchain->win_handle, thus complete the use-after-free cycle. This commit makes sure the swapchain pointer of ALL front and back buffers are set to NULL before decrementing their reference counts. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58325 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8406

3 2

[PATCH 0/1] MR8492: inetcpl: Restore parse_url_from_outside implementation.
by Alex Henrie (＠alexhenrie) 03 Jul '25

03 Jul '25

Fixes: fa4a470f9afd79b8104bacf3f1046e7f8ac2d09e Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58263 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8492

3 3

[PATCH v2 0/1] MR8502: configure: Don't nuke Makefile if makedep is interrupted.
by Yuxuan Shui (＠yshui) 03 Jul '25

03 Jul '25

I noticed that if I Ctrl-C while makedep is re-generating the Makefile, the Makefile will be gone. There are two parts to this problem: 1. make deletes the output file if a rule is interrupted. - Solution: use the special .PRECIOUS target. 2. wine_fn_output_makefile overwrites the existing Makefile, because makedep is hardcoded to use the output makefile as its input. - Solution: add a -i command line options to makedep for specifying the input file name, then don't overwrite Makefile in wine_fn_output_makefile. -- v2: configure: Don't nuke Makefile if makedep is interrupted. https://gitlab.winehq.org/wine/wine/-/merge_requests/8502

2 1

Re: [PATCH v8 0/5] MR8460: ntdll: Add support for multi-battery systems and energy-reporting batteries on Linux
by Vibhav Pant (＠vibhavp) 03 Jul '25

03 Jul '25

On Thu Jul 3 15:25:33 2025 +0000, Tomas-Mendes-ai wrote: > power.c:68:0.001 no battery detected > power.c:69:0.001 Test failed: expected ACLineStatus to be 1, got 0 > This test failed but I'm pretty sure the logic holds on all (compliant) > real systems. > Something about the test environment maybe? Even if the tests are being run in a virtual/containerized environment, they still are real/compliant systems for our purposes. The tests ensure that APIs behave exactly the same on Wine and Windows, real or not. Windows seems to always set `ACLineStatus` to 1, including on virtualized environments where there is power information available to the system. Wine's implementation should do the same. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8460#note_108748

1 0

[PATCH v5 0/6] MR8498: win32u: Implement generic EGL driver pbuffer surface.
by Rémi Bernon (＠rbernon) 03 Jul '25

03 Jul '25

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/8496, leaving context sharing for later. -- v5: win32u: Remove now unnecessary opengl_drawable hdc member. winewayland: Use a distinct wayland_pbuffer struct for pbuffers. win32u: Implement generic EGL driver pbuffer surface. win32u: Avoid releasing opengl drawable within drawables_lock. win32u: Avoid calling detach, flush or swap on pbuffer drawables. winemac: Remove now unnecessary pbuffer tracking. https://gitlab.winehq.org/wine/wine/-/merge_requests/8498

3 9

[PATCH 0/3] MR8500: Some improvements to widl.
by eric pouech (＠epo) 03 Jul '25

03 Jul '25

This MR improves widl with : - fixes a segfault when inheriting from an incomplete interface (prints an error message instead), - supports (for C++) inheriting from interfaces which are declared after the declaration of the derived interface. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8500

3 6

Re: [PATCH v2 0/5] MR8499: win32u: Introduce a new client_surface struct for vulkan surfaces.
by Rémi Bernon (＠rbernon) 03 Jul '25

03 Jul '25

I don't think the failures are related, though always tricky to be sure. Looks more like the famous display change race condition under load / concurrent jobs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8499#note_108736

1 0

[PATCH v4 0/6] MR8498: Draft: win32u: Implement generic EGL driver pbuffer surface.
by Rémi Bernon (＠rbernon) 03 Jul '25

03 Jul '25

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/8496, leaving context sharing for later. -- v4: win32u: Remove now unnecessary opengl_drawable hdc member. winewayland: Use a distinct wayland_pbuffer struct for pbuffers. win32u: Implement generic EGL driver pbuffer surface. win32u: Avoid releasing opengl drawable within drawables_lock. win32u: Avoid calling detach, flush or swap on pbuffer drawables. winemac: Remove now unnecessary pbuffer tracking. https://gitlab.winehq.org/wine/wine/-/merge_requests/8498

3 10

[PATCH 0/1] MR8501: po: Update Japanese translation.
by Akihiro Sagawa (＠sgwaki) 03 Jul '25

03 Jul '25

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

2 1

2025

2024

2023

2022

wine-gitlab July 2025