- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR10777: msxml3: Create structured representation for element declarations.
by Nikolay Sivov (＠nsivov) April 29, 2026

April 29, 2026

Such representation is easy to shared with DOM for validation purposes, so that we don't have to parse it multiple times. Public API is using serialized representation. The parsing and serializing logic comes entirely from libxml2. Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10777

2 1

[PATCH v9 0/2] MR9567: winegstreamer: Refactor WMSyncReader to use DMOs internally.
by Yuxuan Shui (＠yshui) April 29, 2026

April 29, 2026

-- v9: winegstreamer: Refactor WMSyncReader to use DMOs internally. winegstreamer: Fix leakage of media type in IWMOutputMediaProps. https://gitlab.winehq.org/wine/wine/-/merge_requests/9567

5 9

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 29, 2026

April 29, 2026

On Wed Apr 29 14:31:49 2026 +0000, Rémi Bernon wrote: > Yes, I don't think we need to worry about reading raw samples out of > media sources / any other demuxer, unless it actually fixes some > application (which, like I said, I doubt it will ever). Also, your test > above seem to indicate that there's nothing to be done, which is > expected, as demuxer job is to hand over packets exactly as they are stored. OK, I'll wait for Zeb to respond. On the other hand, can you give my wmsyncreader MR !9567 some feedback then? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138210

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Rémi Bernon (＠rbernon) April 29, 2026

April 29, 2026

On Wed Apr 29 14:27:31 2026 +0000, Yuxuan Shui wrote: > yeah i think @zfigura agreed that we should be using a pipeline that > resembles what Windows does, which would automatically give me all the > alignment fixes and i don't need to do anything. IIUC we are mostly done > on that front if we move to winedmo? except maybe `WMSyncReader` which > is my other MR. > IIUC Zeb's argument was even after we are done with this transition, an > mf media source can still produce raw video samples and therefore still > need to worry about alignment. that's what this MR is trying to fix, > this wasn't trying to fix the behavior when wg_parser is also used for > decoding. i agree with you that would be pointless as we are already > moving away from that. > unless you are saying because reading raw video from media sources are > not really used in practice so we don't need to worry about that? Yes, I don't think we need to worry about reading raw samples out of media sources / any other demuxer, unless it actually fixes some application (which, like I said, I doubt it will ever). Also, your test above seem to indicate that there's nothing to be done, which is expected, as demuxer job is to hand over packets exactly as they are stored. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138209

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 29, 2026

April 29, 2026

On Wed Apr 29 14:07:00 2026 +0000, Rémi Bernon wrote: > IMO we shouldn't bother about raw video directly in containers, it's > uncommon and unlikely to be ever encountered in practice: it's just > completely inefficient to store raw video frames in a file and except > for debugging and testing purposes I have never seen it done. In > addition, it's not what the games are doing and therefore changing the > way it's done is not going to fix their broken expectations. > The broken applications are broken because expect an actual decoding / > conversion pipeline to be there, and their expectations are coming from > the decoder / converter behaviors, which are the components that may add > extra buffer alignment for performance reasons. We should fix our > decoder / converters if they don't align buffers properly, but I believe > they now mostly do, and we should then make sure we use them in actual > pipelines as well. Anything else is pointless. yeah i think @zfigura agreed that we should be using a pipeline that resembles what Windows does, which would automatically give me all the alignment fixes and i don't need to do anything. IIUC we are mostly done on that front if we move to winedmo? except maybe `WMSyncReader` which is my other MR. IIUC Zeb's argument was even after we are done with this transition, an mf media source can still produce raw video samples and therefore still need to worry about alignment. that's what this MR is trying to fix, this wasn't trying to fix the behavior when wg_parser is also used for decoding. i agree with you that would be pointless as we are already moving away from that. unless you are saying because reading raw video from media sources are not really used in practice so we don't need to worry about that? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138208

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Rémi Bernon (＠rbernon) April 29, 2026

April 29, 2026

On Wed Apr 29 14:01:09 2026 +0000, Yuxuan Shui wrote: > can we maybe conclude odd width video is bugged on Windows? IMO we shouldn't bother about raw video directly in containers, it's uncommon and unlikely to be ever encountered in practice: it's just completely inefficient to store raw video frames in a file and except for debugging and testing purposes I have never seen it done. In addition, it's not what the games are doing and therefore changing the way it's done is not going to fix their broken expectations. The broken applications are broken because expect an actual decoding / conversion pipeline to be there, and their expectations are coming from the decoder / converter behaviors, which are the components that may add extra buffer alignment for performance reasons. We should fix our decoder / converters if they don't align buffers properly, but I believe they now mostly do, and we should then make sure we use them in actual pipelines as well. Anything else is pointless. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138199

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 29, 2026

April 29, 2026

