- Wine-gitlab - list.winehq.org

[PATCH v5 0/13] MR9489: Draft: mf: Fix seeking within sample grabber.
by Brendan McGrath (＠redmcg) 01 Dec '25

01 Dec '25

This fixes seeking within sample grabber by matching Windows functionality. -- v5: mf: Request new sample before processing markers. mf: Remove no longer used sample_count and samples array. mf: Ensure we always have four requests outstanding/satisfied. mf: Always queue a sample unless stopped. mf: Keep count of samples queued. mf: Make flushing on sample grabber largely a no-op. mf/tests: Test sample grabber pause and resume. mf/tests: Check contents of sample collection. mf/tests: Test seek with sample grabber whilst ignoring clock. mf/tests: Test samplegrabber flush then seek. mf/tests: Check StreamSinkMarker event. mf/tests: Test sample grabber {Set,Cancel}Timer. mf/tests: Add test for sample grabber seek. https://gitlab.winehq.org/wine/wine/-/merge_requests/9489

2 13

[PATCH v2 0/2] MR9631: dlls/wmp: Implement the OLEIVERB_SHOW needed by the software Alldup
by pan hui (＠panhui) 01 Dec '25

01 Dec '25

The software "Alldup" uses OLEIVERB_SHOW, but OLEIVERB_SHOW is not implemented in oleobj.c, resulting in errors when running the Alldup via Wine. -- v2: sign by:panhui(a)uniontech.com https://gitlab.winehq.org/wine/wine/-/merge_requests/9631

2 2

[PATCH 0/1] MR9631: dlls/wmp: Implement the OLEIVERB_SHOW needed by the software Alldup
by pan hui (＠panhui) 01 Dec '25

01 Dec '25

The software "Alldup" uses OLEIVERB_SHOW, but OLEIVERB_SHOW is not implemented in oleobj.c, resulting in errors when running the Alldup via Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9631

2 1

[PATCH 0/1] MR9630: user32: Avoid compiler warnings in tests
by Gerald Pfeifer (＠gerald) 30 Nov '25

30 Nov '25

This avoids two compiler warnings with current versions of GCC 16 (which look like false positives, alas hard to avoid): dlls/user32/tests/win.c:13943:45: warning: "width" may be used uninitialized dlls/user32/tests/win.c:13943:73: warning: "height" may be used uninitialized -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9630

2 1

[PATCH v6 0/4] MR8505: mfsrcsnk: Implement thinning.
by Charlotte Pabst (＠CharlottePabst) 30 Nov '25

30 Nov '25

Follow-up to !8184. This also adds a bunch of helpers for writing media source tests (without involving the mf session) in mfsrcsnk, these could be helpful for more tests of this kind in the future. I'm somewhat unsure as to why we haven't done tests for source behavior so far: while those are plugins, applications rely on a bunch of things in the builtin sources that microsoft provides. Since this affects both mfsrcsnk and winegstreamer sources, tests should be run both with `HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler` enabled and disabled. Due to this I figured it'd make sense to implement everything first and then remove the test todo_wine's and the statements rejecting the thin parameter in a single commit ("Allow thinning"). Perhaps this could be solved more nicely by setting the registry key in the tests themselves? I'm unsure if that is something we do in tests, generally. `MEStreamThinMode` events need to be emitted between the last sample using the outdated thinning parameter and the first sample using the updated thinning parameter. The winegstreamer implementation for this turned out a bit complex, if there is a simpler way to do this please let me know. Regarding winegstreamer, note that buffers need to be intercepted before the decoder because decoders often discard `GST_BUFFER_FLAG_DELTA_UNIT` flags (which is already annoying in itself - it causes all samples to be marked as `MFSampleExtension_CleanPoint`, this should potentially be worked around in the future). But even besides that, intercepting before the decoder is the "proper" implementation, since the point of thinning is increasing decoding speed by skipping delta frames, tho there are some games that rely on the semantics as well. -- v6: mfsrcsnk: Implement thinning. mfsrcsnk: Process SetRate asynchronously. winedmo: Fall back to dts for sample time if pts is not present. mfsrcsnk/tests: Add tests for thinning. https://gitlab.winehq.org/wine/wine/-/merge_requests/8505

2 4

[PATCH v2 0/2] MR9628: user32: Implement pointer input APIs for multi-touch support
by Hecheng Yu (＠kde-yyds) 30 Nov '25

30 Nov '25

