- Wine-GitLab - list.winehq.org

[PATCH v5 0/4] MR10261: Fix toolbar wrapping issues
by Ivan Ivlev (＠iviv) June 15, 2026

June 15, 2026

This MR resolves two bugs with toolbar wrapping I have discovered. 1. Toolbar missing four buttons when app window is maximized (wrap should not appear at all in this case). 2. Last toolbar button disappears when window size (toolbar size) is slightly narrower then button right border. Reasons of this behavior: 1. Toolbar buttons have BTNS_AUTOSIZE style, toolbar width is set using CCS_NORESIZE and equals to widths of all autosized buttons combined. cx (button width) value in TOOLBAR_WrapToolbar is set from nButtonWidth, which contains widest button width. Since buttons in toolbar have different widths, TOOLBAR_WrapToolbar miscalculates total width, because actual buttons widths are less then nButtonWidth. This results in TOOLBAR_WrapToolbar setting TBSTATE_WRAP when it is not not needed, and since app does not paint second button row, wrapped buttons just disappear. 2. After I fixed first issue, I noticed, that last button disappears, when toolbar become narrower then its right border. Then, when toolbar right border approximately in the middle of disappeared button, wrap happens. In windows system, wrapping occurs immediately when toolbar becomes narrower. Found solutions: 1. I noticed, that TOOLBAR_LayoutToolbar calculates buttons rects differently, thats because it checks if button have BTNS_AUTOSIZE style and then calculate size. So i moved this BTNS_AUTOSIZE size calculation in separate function for it to then be used in TOOLBAR_LayoutToolbar and TOOLBAR_WrapToolbar to guarantee that cx values for specific button will be equal in both functions. 2. TOOLBAR_WrapToolbar function decides to wrap in case `if ((x + cx - (infoPtr->nButtonWidth - infoPtr->nBitmapWidth) / 2 > width).` This `(infoPtr->nButtonWidth - infoPtr->nBitmapWidth) / 2` turns out, makes this gap, where button right border (x + cx) exceed toolbar right border (width), but wrap wont appear. I did not found any reasons to make this half-button gap, so I just removed it and it solved this issue. The comment above says /\* The layout makes sure the bitmap is visible, but not the button. \*/, but it was introduced in 1999, when TOOLBAR_LayoutToolbar did not existed, and I think its irrelevant now, since layout calculates cx taking both bitmap and string into account. I wrote tests for both fixes: 1. Creates CCS_NORESIZE toolbar, then add BTNS_AUTOSIZE buttons of different widths one by one and checks if wrap happened. In normal case (in windows) wrap should only happen on fourth button, but without fix wrap happens on third. 2. Creates CCS_NORESIZE toolbar with 4 BTNS_AUTOSIZE buttons. Toolbar width at the creation is calculated beforehand and equals exactly buttons widths combined. Then test reduces toolbar width by 1 and checks if wrap happened, in normal case wrap happens, without the fix its not. -- v5: comctl32/toolbar.c: Wrap toolbar immidiately after width exceeded. comctl32/tests/toolbar.c: Test wrapping occurs immidiately when needed. comctl32/toolbar.c: Move BTNS_AUTOSIZE processing from LayoutToolbar in a separate function and use it in WrapToolbar. comctl32/tests/toolbar.c: Test wrapping for fixed size toolbar and autosized buttons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10261

2 5

[PATCH v2 0/1] MR11130: vbscript: Use a name-sorted index for named item lookups.
by Francis De Brabandere (＠francisdb) June 15, 2026

June 15, 2026

