June 2026 - Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/4] MR11035: gdi32/uniscribe: Eagerly cache cmap tables for a font.
by समीरसिंह Sameer Singh (＠ss141309) June 1, 2026

June 1, 2026

On Mon Jun 1 11:28:47 2026 +0000, Nikolay Sivov wrote: > Then referenced font objects could also be kept around, after GDI > handles are released. The point is that keeping just cmap is clearly not > enough for shaping to work. And duplicating all of the font data for > every cache instance also would be a strange solution. Regarding. "keeping just cmap is clearly not enough for shaping to work", the `ScriptCache` struct already stores raw table data for GSUB, GPOS and GDEF so shaping is possible. Adding cmap format4 to the struct (cmap format 12 was already present) follows the same established pattern. Here is what the struct looked prior to my patch: ```c typedef struct { struct list entry; DWORD refcount; LOGFONTW lf; TEXTMETRICW tm; OUTLINETEXTMETRICW *otm; SCRIPT_FONTPROPERTIES sfp; BOOL sfnt; CacheGlyphPage *page[NUM_PAGES]; ABC *widths[GLYPH_MAX / GLYPH_BLOCK_SIZE]; void *GSUB_Table; void *GDEF_Table; void *CMAP_Table; void *CMAP_format12_Table; void *GPOS_Table; BOOL scripts_initialized; LoadedScript *scripts; SIZE_T scripts_size; SIZE_T script_count; OPENTYPE_TAG userScript; OPENTYPE_TAG userLang; } ScriptCache; ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11035#note_141855

1 0

Re: [PATCH v2 0/4] MR11035: gdi32/uniscribe: Eagerly cache cmap tables for a font.
by Nikolay Sivov (＠nsivov) June 1, 2026

June 1, 2026

On Mon Jun 1 10:41:38 2026 +0000, समीरसिंह Sameer Singh wrote: > I don't think that is the case. I tried running this program on windows, > where I make two calls to `ScriptShapeOpenType` and in between the first > and second call I delete the `dc` . If windows cached the HDC then the > second called would have failed, but that is not the case the shaping > was done successfully. > ```c > #include <windows.h> > #include <usp10.h> > #include <stdio.h> > #define MAKE_OPENTYPE_TAG(a,b,c,d) \ > ((OPENTYPE_TAG)(a) | ((OPENTYPE_TAG)(b) << 8) | \ > ((OPENTYPE_TAG)(c) << 16) | ((OPENTYPE_TAG)(d) << 24)) > int main(void) { > static const WCHAR test1[] = {'O','n','e',0}; > static const WCHAR test2[] = {'T','w','o',0}; > HDC hdc = CreateCompatibleDC(NULL); > HFONT font = CreateFontA(20, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, > DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, > DEFAULT_QUALITY, DEFAULT_PITCH, "Tahoma"); > HFONT orig_font = SelectObject(hdc, font); > WORD glyphs[4], logclust[4]; > SCRIPT_CHARPROP charProp[4]; > SCRIPT_GLYPHPROP glyphProp[4]; > int pcGlyphs = 0; > SCRIPT_CACHE sc = NULL; > SCRIPT_ANALYSIS sa = {0}; > sa.eScript = 1; > OPENTYPE_TAG scriptTag = MAKE_OPENTYPE_TAG('l', 'a', 't', 'n'); > HRESULT hr = ScriptShapeOpenType(hdc, &sc, &sa, scriptTag, 0, NULL, > NULL, 0, test1, 3, 3, logclust, charProp, glyphs, glyphProp, &pcGlyphs); > if (FAILED(hr)) { > printf("Shaping failed for the first run. hr=%08lx\n", hr); > return -1; > } > DeleteDC(hdc); > DeleteObject(font); > hr = ScriptShapeOpenType(NULL, &sc, &sa, scriptTag, 0, NULL, NULL, 0, > test2, 3, 3, logclust, charProp, glyphs, glyphProp, &pcGlyphs); > if (FAILED(hr)) { > printf("Shaping failed for the second run. hr=%08lx\n", hr); > return -1; > } > printf("Shaping successful for the second run. hr=%08lx\n", hr); > ScriptFreeCache(&sc); > return 0; > } > ``` > Output: > ``` > Shaping successful for the second run. hr=00000000 > ``` Then referenced font objects could also be kept around, after GDI handles are released. The point is that keeping just cmap is clearly not enough for shaping to work. And duplicating all of the font data for every cache instance also would be a strange solution. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11035#note_141853