This patch implements core pointer input APIs required by modern applications with touchscreen support, particularly Chromium and Qt-based applications. Implemented APIs: - GetPointerType: Query pointer input type (touch, pen, mouse) - GetPointerTouchInfo: Retrieve detailed touch pointer information - GetPointerFrameTouchInfo: Get all active touch pointers in current frame Added stubs: - SkipPointerFrameMessages: Used by applications to skip pointer frame processing like Qt - GetPointerFrameTouchInfoHistory: Historical touch frame data (not yet implemented) - GetPointerPenInfoHistory: Historical pen data (not yet implemented) System metrics changes: - SM_DIGITIZER: Reports touch capabilities (NID_INTEGRATED_TOUCH | NID_MULTI_INPUT | NID_READY) - SM_MAXIMUMTOUCHES: Returns maximum simultaneous touch points (10) Limitations: - We explictly set pointer type to PT_TOUCH when storing pointer info to queue, so GetPointerType will always return PT_TOUCH - GetPointerFrameTouchInfo returns 0 pointers after finger lift, while Windows returns 1 pointer with UP flags. And SkipPointerFrameMessages is currently a stub returning TRUE. Qt's pointer message processing uses both of them, but it's just working well Application requirements: - Chromium: Requires GetPointerType and GetPointerTouchInfo for touch input - Qt applications: Need GetPointerFrameTouchInfo and proper system metrics for multi-touch support - Qt5: Additionally checks for presence of all pointer APIs at runtime, requiring stubs to enable pointer messages processing -- v2: GetPointerType: Always return PT_MOUSE for id 1 https://gitlab.winehq.org/wine/wine/-/merge_requests/9628

2 2

[PATCH 0/1] MR9628: user32: Implement pointer input APIs for multi-touch support
by Hecheng Yu (＠kde-yyds) 30 Nov '25

30 Nov '25

This patch implements core pointer input APIs required by modern applications with touchscreen support, particularly Chromium and Qt-based applications. Implemented APIs: - GetPointerType: Query pointer input type (touch, pen, mouse) - GetPointerTouchInfo: Retrieve detailed touch pointer information - GetPointerFrameTouchInfo: Get all active touch pointers in current frame Added stubs: - SkipPointerFrameMessages: Used by applications to skip pointer frame processing like Qt - GetPointerFrameTouchInfoHistory: Historical touch frame data (not yet implemented) - GetPointerPenInfoHistory: Historical pen data (not yet implemented) System metrics changes: - SM_DIGITIZER: Reports touch capabilities (NID_INTEGRATED_TOUCH | NID_MULTI_INPUT | NID_READY) - SM_MAXIMUMTOUCHES: Returns maximum simultaneous touch points (10) Limitations: - We explictly set pointer type to PT_TOUCH when storing pointer info to queue, so GetPointerType will always return PT_TOUCH - GetPointerFrameTouchInfo returns 0 pointers after finger lift, while Windows returns 1 pointer with UP flags. And SkipPointerFrameMessages is currently a stub returning TRUE. Qt's pointer message processing uses both of them, but it's just working well Application requirements: - Chromium: Requires GetPointerType and GetPointerTouchInfo for touch input - Qt applications: Need GetPointerFrameTouchInfo and proper system metrics for multi-touch support - Qt5: Additionally checks for presence of all pointer APIs at runtime, requiring stubs to enable pointer messages processing -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9628

2 1

[PATCH 0/1] MR9619: Revert "winex11: Use the default color table for window surfaces on 8bpp displays."
by Alex Henrie (＠alexhenrie) 30 Nov '25

30 Nov '25

This reverts commit 458e0ad5133c9a449e22688a89183f3a6ab286e4. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57584 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9619

2 2

[PATCH v2 0/2] MR9624: qcap: supports capturing camera footage in yuy2 format
by 张顾在 30 Nov '25

30 Nov '25

the yuv2 format video stream captured from v4l requires conversion to RGB24 format for rendering.I have verified that FFmpeg-8.0.1-essentials_build supports YUV capture format under Wine.The attachment contains format support obtained using ffmpeg.exe, along with video capture data processed via yuy2. [ffmpeg_support.log](/uploads/6bbdfa9249ef1cfae3edfa4e11663538/ffmpeg_support.log) [test_yuyv422.avi](/uploads/b2b0fb25fedad17bf60cf5aedaa6c5bf/test_yuyv422.avi) -- v2: quartz: Supports yuy2 video stream rendering qcap: supports capturing camera footage in yuy2 format https://gitlab.winehq.org/wine/wine/-/merge_requests/9624

2 3

[PATCH 0/1] MR9627: po: Update Dutch translation
by Floris Renaud (＠jkfloris) 29 Nov '25

29 Nov '25

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

2 1