Named item lookups walk the item list linearly, so hosts that register many named items pay a cost proportional to the item count for every host object reference a script makes. Visual Pinball is the motivating case: it registers one named item per table element, and complex tables reach roughly 1600 items, so table scripts pay an ~800-compare average scan on every element reference during table load and play. Keep a lazily rebuilt name-sorted index over the named item list and binary search it. Insertion sort keeps items sharing a name in list order, so index lookups return the same item a list walk would, including the flags filtering and the fallthrough to a later item when the host fails to resolve one. The linear walk is kept as a fallback when allocating the index fails. Measured with a small benchmark host that registers N `SCRIPTITEM_ISVISIBLE` named items backed by a trivial `IDispatch` and times `ParseScriptText` with `QueryPerformanceCounter`, 300k iterations per loop, 1600 items: | Benchmark | before | after | native (Win10) | | ------------------------------------------ | ---------: | --------: | -------------: | | Builtin call loop (`s = Trim(" x ")`) | 140.6 ms | 132.2 ms | 20.0 ms | | Last item ref loop (`Set o = Itm1599`) | 1655.0 ms | 116.9 ms | 10.2 ms | | Last item member loop (`v = Itm1599.prop`) | 1662.8 ms | 123.8 ms | 62.7 ms | | First item ref loop (`Set o = Itm0000`) | 101.0 ms | 117.0 ms | 8.6 ms | Lookup time was linear in the item count (694 ms at 500 items) and is now flat across item count and position, matching native's profile with the same host. The first item loop is the old code's best case (head of the list); the index trades it for position independence. The remaining gap to native is the per-reference lookup itself: native appears to resolve a name once and reuse the binding. Extending the recent bind-at-compile-time work to named items and builtins could remove the lookup from the loop entirely, with this index serving as the bind-time resolver. This was discovered while working on !11128 -- v2: vbscript: Index named items by name. https://gitlab.winehq.org/wine/wine/-/merge_requests/11130

3 3

[PATCH v2 0/2] MR11094: cmd: Add wildcard expansion for type command.
by Barath Kannan (＠barath_kannan) June 15, 2026

June 15, 2026

Fixes: https://bugs.winehq.org/show_bug.cgi?id=59816 Signed-off-by: Barath Kannan barathrk11(a)gmail.com -- v2: cmd: Implement wildcard expansion for the type command's arguments. cmd: Add tests for type wildcard expansion. https://gitlab.winehq.org/wine/wine/-/merge_requests/11094

3 10

[PATCH 0/1] MR11156: dinput: Lowercase device paths passed into insert_cache_entry() when reusing cache entries.
by Connor McAdams (＠cmcadams) June 15, 2026

June 15, 2026

Fixes a bug in "Like A Dragon: Infinite Wealth", which uses the path returned by DIPROP_GUIDANDPATH to detect XInput devices. We already do this in `cache_entry_create()`, but must have accidentally missed the case where we reuse a cache entry. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11156

3 2

Re: [PATCH v3 0/3] MR11025: libs: Import upstream code from SymCrypt 103.11.0.
by Paul Menzel (＠pmenzel) June 15, 2026

June 15, 2026

