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

[PATCH v3 0/1] MR9111: ws2_32: Implement SIO_BSP_HANDLE_SELECT.
by Josh Steffen (＠joshsteffen) 07 Oct '25

07 Oct '25

My understanding is that, in the absence of layered service providers, `SIO_BSP_HANDLE_SELECT` should behave like `SIO_BASE_HANDLE` (this is relied upon by https://github.com/python-trio/trio) Should I add tests to verify this? If so, should they basically just be the same as the existing `SIO_BASE_HANDLE` tests? -- v3: ws2_32: Implement SIO_BSP_HANDLE_SELECT. https://gitlab.winehq.org/wine/wine/-/merge_requests/9111

2 1

[PATCH v2 0/1] MR9111: ws2_32: Implement SIO_BSP_HANDLE_SELECT.
by Josh Steffen (＠joshsteffen) 07 Oct '25

07 Oct '25

My understanding is that, in the absence of layered service providers, `SIO_BSP_HANDLE_SELECT` should behave like `SIO_BASE_HANDLE` (this is relied upon by https://github.com/python-trio/trio) Should I add tests to verify this? If so, should they basically just be the same as the existing `SIO_BASE_HANDLE` tests? -- v2: ws2_32: Implement SIO_BSP_HANDLE_SELECT. https://gitlab.winehq.org/wine/wine/-/merge_requests/9111

3 6

[PATCH v3 0/7] MR9115: win32u: Implement Vulkan memory D3DKMT handle import / export.
by Rémi Bernon 07 Oct '25

07 Oct '25

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/9108, creating D3D runtime descriptors from the Vulkan info doesn't seem possible for some cases as some information have been lost (multiple stencil formats end up with the same Vulkan format, D3D bind flags transformation is not bijective). A separate, Wine-specific, D3DKMTEscape code will be exposed instead, to let D3D runtime implementations update the resource descriptors with the data they expect to find (ideally, the same descriptors as native, so importing can be compatible), after having been created and exported. (This, currently doesn't actually implements resource sharing, it only creates the D3DKMT object and exports / imports their handles. We still lack the logic to share the underlying host object fds, which will come later) -- v3: win32u: Implement Vulkan memory D3DKMT handle import from name. win32u: Implement Vulkan memory D3DKMT global / shared handle import. win32u: Implement Vulkan memory D3DKMT NT shared handle export. win32u: Create D3DKMT global resources for exported Vulkan memory. win32u: Swap VK_KHR_external_memory_win32 with the matching host extension. win32u: Pass the name of the extension to replace to get_host_extension. winevulkan: Treat LPCWSTR and HANDLE as pointer sized types. https://gitlab.winehq.org/wine/wine/-/merge_requests/9115

1 8

[PATCH v2 0/5] MR9116: win32u: Implement WGL_WINE_query_renderer extension for EGL driver
by Vasiliy Stelmachenok (＠ventureoo) 07 Oct '25

07 Oct '25

wined3d relies on `WGL_WINE_query_renderer` to get information about current render. The issue is that EGL driver does not implement this extension, which often leads to troubles for wined3d in trying to apply their quirks based only on a `GL_RENDERER` string. Because VRAM size becomes unknown, wined3d refuses to render due to "lack of memory". This MR solves the issue by implementing `WGL_WINE_query_renderer` for EGL driver. In EGL there's no extension like `GLX_MESA_query_renderer`, so we have to implement it ourselves. Some caveats of this implementation: - Obtaining some attributes involves context switching for direct quries to OpenGL driver. I tried to avoid risk of situation where we might lose current driver context, and from my tests it works, but maybe I’m missing something. - Getting vendor and device PCI IDs is done through DRM, which is a bit tricky at the moment as we have to go through devfs. This can be made cleaner through libdrm, but I don’t think we should introduce a new dependency just for a few attributes. - The `GL_NVX_gpu_memory_info` extension is used for VRAM size. It is quite common but not supported everywhere, unfortunately there is no simpler way to get information about VRAM. - There is no API for `WGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_WINE`. Same as for winemac.drv, but it’s not a big problem since it doesn’t seem to be used now. Some advantages: - Unlike GLX, we are not tied to Mesa specific extensions, which allows it to work for NVIDIA as well, sparing wined3d from having to guess something based only on the GPU name. - Unlike the same GLX, we can actually query multiple devices. Although `GLX_MESA_query_renderer` also proclaims this, in fact Mesa does not implement anything other than queries to the current renderer: https://gitlab.freedesktop.org/mesa/mesa/-/blob/32a10ccbdd1e6750c84aac3393d… Hope I didn’t miss anything. Signed-off-by: Vasiliy Stelmachenok <ventureo(a)cachyos.org> -- v2: win32u: Advertise WGL_WINE_query_renderer extension win32u: Add wglQueryRendererStringWINE implementation for EGL driver win32u: Add wglQueryRendererIntegerWINE implementation for EGL driver win32u: Add wglQueryCurrentRendererStringWINE implementation for EGL driver win32u: Add wglQueryCurrentRendererIntegerWINE implementation for EGL driver https://gitlab.winehq.org/wine/wine/-/merge_requests/9116

3 8

[PATCH 0/1] MR9119: gitlab: Install mesa-vulkan-drivers packages.
by Rémi Bernon 07 Oct '25

07 Oct '25

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

1 1

[PATCH 0/1] MR9117: gdi32: Add stub for GetEnhMetaFilePixelFormat.
by Louis Lenders (＠xe) 07 Oct '25

07 Oct '25

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

3 3

[PATCH 0/11] MR9118: odbc32: Improve arguments conversion for Unicode applications using ANSI driver.
by Piotr Caban (＠piotr) 07 Oct '25

07 Oct '25

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

2 11

[PATCH v4 0/1] MR9038: Draft: msi: implement MsiProvideAssembly[AW]()
by Ratchanan Srirattanamet (＠ratchanan.sr) 07 Oct '25

07 Oct '25

TODO: - make awstring version of MsiProvideComponent() and use that. - Actually implement MsiProvideAssemblyA() using the above. - Write conformance test? Dependency: - Have ACTION_PublishAssemblies() record feature (https://gitlab.winehq.org/wine/wine/-/merge_requests/9037) - Have MsiEnumFeatures() fixed. Currently it seems to just look for features at the wrong place and thus is useless for this purpose. (https://gitlab.winehq.org/wine/wine/-/merge_requests/9041) Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58578 -- v4: [WIP] msi: implement MsiProvideAssembly[AW]() https://gitlab.winehq.org/wine/wine/-/merge_requests/9038

3 5

[PATCH v2 0/6] MR9115: Draft: win32u: Implement Vulkan memory D3DKMT handle import / export.
by Rémi Bernon 07 Oct '25

07 Oct '25

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/9108, creating D3D runtime descriptors from the Vulkan info doesn't seem possible for some cases as some information have been lost (multiple stencil formats end up with the same Vulkan format, D3D bind flags transformation is not bijective). A separate, Wine-specific, D3DKMTEscape code will be exposed instead, to let D3D runtime implementations update the resource descriptors with the data they expect to find (ideally, the same descriptors as native, so importing can be compatible), after having been created and exported. (This, currently doesn't actually implements resource sharing, it only creates the D3DKMT object and exports / imports their handles. We still lack the logic to share the underlying host object fds, which will come later) -- v2: win32u: Implement Vulkan memory D3DKMT handle import from name. win32u: Implement Vulkan memory D3DKMT global / shared handle import. win32u: Implement Vulkan memory D3DKMT NT shared handle export. win32u: Create D3DKMT global resources for exported Vulkan memory. win32u: Swap VK_KHR_external_memory_win32 with the matching host extension. win32u: Pass the name of the extension to replace to get_host_extension. https://gitlab.winehq.org/wine/wine/-/merge_requests/9115

1 7

[PATCH 0/5] MR9116: win32u: Implement WGL_WINE_query_renderer extension for EGL driver
by Vasiliy Stelmachenok (＠ventureoo) 07 Oct '25

07 Oct '25

wined3d relies on `WGL_WINE_query_renderer` to get information about current render. The issue is that EGL driver does not implement this extension, which often leads to troubles for wined3d in trying to apply their quirks based only on a `GL_RENDERER` string. Because VRAM size becomes unknown, wined3d refuses to render due to "lack of memory". This MR solves the issue by implementing `WGL_WINE_query_renderer` for EGL driver. In EGL there's no extension like `GLX_MESA_query_renderer`, so we have to implement it ourselves. Some caveats of this implementation: - Obtaining some attributes involves context switching for direct quries to OpenGL driver. I tried to avoid risk of situation where we might lose current driver context, and from my tests it works, but maybe I’m missing something. - Getting vendor and device PCI IDs is done through DRM, which is a bit tricky at the moment as we have to go through devfs. This can be made cleaner through libdrm, but I don’t think we should introduce a new dependency just for a few attributes. - The `GL_NVX_gpu_memory_info` extension is used for VRAM size. It is quite common but not supported everywhere, unfortunately there is no simpler way to get information about VRAM. - There is no API for `WGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_WINE`. Same as for winemac.drv, but it’s not a big problem since it doesn’t seem to be used now. Some advantages: - Unlike GLX, we are not tied to Mesa specific extensions, which allows it to work for NVIDIA as well, sparing wined3d from having to guess something based only on the GPU name. - Unlike the same GLX, we can actually query multiple devices. Although `GLX_MESA_query_renderer` also proclaims this, in fact Mesa does not implement anything other than queries to the current renderer: https://gitlab.freedesktop.org/mesa/mesa/-/blob/32a10ccbdd1e6750c84aac3393d… Hope I didn’t miss anything. Signed-off-by: Vasiliy Stelmachenok <ventureo(a)cachyos.org> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9116

2 5