February 2024 - wine-gitlab

[PATCH 0/2] MR5158: rtworkq: Avoid closing a thread pool object while its callbacks are running.
by Zhiyi Zhang (＠zhiyi) 04 Mar '24

04 Mar '24

Patch 2 fixes a race condition in theory. I haven't found it affecting any real-world applications. These two bugs are caused by race conditions. I don't think adding tests could demonstrate them reliably. This MR can probably fix the race condition mentioned at https://gitlab.winehq.org/wine/wine/-/merge_requests/4243 patch 3. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5158

3 4

[PATCH v2 0/7] MR5174: win32u: Simplify sysparams using ascii strings for registry operations when possible.
by Rémi Bernon (＠rbernon) 04 Mar '24

04 Mar '24

Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/5137 -- v2: win32u: Introduce and use new reg_(open|create)_ascii_key helpers. win32u: Use set_reg_ascii_value whenever possible. win32u: Remove unnecessary class_guidW double check. win32u: Use REG_SZ instead of REG_BINARY for some adapter keys. win32u: Remove unused wine_devpropkey_monitor_adapternameW property. win32u: Simplify adapter key path creation from gpu_guid. win32u: Use char array for the device manager context gpuid. https://gitlab.winehq.org/wine/wine/-/merge_requests/5174

2 8

[PATCH 0/1] MR667: win32u: Ignore SetWindowPos() if it is trying to change topmost state for child window.
by Paul Gofman (＠gofman) 03 Mar '24

03 Mar '24

I think the behaviour of SetWindowPos() in this case is partially explained by the fact that topmost state is not strictly applicable to child windows and so Windows denies such requests. Child window can still end up with WS_EX_TOPMOST style if it was set at window creation (doesn't work this way in Wine now) or, e. g., like in the test added in the patch. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=20190 Also fixes game load dialog in Indiana Jones and the Infernal Machine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/667

6 6

[PATCH v3 0/1] MR4206: Draft: gdiplus: Check bounding box in GdipIsVisibleRegionPoint.
by Esme Povirk (＠madewokherd) 02 Mar '24

02 Mar '24

I don't think this should be committed so late in the release cycle, but the work others have been doing with point checking functions inspired me to move on this, and I wanted to let folks know what I'm thinking about and get some feedback. Consider it a proof of concept for now. The problem: GdipGetRegionHRgn is expensive. Regardless of how much of the region we actually care about, we must rasterize the entire plane of that region. Currently, we rely on gdi32 to do this, which doesn't provide us with any way to ask for a smaller area. This has been a real problem for applications that work with very large, non-rectangular regions or paths. So it seems to me, the solution will involve writing two functions, one of which is in this MR: a bounding-box calculation for regions, and rasterization. Since the result of rasterization will be short-lived, I think it should always be an array of bytes (which are effectively a bitmap but don't require bitwise operations to work with). The rasterization should be limited to a specific integer rectangle, which in the case of GdipIsVisibleRegionPoint can be 1x1 pixel. We should then be able to eliminate all internal uses of GdipGetRegionHRgn, except when we have to return an HRGN to the application. This would also be useful for implementing anti-aliasing, as we could keep the memory usage down by only rasterizing the part we need for each scanline at a time. My current concerns about what I've written so far: * Although it shouldn't change the behavior, I doubt it's adequately tested, even including the Mono tests. I'd like to ideally test every combine mode in a variety of cases. * This is too clever for its own good. Unfortunately, with the complexity of handling so many combine modes as well as infinities for each region being combined, I think the only available choices are "too clever for its own good" and "20 different special cases that need to be considered manually". Still, I want to make this as simple and easy to follow as possible, within its requirements. -- v3: gdiplus: Check bounding box in GdipIsVisibleRegionPoint. https://gitlab.winehq.org/wine/wine/-/merge_requests/4206

6 9

[PATCH 0/1] MR5164: wined3d: Pass "shader->function" as source to vkd3d_shader_scan() in shader_spirv_scan_shader().
by Henri Verbeet (＠hverbeet) 01 Mar '24

01 Mar '24

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

5 4

[PATCH v2 0/10] MR5177: winewayland.drv: part 13.1: Basic OpenGL support
by Alexandros Frantzis (＠afrantzis) 01 Mar '24

01 Mar '24

