September 2025 - wine-gitlab

[PATCH v8 0/5] MR5068: win32u: Fix rendering of the rotated and scaled text.
by Dmitry Timoshkov (＠dmitry) 17 Oct '25

17 Oct '25

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

3 16

[PATCH 0/1] MR8931: winex11.drv: Fixing an issue where the window size was not saved after...
by Ivan Lyugaev (＠valy) 16 Oct '25

16 Oct '25

winex11.drv: Fixing an issue where the window size was not saved after switching from full-screen mode When switching from maximized window to windowed mode, the window retains the size of the entire screen. This bug is reproducible in xfce. Upon closer examination of the logs, I noticed that xfce was duplicating ConfigureNotify requests. The duplicate requests had the send_event=TRUE flag. These requests caused the window to resize incorrectly. The current implementation of wine uses the asynchronous ConfigureNotify event notification method - NtUserPosteMessage with the WM_WINE_WINDOW_STATE_CHANGED flag. I suggest returning to the synchronous method using Send_message. This bug is a regression. This issue first appeared in commit 0f1d999b, which moved the handling of GetWindowStateUpdates in win32u/message.c to the handle_internal_message function via NtUserPostMessage. I decided to revert the handling logic to before this patch was applied, adapting it to the current handling of GetWindowStateUpdates in win32u/message.c This solution was tested in xfce, mate, and a number of different programs. Everything worked correctly -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8931

3 8

[PATCH 0/1] MR8933: mf: Update the stream sink input type when a transform output type changes.
by Conor McCarthy (＠cmccarthy) 14 Oct '25

14 Oct '25

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

3 3

[PATCH v7 0/2] MR8887: mf/tests: Test H.264 sink media type height alignment.
by Conor McCarthy (＠cmccarthy) 14 Oct '25

14 Oct '25

H.264 uses a 16-pixel alignment, and the stream sink media type should have the aligned height after the session has started. -- v7: mf/tests: Test H.264 decoder alignment. mf/tests: Test H.264 sink media type height alignment. https://gitlab.winehq.org/wine/wine/-/merge_requests/8887

3 3

[PATCH v3 0/1] MR8988: win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor...
by Kun Yang (＠yangkun) 12 Oct '25

12 Oct '25

win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor when using StretchBlt in TransparentBlt. In NtGdiTransparentBlt function, the StretchBlt mode of dst hdc is not set. The Default StretchBlt Mode in wine is BlackOnWhite. It is not correct to use this StretchBltMode in TransparentBlt dealing with color bitmap. According to MSDN, it should be converted to ColorOnColor. My test code shows that, the image converted by wine generates a lot of chromatic noise. [test_blt.c](/uploads/26101bc7bdb27400d02c8ff5bf741864/test_blt.c) [test_blt.exe](/uploads/98ee3ab7ce0d590e1511bd8a5fb5a1bb/test_blt.exe) ![source](/uploads/0c56c5e6d1280040ba08cd3dee7acd95/source.bmp) ![result_wrong](/uploads/2076396e069f852914313a8fb86dd5e2/result_wrong.bmp) ![result](/uploads/cf3ec00bf0f0e7f3ea7fe1e2085385d6/result.bmp) -- v3: win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor when using StretchBlt in TransparentBlt. https://gitlab.winehq.org/wine/wine/-/merge_requests/8988

3 5

[PATCH v2 0/1] MR411: win32u: Don't load bitmap only TTF fonts without bitmap table.
by Paul Gofman (＠gofman) 12 Oct '25

12 Oct '25

The offending font is NotoColorEmoji.ttf which is present in, e. g., google-noto-emoji-color-fonts or noto-fonts-emoji packages available in various distribution. Attempting to load this font on Windows 10 (with AddFontResourceA() or open it with default font viewer) fails while currently succeeds on Windows. fontforge also refuses to open this font. That is because the font is bitmap only but missing bitmap table. Some apps (Glyph launcher is an example) try to GetOutlineTextMetrics() on this font and do not expect that to have an error return (as we currenly do), which leads to crash on unhandled division by zero exception. I am attaching a bitmap-only ttf test font (with only one bitmap) which I created with fontforge to make sure that such font can still be loaded in Wine. This font also loads on Windows (both with AddFontResourceA() and with default font viewer). There are other font types which can be legitimately missing EBDT table, but FT_Load_Sfnt_Table() returns a different error for those and my patch doesn't reject those fonts. [test.ttf](/uploads/b41472180b80c2c53f9dcc06055990f0/test.ttf) -- v2: win32u: Don't load bitmap only TTF fonts without bitmap table. https://gitlab.winehq.org/wine/wine/-/merge_requests/411

3 2

[PATCH 0/1] MR6140: ntdll: Exclude biggest envars to fit 32767 chars limit in get_initial_environment.
by Martino Fontana (＠tinozzo123) 11 Oct '25

11 Oct '25

Windows has a limit of 32767 characters in the environment block. https://superuser.com/questions/1070272/why-does-windows-have-a-limit-on-en… Wine doesn't attempt to respect that at all. Do some programs actually depend on this? Unfortunately yes. With this patch, during initialization, if the block size would exceed (or be close to) the limit, the biggest environment variables will be excluded. This is useful when a user has very long environment variables in their system for reasons unrelated to Wine. Do note that there's still nothing done to make sure that the limit isn't exceeded after initialization. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56941 Signed-off-by: Martino Fontana <tinozzo123(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6140

7 12

[PATCH 0/1] MR9051: qasf: Implement seeking for asf reader.
by Ziqing Hui (＠zhui) 10 Oct '25

10 Oct '25

This fixes media replay for BlazeBlue. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9051

4 10

[PATCH v2 0/3] MR8760: mmdevapi: Add support for storing/retrieving more variant types from the device property store.
by Connor McAdams (＠cmcadams) 09 Oct '25

09 Oct '25

This has been implemented in a few different ways (see MR !7238 and MR !359), neither of which have associated tests. This way of doing things sidesteps the need to update existing `VT_BLOB` properties by just storing/retrieving them in the same format we always have. If the registry data doesn't match a set of criteria, we treat it as `VT_BLOB` always. -- v2: mmdevapi: Add support for storing VT_CLSID properties. mmdevapi: Add support for storing VT_BOOL properties. https://gitlab.winehq.org/wine/wine/-/merge_requests/8760

3 6

[PATCH v2 0/8] MR8965: Draft: win32u: Flush window surfaces from owner thread, while waiting for messages.
by Rémi Bernon (＠rbernon) 09 Oct '25

09 Oct '25

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/8869 I think this would be a much lighter and less complicated approach than trying to wake the window threads with internal messages. And it should be able to avoid spurious wake ups when there's no window surfaces involved. What I'm not completely sure about is whether this is going to flush the surfaces frequently enough, and if we can assume the window thread will always either peek or wait for messages. -- v2: win32u: Keep window surfaces in a per-thread linked list. win32u: Remove window surface flush in expose_window_surface. win32u: Remove window surface flush on lock / unlock. win32u: Remove some less useful flush_window_surfaces. win32u: Flush window surfaces while waiting for messages. win32u: Use an absolute wait timeout in wait_message. win32u: Remove unnecessary window_surface exports. win32u: Dispatch NtUserUpdateLayeredWindow to the owner thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/8965

2 10

2025

2024

2023

2022

wine-gitlab September 2025