1 0

[PATCH 0/2] MR11042: jscript,vbscript: Remove unused variables.
by Jacek Caban (＠jacek) June 1, 2026

June 1, 2026

Fixes -Wunused-but-set-global warnings. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11042

2 2

Re: [PATCH v2 0/4] MR11035: gdi32/uniscribe: Eagerly cache cmap tables for a font.
by समीरसिंह Sameer Singh (＠ss141309) June 1, 2026

June 1, 2026

On Mon Jun 1 10:38:38 2026 +0000, Nikolay Sivov wrote: > This could also mean that HDC handle is cached, not the data itself. I don't think that is the case. I tried running this program on windows, where I make two calls to `ScriptShapeOpenType` and in between the first and second call I delete the `dc` . If windows cached the HDC then the second called would have failed, but that is not the case the shaping was done successfully. ```c #include <windows.h> #include <usp10.h> #include <stdio.h> #define MAKE_OPENTYPE_TAG(a,b,c,d) \ ((OPENTYPE_TAG)(a) | ((OPENTYPE_TAG)(b) << 8) | \ ((OPENTYPE_TAG)(c) << 16) | ((OPENTYPE_TAG)(d) << 24)) int main(void) { static const WCHAR test1[] = {'O','n','e',0}; static const WCHAR test2[] = {'T','w','o',0}; HDC hdc = CreateCompatibleDC(NULL); HFONT font = CreateFontA(20, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH, "Tahoma"); HFONT orig_font = SelectObject(hdc, font); WORD glyphs[4], logclust[4]; SCRIPT_CHARPROP charProp[4]; SCRIPT_GLYPHPROP glyphProp[4]; int pcGlyphs = 0; SCRIPT_CACHE sc = NULL; SCRIPT_ANALYSIS sa = {0}; sa.eScript = 1; OPENTYPE_TAG scriptTag = MAKE_OPENTYPE_TAG('l', 'a', 't', 'n'); HRESULT hr = ScriptShapeOpenType(hdc, &sc, &sa, scriptTag, 0, NULL, NULL, 0, test1, 3, 3, logclust, charProp, glyphs, glyphProp, &pcGlyphs); if (FAILED(hr)) { printf("Shaping failed for the first run. hr=%08lx\n", hr); return -1; } DeleteDC(hdc); DeleteObject(font); hr = ScriptShapeOpenType(NULL, &sc, &sa, scriptTag, 0, NULL, NULL, 0, test2, 3, 3, logclust, charProp, glyphs, glyphProp, &pcGlyphs); if (FAILED(hr)) { printf("Shaping failed for the second run. hr=%08lx\n", hr); return -1; } printf("Shaping successful for the second run. hr=%08lx\n", hr); ScriptFreeCache(&sc); return 0; } ``` Output: ``` Shaping successful for the second run. hr=00000000 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11035#note_141849

1 0

[PATCH 0/1] MR11039: winhttp: Revert recursion limit to 3.
by Hans Leidekker (＠hans) June 1, 2026

June 1, 2026

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

2 1

[PATCH v3 0/2] MR11016: msxml3: Don't indent endElement node since it changes text node content.
by Piotr Caban (＠piotr) June 1, 2026

June 1, 2026

-- v3: msxml3: Don't indent endElement since it changes text node content. msxml3: Don't add newline before first element when indentation is enabled. https://gitlab.winehq.org/wine/wine/-/merge_requests/11016