I get several errors with LLVM/Clang 16.0.1: $ md5sum wine-11.11.tar.xz b443f980be556567eb7f25be995c9825 wine-11.11.tar.xz $ lld-link --version LLD 16.0.1 $ clang --version clang version 16.0.1 Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /pkg/llvm-16.0.1-0/bin $ ./configure --prefix=/dev/shm/pmenzel/local/wine-11.11-0 --with-x --with-gnutls --with-opengl --without-vulkan --with-wayland --enable-win64 --enable-archs=x86_64 --disable-tests `make` results in the errors below: ``` In file included from libs/symcrypt/lib/aes-xmm.c:741: libs/symcrypt/lib/aes-pattern.c:210:13: error: call to undeclared function '_mm_shuffle_epi8'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] chain = _mm_shuffle_epi8( chain, BYTE_REVERSE_ORDER ); ^ libs/symcrypt/lib/aes-pattern.c:210:11: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' chain = _mm_shuffle_epi8( chain, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:241:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c0 = _mm_shuffle_epi8( c0, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:242:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c1 = _mm_shuffle_epi8( c1, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:243:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c2 = _mm_shuffle_epi8( c2, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:244:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c3 = _mm_shuffle_epi8( c3, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:245:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c4 = _mm_shuffle_epi8( c4, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:246:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c5 = _mm_shuffle_epi8( c5, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:247:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c6 = _mm_shuffle_epi8( c6, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:248:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c7 = _mm_shuffle_epi8( c7, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:311:16: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c0 = _mm_shuffle_epi8( c0, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:312:16: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c1 = _mm_shuffle_epi8( c1, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:313:16: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c2 = _mm_shuffle_epi8( c2, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:314:16: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c3 = _mm_shuffle_epi8( c3, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:337:16: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c0 = _mm_shuffle_epi8( c0, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:344:11: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' chain = _mm_shuffle_epi8( chain, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from libs/symcrypt/lib/aes-xmm.c:751: libs/symcrypt/lib/aes-pattern.c:210:13: error: call to undeclared function '_mm_shuffle_epi8'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] chain = _mm_shuffle_epi8( chain, BYTE_REVERSE_ORDER ); ^ libs/symcrypt/lib/aes-pattern.c:210:11: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' chain = _mm_shuffle_epi8( chain, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/symcrypt/lib/aes-pattern.c:241:12: error: assigning to '__m128i' (vector of 2 'long long' values) from incompatible type 'int' c0 = _mm_shuffle_epi8( c0, BYTE_REVERSE_ORDER ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. make: *** [Makefile:170664: libs/symcrypt/x86_64-windows/lib/aes-xmm.o] Error 1 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11025#note_143135

1 0

[PATCH v4 0/2] MR11110: dxgi/tests: Skip tests if DXGI 1.4 is not available.
by Bernhard Übelacker (＠bernhardu) June 15, 2026

June 15, 2026

-- v4: dxgi/tests: Add two missing winetest_pop_context. dxgi/tests: Skip tests if DXGI 1.4 is not available. https://gitlab.winehq.org/wine/wine/-/merge_requests/11110

3 5

[PATCH v3 0/1] MR11155: ntdll: Don't validate arm64 pointer signing when unwinding.
by Martin Storsjö (＠mstorsjo) June 15, 2026

June 15, 2026

When unwinding through a "pac_sign_lr" opcode, we need to strip out pointer authentication bits from the address in the LR register. Previously this was done with the "autib1716" instruction, which does validate that the address in x17 is properly signed with the B key, given the reference address in x16 (SP). However - Clang has a bug [1] since Clang 19, that has caused it to generate incorrect prologues (if building with "-mbranch-protection=standard"), doing return address signing using the A key, while the unwind info says that the address should be signed using the B key. (The unwind info has no way of signaling which key to use, but the normative form uses the B key.) It also turns out that Windows doesn't do any validation of the signing of the return address when unwinding; Windows can correctly execute and do unwinding in binaries built with the buggy Clang - which might explain why the bug has passed unnoticed for so long. Therefore, doing the same and reducing the strictness here in Wine seems reasonable (in addition to doing it to work around the Clang bug). In addition to failing on unwinding in user binaries built return address signing (e.g. "-mbranch-protection=standard") with a buggy Clang, this issue also hits cases if Wine itself has been built with "-mbranch-protection=standard" in CROSSCFLAGS, with a buggy version of Clang. This is the case on e.g. Ubuntu 26.04, making those builds of Wine fail (either directly on startup, or failing only if attempting to do unwinding in user code), if running on a CPU that supports pointer authentication. [1] https://github.com/llvm/llvm-project/issues/203852 -- v3: ntdll: Don't validate arm64 pointer signing when unwinding. https://gitlab.winehq.org/wine/wine/-/merge_requests/11155

2 1

[PATCH v2 0/1] MR11155: ntdll: Don't validate arm64 pointer signing when unwinding.
by Martin Storsjö (＠mstorsjo) June 15, 2026

June 15, 2026

When unwinding through a "pac_sign_lr" opcode, we need to strip out pointer authentication bits from the address in the LR register. Previously this was done with the "autib1716" instruction, which does validate that the address in x17 is properly signed with the B key, given the reference address in x16 (SP). However - Clang has a bug [1] since Clang 19, that has caused it to generate incorrect prologues (if building with "-mbranch-protection=standard"), doing return address signing using the A key, while the unwind info says that the address should be signed using the B key. (The unwind info has no way of signaling which key to use, but the normative form uses the B key.) It also turns out that Windows doesn't do any validation of the signing of the return address when unwinding; Windows can correctly execute and do unwinding in binaries built with the buggy Clang - which might explain why the bug has passed unnoticed for so long. Therefore, doing the same and reducing the strictness here in Wine seems reasonable (in addition to doing it to work around the Clang bug). In addition to failing on unwinding in user binaries built return address signing (e.g. "-mbranch-protection=standard") with a buggy Clang, this issue also hits cases if Wine itself has been built with "-mbranch-protection=standard" in CROSSCFLAGS, with a buggy version of Clang. This is the case on e.g. Ubuntu 26.04, making those builds of Wine fail (either directly on startup, or failing only if attempting to do unwinding in user code), if running on a CPU that supports pointer authentication. [1] https://github.com/llvm/llvm-project/issues/203852 -- v2: ntdll: Don't validate arm64 pointer signing when unwinding. https://gitlab.winehq.org/wine/wine/-/merge_requests/11155

2 1

[PATCH v7 0/9] MR10954: nsiproxy.sys: Reuse icmp sockets for multiple requests and support receiving error packets with Linux ping sockets.
by Paul Gofman (＠gofman) June 15, 2026

June 15, 2026

-- v7: nsiproxy.sys: Use compatible ICMP request id and seq numbers. nsiproxy.sys: Support ICMP error replies with ping sockets. nsiproxy.sys: Reuse icmp socket with matching parameters. nsiproxy.sys: Return ICMP ids from parse_icmp_hdr() instead of matching those. nsiproxy.sys: Poll all icmp sockets in a single thread. nsiproxy.sys: Manage ICMP listen threads on the Unix side. nsiproxy.sys: Contain all the reply data in struct icmp_reply_ctx. nsiproxy.sys: Rename icmp_listen into icmp_get_reply. nsiproxy.sys: Factor out icmp_socket structure. https://gitlab.winehq.org/wine/wine/-/merge_requests/10954

3 11

[PATCH 0/1] MR11155: Draft: ntdll: Don't validate arm64 pointer signing when unwinding.
by Martin Storsjö (＠mstorsjo) June 15, 2026

June 15, 2026

When unwinding through a "pac_sign_lr" opcode, we need to strip out pointer authentication bits from the address in the LR register. Previously this was done with the "autib1716" instruction, which does validate that the address in x17 is properly signed with the B key, given the reference address in x16 (SP). However - Clang has a bug [1] since Clang 19, that has caused it to generate incorrect prologues (if building with "-mbranch-protection=standard"), doing return address signing using the A key, while the unwind info says that the address should be signed using the B key. (The unwind info has no way of signaling which key to use, but the normative form uses the B key.) It also turns out that Windows doesn't do any validation of the signing of the return address when unwinding; Windows can correctly execute and do unwinding in binaries built with the buggy Clang - which might explain why the bug has passed unnoticed for so long. Therefore, doing the same and reducing the strictness here in Wine seems reasonable (in addition to doing it to work around the Clang bug). In addition to failing on unwinding in user binaries built return address signing (e.g. "-mbranch-protection=standard") with a buggy Clang, this issue also hits cases if Wine itself has been built with "-mbranch-protection=standard" in CROSSCFLAGS, with a buggy version of Clang. This is the case on e.g. Ubuntu 26.04, making those builds of Wine fail (either directly on startup, or failing only if attempting to do unwinding in user code), if running on a CPU that supports pointer authentication. --- One reason for initially handling "pac_sign_lr" with the "autib1617" instruction was that this instruction can be encoded as a hint instruction, which any CPU can execute, and CPUs not implementing pointer authentication treats it as a nop. If doing the stripping out of pointer authentication using "xpaci", then we must only execute that instruction on CPUs that support it. There is no flag for IsProcessorFeaturePresent for checking for pointer authentication. (Also, we can't just assemble the instruction as such without enabling pointer authentication support in the assembler - but we can assemble it using ".inst".) Instead, do pointer signing using the regular "pacibsp" instruction (which can be encoded as a hint instruction) and check if it results in changed bits in the address. And in case the B key would happen to be disabled (resulting in no changed bits) while the code erroneously signs using the A key (if that one is enabled), also check if "paciasp" changes any bits. If either of them changes bits, we can be sure that pointer authentication is available and we can execute the "xpaci" instruction. [1] https://github.com/llvm/llvm-project/issues/203852 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11155

2 2

[PATCH v3 0/6] MR11111: libs: FFmpeg initial import
by Alexandre Julliard (＠julliard) June 15, 2026

June 15, 2026

Initial subset of !10687, without any asm optimizations. -- v3: resampledmo: Move resampler implementation from winegstreamer. winegstreamer/resampler: Translate IMFTransform calls to IMediaObject. winegstreamer/resampler: Implement IMediaObject iface using libswresample. winegstreamer: Remove unnecessary resampler inline qualifiers. ffmpeg: Redirect av_log calls to Wine debug traces. libs: Import ffmpeg from upstream release 8.1.1. https://gitlab.winehq.org/wine/wine/-/merge_requests/11111

3 6

[PATCH 0/1] MR11092: mf/topology_loader: Restore original type when optional connection fails.
by Rémi Bernon (＠rbernon) June 15, 2026

June 15, 2026

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

3 4

[PATCH v8 0/5] MR5068: win32u: Fix rendering of the rotated and scaled text.
by Dmitry Timoshkov (＠dmitry) June 15, 2026

June 15, 2026

These patches make a test case attached to the bug https://bugs.winehq.org/show_bug.cgi?id=33190 work. -- v8: win32u: NtGdiExtTextOutW() should translate x,y from logical to device units at the last step. win32u: Fix device<->world width/height converters. win32u: Use slightly more readable names for DP/LP converters. win32u: Use correct helper for converting width to device units. gdi32/tests: Add some tests for rotated font metrics. https://gitlab.winehq.org/wine/wine/-/merge_requests/5068

4 19

[PATCH 0/1] MR11147: winewayland: Do not detach client surface on update.
by Etaash Mathamsetty (＠etaash.mathamsetty) June 15, 2026

June 15, 2026

This matches winex11 behavior and fixes Splitgate Arena Reloaded. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11147

3 3

[PATCH v6 0/4] MR11117: winewayland: Implement pointer rawinput.
by Etaash Mathamsetty (＠etaash.mathamsetty) June 15, 2026

June 15, 2026

Implements rawinput by refactoring a few things and adding a wine staging patch. Also fixes a few bugs with the existing pointer implementation, which can cause the mouse cursor to escape or is just inefficient. As much as I would like to make relative pointer protocol mandatory, most compositors don't support it in their nested mode, which makes this a very difficult tradeoff to make. For now I have left it optional. -- v6: winewayland: Implement pointer rawinput. server: Add send_hardware_message flags for rawinput translation. https://gitlab.winehq.org/wine/wine/-/merge_requests/11117

4 6

[PATCH v2 0/1] MR11140: win32u: Always flush the window surface in expose_window_surface.
by Etaash Mathamsetty (＠etaash.mathamsetty) June 15, 2026

June 15, 2026

This matches the old behavior for winewayland before this function was introduced. For future work (like for fractional scaling or xdg-popup), expose does need to flush the window surface every single time, not just when there is an alpha mask. -- v2: win32u: Always flush the window surface in expose_window_surface. https://gitlab.winehq.org/wine/wine/-/merge_requests/11140

3 2

Re: [PATCH v3 0/1] MR10265: Draft: winewayland: Implement support for min/max window size hints. - closed
by Etaash Mathamsetty (＠etaash.mathamsetty) June 15, 2026

June 15, 2026

This merge request was closed by Etaash Mathamsetty. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10265

1 0

[PATCH 0/4] MR11139: xinput1_3: Some minor fixes.
by Shaun Ren (＠shaunren) June 15, 2026

June 15, 2026

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

4 5

[PATCH 0/1] MR11153: opengl32: Remove unused unix thunks.
by Rémi Bernon (＠rbernon) June 15, 2026

June 15, 2026

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

2 1

[PATCH 0/4] MR11152: opengl32: Implement object name isolation for the remaining object types.
by Rémi Bernon (＠rbernon) June 15, 2026

June 15, 2026

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

2 4

[PATCH v7 0/1] MR11101: winewayland: Implement fractional scaling protocol.
by Etaash Mathamsetty (＠etaash.mathamsetty) June 15, 2026

June 15, 2026

The idea behind this is to use fractional scaling to make it appear as if the Wine environment is running at the user-specified DPI in winecfg while keeping the windows looking crisp. This enables users to have different fractional scales per display under wine without causing blur. This matches the behavior under XWayland and is actually better than the XWayland behavior when using multiple displays with different fractional scales. FWIW: Mutter has a bug with its implementation of fractional scaling that has been recently fixed in case this compositor is being used to try this implementation: <https://gitlab.gnome.org/GNOME/mutter/-/work_items/4834> -- v7: winewayland: Implement fractional scaling protocol. https://gitlab.winehq.org/wine/wine/-/merge_requests/11101

3 2

[PATCH v5 0/2] MR11135: win32u/tests: add test for swp_owner_popups self-reference fix
by Jiajin Cui (＠jin-king1) June 14, 2026

June 14, 2026

Add test_swp_owner_popups to verify that swp_owner_popups restores initial_after when it becomes the window itself. When an owned popup is immediately above its owner in z-order and is moved after the owner, the function incorrectly sets after = hwnd (self-reference). The fix restores initial_after, and the test verifies this via WM_WINDOWPOSCHANGED hwndInsertAfter capture. Change-Id: I1f63fc4046d65ea767beafbcae4f6f26b25a26ba Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- v5: win32u: restore initial after value in swp_owner_popups win32u/tests: add test for swp_owner_popups self-reference fix https://gitlab.winehq.org/wine/wine/-/merge_requests/11135

2 2

[PATCH v4 0/1] MR10279: configure.ac: fixes libusb detection on FreeBSD
by Thibault Payet (＠thpayet) June 14, 2026

June 14, 2026

This fixes libusb detection on FreeBSD. I don't have a simple program to test though, nor a specific peripheral that need such access. I haven't build on GNU/Linux, but I think that it should not be impacted (hopefully, the build cluster will tell us). -- v4: configure.ac: fixes libusb detection on FreeBSD https://gitlab.winehq.org/wine/wine/-/merge_requests/10279

3 7

[PATCH v2 0/2] MR11150: wshom.ocx: Fix Popup not waiting correctly
by Anders Kjersem (＠anders) June 14, 2026

June 14, 2026

`MsgWaitForMultipleObjects` can return immediately if the current thread already has a message waiting (posted by something unrelated to this function). We need to process messages until the handle we actually care about becomes signaled or times out. -- v2: (Style) Fix old missing space https://gitlab.winehq.org/wine/wine/-/merge_requests/11150

2 2

[PATCH v4 0/1] MR11148: ksecdd.sys: Implement BCrypt* functions by redirecting to bcrypt.dll equivalents
by tobbi (＠tobbi) June 14, 2026

June 14, 2026

I just found out that the functions were unimplemented in that file, but that a (mostly complete) implementation was available in the bcrypt.dll. Thus, I redirected those calls. -- v4: ksecdd.sys: Implement BCrypt functions by redirecting to equivalent bcrypt.dll implementations https://gitlab.winehq.org/wine/wine/-/merge_requests/11148

2 1