On Wed Apr 29 13:59:58 2026 +0000, Yuxuan Shui wrote: > OK I tried rawvideo in avi container. and additionally i think I must > avoid doing pixel format conversion to avoid involving mf transforms? > after doing that, i noticed that the `IMF2DBuffer` interface was gone > from the samples. so likely that was mf transforms related. > now what I saw was quite odd, my input video is i420 161x120, the output > i got is somehow 160x121. huh? > the output buffer size is 29040, which is `160x121 * 3/2`. but > `MF_MT_FRAME_SIZE` still reports 161x120. > (not sure if this information is relevant, but i also tried using a raw > rgb32 video with pixel format conversion to yuv, which i believe would > be using transforms. this time I got buffer size 29160, which is > `162x120 * 3/2`, which is exactly what's expected. and `IMF2DBuffer` > interface again becomes available.) can we maybe conclude odd width video is bugged on Windows? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138198

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 29, 2026

April 29, 2026

On Mon Apr 20 21:30:57 2026 +0000, Yuxuan Shui wrote: > Oh right, I am dumb. I was only thinking about wine and forgot h264 > would also be going through IMFTransform on Windows. I'll do what you suggested. OK I tried rawvideo in avi container. and additionally i think I must avoid doing pixel format conversion to avoid involving mf transforms? after doing that, i noticed that the `IMF2DBuffer` interface was gone from the samples. so likely that was mf transforms related. now what I saw was quite odd, my input video is i420 161x120, the output i got is somehow 160x121. huh? the output buffer size is 29040, which is `160x121 * 3/2`. but `MF_MT_FRAME_SIZE` still reports 161x120. (not sure if this information is relevant, but i also tried using a raw rgb32 video with pixel format conversion to yuv, which i believe would be using transforms. this time I got buffer size 29160, which is `162x120 * 3/2`, which is exactly what's expected. and `IMF2DBuffer` interface again becomes available.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138197

1 0

[PATCH v5 0/1] MR10725: win32u: Set the normal window position without going through NtUserSetInternalWindowPos().
by Zhiyi Zhang (＠zhiyi) April 29, 2026

April 29, 2026

Fix a regression from be60f779, the intent of which was to restore the win32 window position to the current host window position. However, NtUserSetInternalWindowPos() eventually calls NtUserSetWindowPos() and NtUserShowWindow(). We don't want that because they might generate window position change messages that applications might not expect. Fix Homeworld Remastered Collection (244160) Homeworld 2 Classic black screen after restoring from the minimized state in fullscreen mode due to an unexpected window size. -- v5: win32u: Set the normal window position without going through NtUserSetInternalWindowPos(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10725

3 3

[PATCH v6 0/2] MR10340: comctl32/tooltips: suppress icon and title when title is NULL or empty.
by Larry Starr (＠starrl) April 29, 2026

April 29, 2026

Per MSDN, TTM_SETTITLE with a NULL or empty title string should suppress both the title row and any associated icon. Previously an empty string was treated the same as a non-empty title, causing the icon to still be displayed and the tooltip to be incorrectly sized. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58236 Signed-off-by: Larry Starr <Larry_A_Starr(a)yahoo.com> -- v6: comctl32/tooltips: suppress icon and title when title is NULL or empty. comctl32/tooltips/tests: add regression test for TTM_SETTITLE with NULL or empty title. https://gitlab.winehq.org/wine/wine/-/merge_requests/10340

3 5

[PATCH 0/1] MR10676: gdi32/uniscribe: Correct the script tag for Tamil.
by समीरसिंह Sameer Singh (＠ss141309) April 29, 2026

April 29, 2026

The script tag for the Tamil script is 'tml2' and not 'tam2'. The fix turned out to be easier than expected. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10676

4 4

[PATCH v5 0/2] MR10612: gdi32/uniscribe: Fix heap buffer overflow in ScriptStringAnalyse().
by समीरसिंह Sameer Singh (＠ss141309) April 29, 2026

April 29, 2026

Hi, I came across this bug while solving another issue. Steps to reproduce: 1. Open wine notepad 2. Start spamming any character that requires mark_invalid_combinations() in the notepad, such as: َ (0x064e Arabic Fatha) 3. At nearly 41 inserted Fatha, notepad will crash -- v5: gdi32/uniscribe: Resize the buffers if glyph count exceeds limit. gdi32/uniscribe: Perform bounds check in insert_glyph(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10612

4 4

[PATCH 0/1] MR10439: crypt32: Protect certificate context from repeated releases.
by Dmitry Timoshkov (＠dmitry) April 29, 2026

April 29, 2026

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

3 16

[PATCH v2 0/4] MR10775: vbscript: Fix and expand test coverage for BSTR comparison. (alternate)
by Francis De Brabandere (＠francisdb) April 29, 2026

April 29, 2026

Alternate version of !10766 This replaces runtime VT_RESERVED tracking with compile-time is_literal_expr at the AST level: comparison opcodes (equal/nequal/gt/gteq/lt/lteq/case) carry a flag arg with bit 0 = left-literal, bit 1 = right-literal, and var_cmp dispatches on those flags. No runtime stripping, no OP_strip_reserved, and Const references stay non-literal because they're EXPR_MEMBER nodes even though the value is inlined. -- v2: vbscript: Match Windows BSTR-vs-numeric and BSTR-vs-Boolean comparison. https://gitlab.winehq.org/wine/wine/-/merge_requests/10775

2 4

[PATCH 0/5] MR10776: dinput: Add proper support for DIPROP_JOYSTICKID and GUID_Joystick.
by Rémi Bernon (＠rbernon) April 29, 2026

April 29, 2026

Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/10755 with some style fixes and simplified joystick ID allocation, moved to a dedicated function. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10776

3 5

[PATCH 0/4] MR10775: vbscript: Fix and expand test coverage for BSTR comparison. (alternate)
by Francis De Brabandere (＠francisdb) April 29, 2026

April 29, 2026

Alternate version of !10766 This replaces runtime VT_RESERVED tracking with compile-time is_literal_expr at the AST level: comparison opcodes (equal/nequal/gt/gteq/lt/lteq/case) carry a flag arg with bit 0 = left-literal, bit 1 = right-literal, and var_cmp dispatches on those flags. No runtime stripping, no OP_strip_reserved, and Const references stay non-literal because they're EXPR_MEMBER nodes even though the value is inlined. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10775

2 5

[PATCH 0/23] MR10687: Draft: colorcnv, msvproc, resampledmo: Import and use libswresample and libswscale.
by Rémi Bernon (＠rbernon) April 29, 2026

April 29, 2026

This is an attempt at importing some of FFmpeg code as a PE library, in order to use it to implement audio and video conversion. It removes the need to have the corresponding components available through Gstreamer on the unix side, improves compatibility, as well as performance by a large amount. This is the case in particular for video format conversion. Note that for now it will only benefit pipelines that use these components on the PE side, which is not the majority of use cases right now because we are still doing more than we should on the Gstreamer. I think the idea could perhaps later be extended to cover demuxers (although that could be a bit controversial, but I believe most Linux distributions are distributing them without concerns now), leaving only decoder components to be possibly delegated to the unix side to avoid going into dangerous waters. ``` Measured conversion times for a 4K video frame, average over 1000 calls: (gstreamer) (ffmpeg) I420 -> NV12 2d:0 flip:0 0.232932ms -> 0.122778ms (1.90x) I420 -> NV12 2d:1 flip:0 0.212732ms -> 0.153243ms (1.39x) I420 -> RGB565 2d:0 flip:0 0.415617ms -> 0.153634ms (2.71x) I420 -> RGB24 2d:0 flip:0 0.652448ms -> 0.147694ms (4.42x) I420 -> RGB32 2d:0 flip:0 0.468539ms -> 0.144602ms (3.24x) I420 -> RGB32 2d:0 flip:1 0.442714ms -> 0.176187ms (2.51x) I420 -> RGB32 2d:1 flip:0 0.432901ms -> 0.205248ms (2.11x) I420 -> RGB32 2d:1 flip:1 0.434456ms -> 0.164153ms (2.65x) I420 -> ARGB32 2d:0 flip:0 0.484792ms -> 0.166264ms (2.92x) NV12 -> I420 2d:0 flip:0 0.237323ms -> 0.070567ms (3.36x) NV12 -> I420 2d:1 flip:0 0.233147ms -> 0.085753ms (2.72x) NV12 -> RGB565 2d:0 flip:0 1.073673ms -> 0.628600ms (1.71x) NV12 -> RGB24 2d:0 flip:0 1.310258ms -> 0.737381ms (1.78x) NV12 -> RGB32 2d:0 flip:0 1.365511ms -> 0.810218ms (1.69x) NV12 -> RGB32 2d:0 flip:1 1.213529ms -> 0.832048ms (1.46x) NV12 -> RGB32 2d:1 flip:0 1.185173ms -> 0.821544ms (1.44x) NV12 -> RGB32 2d:1 flip:1 1.051457ms -> 0.837046ms (1.26x) NV12 -> ARGB32 2d:0 flip:0 1.111438ms -> 0.814145ms (1.37x) ``` -- This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/10687

3 5

[PATCH 0/2] MR10773: windows.media.speech: Don't access the all voices vector view directly.
by Bernhard Kölbl (＠besentv) April 29, 2026

April 29, 2026

The vector view might be uninitialized by the time ISpeechSynthesizer_put_Voice is called, so get it via the "official" way through IInstalledVoicesStatic. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59694 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10773

2 2

[PATCH v4 0/4] MR10680: scrrun: Implement IFile and IFolder Delete and Move methods.
by Francis De Brabandere (＠francisdb) April 29, 2026

April 29, 2026

file_Delete wraps DeleteFileW, honouring the Force flag by clearing readonly attributes. folder_Delete recursively removes contents via the existing delete_file/delete_folder helpers, then RemoveDirectoryW. Both Move methods wrap MoveFileW. -- v4: scrrun: Implement IFolder::Move. scrrun: Implement IFile::Move. scrrun: Implement IFolder::Delete. scrrun: Implement IFile::Delete. https://gitlab.winehq.org/wine/wine/-/merge_requests/10680

2 4

[PATCH v7 0/1] MR10343: vbscript: Resolve parser conflicts with %prec and %expect.
by Francis De Brabandere (＠francisdb) April 29, 2026

April 29, 2026

Use %prec LOWER_THAN_ELSE on the empty EndIf_opt rule to explicitly resolve 4 dangling Else / End If shift/reduce conflicts. The remaining 6 conflicts are benign colon-chain ambiguities documented with %expect 6. -- v7: vbscript: Resolve parser conflicts with %prec and %expect. https://gitlab.winehq.org/wine/wine/-/merge_requests/10343

2 1

[PATCH 0/2] MR8414: Fix EV Nova game text truncation.
by Zhiyi Zhang (＠zhiyi) April 29, 2026

April 29, 2026

Fix the rectangle from DrawText(..., DT_CALCRECT) with a selected font might not be enough to actually draw text with the font for the EV Nova game. This ensures that text extent calculated with a font selected in a device context is enough when drawing texts using the same font and device context. The root cause is that FreeType might report different font metrics for different GGO formats. GetTextExtentExPoint() gets text extent with GGO_METRICS. And GGO_METRICS gets font metrics from glyphs loaded with FT_LOAD_TARGET_NORMAL, so when drawing bitmap fonts, which is of GGO_BITMAP format loaded with FT_LOAD_TARGET_MONO, with the calculated text extent, the result text might get truncated because of the font metrics difference. On Windows, anti-aliased font and bitmap font of the same face font reports the same font metrics so such a problem doesn't happen. The ultimate fix is to let FreeType hint the bitmap fonts with the same font metrics as anti-aliased fonts but there are no settings that can achieve it unless we write a new FreeType hinter. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57309 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8414

4 9

[PATCH v2 0/1] MR10594: Draft: vbscript: Log call stack trace on runtime errors.
by Francis De Brabandere (＠francisdb) April 29, 2026

April 29, 2026

Add WARN-level trace output showing the call chain when a runtime error propagates through nested function calls. This helps diagnose errors in ExecuteGlobal/Execute code where the reported error location has no context about which call chain led to it. ``` Example output for WINEDEBUG=warn+vbscript: error 0x80020012 in L"Broken", line 3 called from L"Wrapper", line 2 called from <global>, line 16 ``` -- v2: vbscript: Log call stack trace on runtime errors. https://gitlab.winehq.org/wine/wine/-/merge_requests/10594

2 1

[PATCH v20 0/1] MR10461: vbscript: Implement IDispatch::GetTypeInfo for class instances.
by Francis De Brabandere (＠francisdb) April 29, 2026

April 29, 2026

Implement GetTypeInfo on vbdisp_t (VBScript class instances) by returning an ITypeInfo that reports the class name via GetDocumentation(MEMBERID_NIL) and exposes public methods and properties via GetFuncDesc, GetVarDesc, GetNames, GetIDsOfNames, and GetTypeAttr. This makes TypeName() return the actual class name (e.g. "MyClass") instead of falling back to "Object". This is partially based on previous work by @jsm174 at https://github.com/jsm174/libwinevbs/blob/fbc4d2a17a2da8196d50805f7ae289406… -- v20: vbscript: Implement IDispatch::GetTypeInfo for class instances. https://gitlab.winehq.org/wine/wine/-/merge_requests/10461

2 1

[PATCH v5 0/1] MR10736: gdiplus: Don't add X margin to Center/Far for GdipMeasureCharacterRanges
by Bartosz Kosiorek (＠gang65) April 29, 2026

April 29, 2026

We should shift X position only for StringAlignmentNear. -- v5: gdiplus: Don't add X margin on Center/Far for GdipMeasureCharacterRanges and GdipDrawString https://gitlab.winehq.org/wine/wine/-/merge_requests/10736

4 10

Re: [PATCH v18 0/3] MR10603: win32u/freetype: Fix tmExternalLeading for CFF fonts.
by Arie Miller (＠Arimil) April 29, 2026

April 29, 2026

@huw are you able to take a look at this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10603#note_138124

1 0