3 4

[PATCH 0/1] MR11038: server: Fix numpad vkey handling.
by Rémi Bernon (＠rbernon) June 1, 2026

June 1, 2026

It looks like 2eeb4d5192e808c18e5949cc1c14b51b22fee342 missed updating the hunk introduced a bit earlier by 11ef7af768427a8fe38a43351377100086357388. Fixes: 2eeb4d5192e808c18e5949cc1c14b51b22fee342 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11038

3 3

Re: [PATCH v2 0/4] MR11035: gdi32/uniscribe: Eagerly cache cmap tables for a font.
by Nikolay Sivov (＠nsivov) June 1, 2026

June 1, 2026

This could also mean that HDC handle is cached, not the data itself. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11035#note_141839

1 0

[PATCH v3 0/1] MR10916: secur32: Return SEC_E_INVALID_TOKEN for invalid TLS record headers
by Ivan Lyugaev (＠valy) June 1, 2026

June 1, 2026

I encountered an issue with establishing an encrypted connection to the mail server in Outlook. I managed to find out that Outlook tries various connection setup options — in particular, it sends a ClientHello to server port 587, and in response receives an SMTP banner, which in the establish_context function (https://gitlab.winehq.org/wine/wine/-/blame/master/dlls/secur32/schannel.c?…) is mistakenly interpreted as TLS and returns a SEC_E_INCOMPLETE_MESSAGE error. This causes further reading of data from the server → an error and connection break. I managed to fix it by adding validation of the first bytes of the buffer to match the TLS header. -- v3: secur32: Return SEC_E_INVALID_TOKEN for invalid TLS record headers https://gitlab.winehq.org/wine/wine/-/merge_requests/10916

3 3

[PATCH v3 0/2] MR11017: msi: Catch all exceptions in the custom DLL procedure.
by Dmitry Timoshkov (＠dmitry) June 1, 2026

June 1, 2026

-- v3: msi: Return ERROR_INSTALL_FAILURE on an exception in the custom action. msi: Catch all exceptions in the custom DLL procedure. https://gitlab.winehq.org/wine/wine/-/merge_requests/11017

3 3

Re: [PATCH v4 0/4] MR10960: scrrun/dictionary: Match native semantics for Empty and Boolean keys.
by Francis De Brabandere (＠francisdb) June 1, 2026

June 1, 2026

@nsivov Looks like I just hit the BOOL type key case breaking a Visual Pinball table script: ```vbscript If m_force_different = True Then If valid_events.Exists(GetPlayerState("random_" & m_mode & "_" & m_key & "_last")) Then valid_events.Remove GetPlayerState("random_" & m_mode & "_" & m_key & "_last") End If End If ``` The key argument is whatever GetPlayerState("random_..._last") returns — in the state we hit, that's a Boolean (VT_BOOL), which is the key type wine's scrrun hash function doesn't handle, hence the E_NOTIMPL. Adding this to the MR -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10960#note_141823

1 0

[PATCH 0/1] MR11036: Add .DS_Store file to gitignore
by tobbi (＠tobbi) June 1, 2026

June 1, 2026

The .DS_Store file is a file that gets used by MacOS's finder application for storing internal configuration data. There's no reason for that file to be part of the git tree. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11036

3 3

[PATCH v2 0/2] MR10535: mfreadwrite: Rescale video frames based on aspect ratio when processing is enabled.
by Yuxuan Shui (＠yshui) June 1, 2026

June 1, 2026

-- v2: mfreadwrite: Ensure output has a 1:1 pixel aspect ratio if processing is enabled. mfreadwrite: Don't modify the `type` parameter in src_reader_SetCurrentMediaType. https://gitlab.winehq.org/wine/wine/-/merge_requests/10535

3 5

[PATCH 0/2] MR10997: winegstreamer: Video processor shouldn't have a preferred size.
by Yuxuan Shui (＠yshui) June 1, 2026

June 1, 2026

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

3 4

[PATCH v2 0/3] MR10935: winemac: Add cross-process MetalViewSwapChain.
by Marc-Aurel Zent (＠mzent) June 1, 2026

June 1, 2026

-- v2: winemac: Implement cross-process MetalViewSwapChain via CALayerHost. winemac: Factor out Metal device and view logic into MetalViewSwapChain. https://gitlab.winehq.org/wine/wine/-/merge_requests/10935

4 9

Re: [PATCH v3 0/1] MR9796: winebus: Adjust hatswitch encoding to follow T300RS and G29 - closed
by SeongChan Lee (＠foriequal0) June 1, 2026

June 1, 2026

This merge request was closed by SeongChan Lee. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9796

1 0

Re: [PATCH 0/4] MR11035: gdi32/uniscribe: Eagerly cache cmap tables for a font.
by समीरसिंह Sameer Singh (＠ss141309) June 1, 2026

June 1, 2026

I should probably explain my changes here. The game Sail Simulator 5 was crashing due to usp10 because it relied on a Windows behaviour where the OS will cache all of the glyphs of the font in the ScriptCache when a valid hdc is present, so the next time when the shaping function is called with a null hdc, the os can then look at the ScriptCache for the glyph to see if it exists. Prior to this patch wine did not do that, it only stored the glyphs in the cache which were encountered in previous shaping runs. So what I did was add a cmap format 4 table (the cmap table which is used for the BMP plane of unicode) to the ScriptCache and then eagerly load the tables when ScriptShapeOpenType is called. So when the shaping function is called again with an invalid hdc, instead of immediately returning `E_PENDING` check for the glyph in the cmap table first. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11035#note_141803

1 0

[PATCH v5 0/3] MR10567: wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB...
by Stian Low (＠stianlow) June 1, 2026

June 1, 2026

wined3d: fix vk swapchain rendering too dark by supporting UNORM to SRGB conversion for brightness similar to gl This merge request addresses: https://bugs.winehq.org/show_bug.cgi?id=45364 Frostpunk is very dark Very dark rendering issues for Frostpunk seem to match the same problem for Vulkan renderer for "Against the Storm": - https://bugs.winehq.org/show_bug.cgi?id=58632 - https://bugs.winehq.org/attachment.cgi?id=80656 Running both games with gl renderer seems to fix excessive darkness: - https://bugs.winehq.org/attachment.cgi?id=80654 - https://bugs.winehq.org/attachment.cgi?id=80690 Vulkan renderer seems to be missing SRGB conversion handling availiable for GL renderer. GL renderer can be forced to render darker the same as Vulkan by bypassing EXT_TEXTURE_SRGB support for ./dlls/wined3d/utils.c: ``` @@ -3133,7 +3146,7 @@ static BOOL init_format_texture_info(struct wined3d_adapter *adapter, struct win continue; copy_format(adapter, &srgb_format->f, &format->f); +#if 000 if (gl_info->supported[EXT_TEXTURE_SRGB] && !(adapter->d3d_info.wined3d_creation_flags & WINED3D_SRGB_READ_WRITE_CONTROL)) { @@ -3142,6 +3155,7 @@ static BOOL init_format_texture_info(struct wined3d_adapter *adapter, struct win format_set_caps(&srgb_format->f, WINED3D_FORMAT_CAP_SRGB_READ | WINED3D_FORMAT_CAP_SRGB_WRITE); query_internal_format(adapter, srgb_format, &format_texture_info[i], gl_info, TRUE); } +#endif } ``` This merge request patch allows Vulkan renderer to perform SRGB conversion for wined3d_swapchain_vk_select_vk_format() to mimic the GL capability. Changing VkSwapchainCreateInfoKHR imageColorSpace from VK_COLOR_SPACE_SRGB_NONLINEAR_KHR for `wined3d_swapchain_vk_create_vulkan_swapchain()` had no effect despite enabling VK_EXT_swapchain_colorspace for dlls/win32u/vulkan.c `convert_instance_create_info():` https://docs.vulkan.org/refpages/latest/refpages/source/VkColorSpaceKHR.html Therefore converting UNORM to SRGB was chosen similar to how the GL renderer seems to handle it: ``` static const struct wined3d_format_srgb_info format_srgb_info[] = { {WINED3DFMT_R8G8B8A8_UNORM_SRGB, WINED3DFMT_R8G8B8A8_UNORM}, {WINED3DFMT_BC1_UNORM_SRGB, WINED3DFMT_BC1_UNORM}, {WINED3DFMT_BC2_UNORM_SRGB, WINED3DFMT_BC2_UNORM}, {WINED3DFMT_BC3_UNORM_SRGB, WINED3DFMT_BC3_UNORM}, {WINED3DFMT_B8G8R8A8_UNORM_SRGB, WINED3DFMT_B8G8R8A8_UNORM}, {WINED3DFMT_B8G8R8X8_UNORM_SRGB, WINED3DFMT_B8G8R8X8_UNORM}, {WINED3DFMT_BC7_UNORM_SRGB, WINED3DFMT_BC7_UNORM}, }; ``` Its unclear whether SRGB conversion should always happen or only for particular games so the patch leaves the Vulkan renderer without SRGB conversion by default. Therefore the patch adds a new WINE_D3D_CONFIG flag named "vk_swap_srgb" to force the Vulkan renderer to perform SRGB conversion for the swapchain. By default vk_swap_srgb is set to FALSE or 0: `WINE_D3D_CONFIG=vk_swap_srgb=0,renderer=vulkan` To force vk_swap_srgb to TRUE or 1: `WINE_D3D_CONFIG=vk_swap_srgb=1,renderer=vulkan` For example, launching Frostpunk via the following after the patch fixes the dark rendering for Vulkan and appears brighter similar to the GL renderer: `WINEDEBUG=-all mangohud --dlsym WINE_D3D_CONFIG=csmt=0x1,renderer=vulkan,vk_swap_srgb=1 WINEPREFIX=/home/any/wine_stianlow_wow64_new_pfx ~/tmp/wine_stianlow_wow64_new_install/bin/wine /home/any/wine_stianlow_wow64_new_pfx/drive_c/GOG\ Games/Frostpunk/Frostpunk.exe` Some SRGB handling was added several years ago but not for mapping UNORM to SRGB that this patch adds: ``` 6f55c8d1c56 * wined3d: Use an sRGB fallback format for sRGB formats in wined3d_swapchain_vk_select_vk_format(). Author: Henri Verbeet <hverbeet(a)codeweavers.com> CommitDate: Wed Dec 9 16:29:28 2020 +0100 ``` If UNORM to SRGB should be enabled by default then this patch may be changed so that vk_swap_srgb defaults to TRUE. -- v5: wined3d: fix vk swapchain rendering too dark by supporting rtvs for swapchain back_buffers > 1 wined3d: revert fix vk swapchain rendering too dark by supporting UNORM to SRGB conversion for brightness similar to gl https://gitlab.winehq.org/wine/wine/-/merge_requests/10567

4 14

[PATCH v4 0/3] MR10844: gdi32/uniscribe: Perform bounds check in GSUB_apply_MultipleSubst().
by समीरसिंह Sameer Singh (＠ss141309) June 1, 2026

June 1, 2026

Check if the current number of glyphs exceed the maximum limit and then return an E_OUTOFMEMORY. Modify the functions to bubble this error so that it can be dealt with. -- v4: gdi32/uniscribe: Propagate GSUB_E_OUTOFMEMORY error. gdi32/uniscribe: Return GSUB_E_OUTOFMEMORY on lookup buffer overflow. gdi32/uniscribe: Pass maximum glyph count to GSUB lookup functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/10844

2 4