This MR introduces support for OpenGL in the Wayland driver. Since the MR started to become somewhat long I have left some things for a subsequent part 13.2: * wgl(Get)SwapIntervalEXT (which means everything is vsync-ed at the moment) * wglShareLists * wglCreateContextAttribsARB * Fix for some apps appearing translucent in certain compositors (typically when fullscreen). Missing features not planned to be part of the 13.x MRs: * Offscreen rendering through pbuffers or pixmaps, since Wayland EGL doesn't support them (perhaps we can simulate with FBOs instead?). * Front buffer rendering. Again Wayland EGL doesn't support this, and certainly not in the form needed (i.e., the surface should be available for additional rendering with GDI). In the experimental branch I implemented a workaround that seemed to work for many cases, but will need to revisit and reevaluate options. IIRC, the most common case I have seen for this is when using wined3d/gl for older (Direct)2D games, so perhaps we can find a better solution at that layer. * Child window rendering (this needs infrastructure in Wayland driver core which will enable both GL and Vulkan rendering in child windows). * Cross-process rendering. Thanks! -- v2: winewayland.drv: Handle resizing of OpenGL content. winewayland.drv: Implement wglSwapBuffers. winewayland.drv: Implement wglMakeCurrent and wglMakeContextCurrentARB. winewayland.drv: Implement OpenGL context creation. winewayland.drv: Implement wglSetPixelFormat(WINE). winewayland.drv: Implement wglDescribePixelFormat. winewayland.drv: Implement wglGetProcAddress. winewayland.drv: Implement wglGetExtensionsString{ARB,EXT}. winewayland.drv: Initialize core GL functions. winewayland.drv: Add skeleton OpenGL driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/5177

3 37

[PATCH 0/1] MR5022: Draft: d3dx10: Add support for creating textures from DXGI_FORMAT_B4G4R4A4_UNORM DDS files.
by Connor McAdams (＠cmcadams) 01 Mar '24

01 Mar '24

Yakuza 6's Puyo Puyo minigame creates a texture from a DDS file that is the equivalent format of `DXGI_FORMAT_B4G4R4A4_UNORM`, which windowscodecs does not support. This patch converts the texture into the equivalent of `DXGI_FORMAT_R8G8B8A8_UNORM` DDS file at the start of `load_texture_data()`, which allows us to avoid having an entirely separate code path for this specific image type. This current patch just handles the most basic of DDS files, if this approach seems reasonable I will flesh it out more, I just wanted to see if it was a good/bad idea before putting anymore work into it. :) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5022

3 5

[PATCH v6 0/1] MR364: kernel32/tests: Test module refcounting with forwarded exports.
by Jinoh Kang (＠iamahuman) 01 Mar '24

01 Mar '24

Test module references created by resolving forwarded exports. The following diagram explains what happens in bug #52094 under the hood: ```mermaid graph TB subgraph state_00["Initial"] direction LR s00_ida[ida64.dll] ~~~ s00_idapy[idapython64.dll] -. "(import)" .-> s00_py3[python3.dll] -. "(forwards to)" .-> s00_py311[python311.dll] end state_00 -. "1. <code>LoadLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_01 subgraph state_01["python311.dll loaded"] direction LR s01_ida[ida64.dll] ~~~ s01_idapy[idapython64.dll] -. "(import)" .-> s01_py3[python3.dll] -. "(forwards to)" .-> s01_py311[python311.dll] s01_ida -- "dynamic ref" --> s01_py311 end state_01 -. "2. <code>LoadLibrary("</code>idapython64.dll<code>")</code>" .-> state_02 subgraph state_02["idapython64.dll loaded"] direction LR s02_ida[ida64.dll] -- "dynamic ref" --> s02_idapy[idapython64.dll] -- "static ref" --> s02_py3[python3.dll] -. "(forwards to)" .-> s02_py311[python311.dll] s02_ida -- "dynamic ref" --> s02_py311 s02_idapy -- "static forwarded ref" --> s02_py311 end state_02 -. "3. <code>FreeLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_03 subgraph state_03["python311.dll reference removed"] direction LR style s03_py311 color:#f00,stroke:#f00 s03_ida[ida64.dll] -- "dynamic ref" --> s03_idapy[idapython64.dll] -- "static ref" --> s03_py3[python3.dll] -. "(forwards to)" .-> s03_py311[python311.dll] s03_ida -. "<del>dynamic ref (deleted)</del>" .-> s03_py311 s03_idapy -- "static forwarded ref" --> s03_py311 end ``` On Windows, the static forwarded ref keeps `python311.dll` from being unloaded; however, Wine is missing this behavior, causing it to be unloaded and segfault immediately (since further initialization happens just after step 3 FreeLibrary). The tests aim to reproduce this condition. --- ### Alternative options 1. Find existing DLLs satisfying this scenario: I haven't found any in wine tree. Let me know if I missed anything. 2. Construct PE for the DLLs on-the-fly: This sounds more complicated than a handful of test DLLs. -- v6: kernel32/tests: Test module refcounting with forwarded exports. https://gitlab.winehq.org/wine/wine/-/merge_requests/364

5 9

[PATCH 0/7] MR5138: winegstreamer: Support and expose generic audio/video MFT decoders.
by Rémi Bernon (＠rbernon) 01 Mar '24

01 Mar '24

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

4 22

[PATCH v6 0/2] MR5178: winewayland.drv: set wayland app-id from the process name
by llyyr (＠llyyr) 01 Mar '24

01 Mar '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56000 -- v6: winewayland.drv: Implement SetWindowText. winewayland.drv: Set wayland app-id from the process name. https://gitlab.winehq.org/wine/wine/-/merge_requests/5178

3 8

2025

2024

2023

2022

wine-gitlab February 2024