- Wine-GitLab - list.winehq.org

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

Dec. 1, 2025

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) Nov. 30, 2025

Nov. 30, 2025

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) Nov. 30, 2025

Nov. 30, 2025

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) Nov. 30, 2025

Nov. 30, 2025

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) Nov. 30, 2025

Nov. 30, 2025

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) Nov. 30, 2025

Nov. 30, 2025

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 张顾在 Nov. 30, 2025

Nov. 30, 2025

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) Nov. 29, 2025

Nov. 29, 2025

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

2 1

Re: [PATCH v4 0/2] MR9584: win32u: Update client surfaces starting from toplevel window.
by darkblaze (＠darkblaze69) Nov. 29, 2025

Nov. 29, 2025

@rbernon there's a regression in wayland with this one: https://bugs.winehq.org/show_bug.cgi?id=59061 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9584#note_124242

1 0

[PATCH v3 0/2] MR9555: Fix ICAP_BITDEPTH semantics, allow setting it
by Bernd Herd (＠herdsoft) Nov. 29, 2025

Nov. 29, 2025

In Twain the capability ICAP_BITDEPTH defines the number of bits to transfer per pixel during a scan. So for an RGB image with 8 bit per color channel, ICAP_BITDEPTH is 24. In Sane the depth is defined as the number of bits per color channel, so for an RGB image with 8 bit per color channel, depth is 8. See Page 10-132 (PDF Page 550) if the Twain 2.5 Spec. Obviously older spec versions where not as exact, so there were misunderstandings. The existing code to handle ICAP_BITDEPTH did not consider this difference and returned the sane depth value. This merge request fixes this and adds the ability to set the depth to 16 bit per color channel for those sane backends that support the "depth" option. -- v3: dlls/sane.ds: Refuse native transfer mode with depth 16 bit dlls/sane.ds: Fix ICAP_BITDEPTH semantics, allow setting it https://gitlab.winehq.org/wine/wine/-/merge_requests/9555

3 3