November 2025 - Wine-GitLab

[PATCH v7 0/4] MR8505: mfsrcsnk: Implement thinning.
by Charlotte Pabst (＠CharlottePabst) Dec. 2, 2025

Dec. 2, 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. -- v7: mfsrcsnk: Implement thinning. https://gitlab.winehq.org/wine/wine/-/merge_requests/8505

3 6

[PATCH v2 0/3] MR9454: Revert "winmm: Use AUTOCONVERTPCM when initializing the audio client."
by Giovanni Mascellani (＠giomasce) Dec. 2, 2025

Dec. 2, 2025

This reverts commit 21fb3555ed1f26e46d4c82cb2ec8fc29f730a0e9, which inadvertently removed support for converting audio formats not directly supported by mmdevapi. I'll work on a better solution over the next few days. -- v2: Revert "winmm: Use AUTOCONVERTPCM when initializing the audio client." https://gitlab.winehq.org/wine/wine/-/merge_requests/9454

3 4

[PATCH 0/1] MR9625: dlls/sane.ds: Make UI Non-Modal as required by Twain specification
by Bernd Herd (＠herdsoft) Dec. 1, 2025

Dec. 1, 2025

This is neccessary according to the Twain specification and also allows much more comfortable user interfaces. The Twain specification is clear that event processing in the main application must be provided while the data source shows it's User Interface: ``` "You cannot use the modal dialog creation call DialogBox( ) to create the Source’s user interface main window. To allow event processing by both the application and the Source, this call cannot be used" ``` This was already documented that way in Twain Specification 1.8. According to the specification, MSG_ENABLEDS only creates the dialog and then returns. But the implementation in ui.c with the call to CreatePropertySheetW equals a "DialogBox" call and returns only when the user clicks OK or CANCEL. This Merge Requests sets PSH_MODELESS to make CreatePropertySheetW create a non-modal dialog and then returns control back to the application. To avoid crashes, some of the pointers passed to CreatePropertySheetW must stay valid as long as the dialog remains open. A pointer to an additional struct SUiData is stored with the activeDS and cleared when the user interface is cleared with DestroyWindow on MSG_DISABLEDS. To reduce the number of changes in the source code, the PROPSHEETHEADERW is not part of the struct as no problems were observable. The user interface is no longer automatically closed after every scan. Depening on the application program, it can stay open, ready for the next scan with just a click on the "Scan" button, which results in a much easier and faster user interface experience. For example the user might modifiy settings like resolution or brightness and start a second scan with the modified parameters with a singe click. The progress dialog is modified * to use the UI dialog as it's parent window. * And get created centered on the user interface dialog instead of the screen. Application orograms I found to profit from the modified behaviour: * IrfanView 4.7.2 if the Button "Close Twain dialog after acquiring an image" is disabled. * The simple memxfer.c source I recently attached to an older merge request. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9625

3 2

[PATCH 0/1] MR9602: dlls/sane.ds: Support SANE Backends that treat resolution as TYPE_FIXED
by Bernd Herd (＠herdsoft) Dec. 1, 2025

Dec. 1, 2025

Most SANE backends store resolution in DPI as an integer value TYPE_INT. Some store it as TYPE_FIXED. Twain always uses TW_FIX32 for resolution. This MR provide access to the resolution in ICAP_xRESOLUTION and DG_IMAGE/DAT_IMAGEINFO/MSG_GET for both types of sane backends. Since some backends have only one option "resolution" for both X and Y resolution, while others provide separate options for "x-resolution" and "y-resolution", there are a lot of possible combinations. Some backends do not allow read access to to their options once scanning has started. This had the consequene that for these backends, DG_IMAGE/DAT_IMAGEINFO/MSG_GET specified a resolution of -1. For that reason the current X/Y Resolution is now cached in activeDS before starting the scan. One backend that uses TYPE_FIXED is the SANE "test" backend. When setting a resolution, the test backend rounds to the nearest integer, so 300.4 DPI get 300.0 DPI and 300.6 DPI git 301 DPI. The test backend is not the only backend that stores resolution as TYPE_FIXED. This MR also contains code to display the resolution in DPI and the paper size calculated by pixel width/height and resolution in the progress dialog. If LOCALE_IMEASURE says that the locale applies the metric system, sizes are displayed in mm, otherwise (USA) sizes are displayed in inch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9602

3 2

[PATCH v3 0/3] MR9628: user32: Implement pointer input APIs for multi-touch support
by Hecheng Yu (＠kde-yyds) Dec. 1, 2025

Dec. 1, 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 -- v3: GetPointerType: Drop into an error and return false when id or type is invalid https://gitlab.winehq.org/wine/wine/-/merge_requests/9628

3 7

[PATCH v2 0/9] MR9618: windows.perception.stub: Stub SpatialAnchorExporter class.
by Paul Gofman (＠gofman) Dec. 1, 2025

Dec. 1, 2025

-- v2: coremessaging: Synchronize IAsyncInfo implementation in async.c. windows.security.credentials.ui.userconsentverifier: Synchronize IAsyncInfo implementation in async.c. windows.devices.enumeration: Synchronize IAsyncInfo implementation in async.c. cryptowinrt: Synchronize IAsyncInfo implementation in async.c. windows.gaming.input: Synchronize IAsyncInfo implementation in async.c. windows.media.speech: Synchronize IAsyncInfo implementation in async.c. windows.perception.stub: Implement exporter_statics_RequestAccessAsync(). windows.perception.stub: Stub SpatialAnchorExporter class. include: Add defintions related to Windows.Perception.Spatial.SpatialAnchorExporter. https://gitlab.winehq.org/wine/wine/-/merge_requests/9618

3 12

[PATCH v6 0/2] MR2545: winmm: Remove 'dwLineID' check when MIXER_GETLINECONTROLSF_ONEBYID
by Yeshun Ye (＠yeyeshun) Dec. 1, 2025

Dec. 1, 2025

winmm: Remove 'dwLineID' check when MIXER_GETLINECONTROLSF_ONEBYID winmm/tests: Add flags tests for mixerGetLineControlsA/W support MIXER_GETLINECONTROLSF_ONEBYID and MIXER_GETLINECONTROLSF_ONEBYTYPE Signed-off-by: YeshunYe <yeyeshun(a)uniontech.com> -- v6: winmm: Remove 'dwLineID' check when MIXER_GETLINECONTROLSF_ONEBYID winmm/tests: Add flags tests for mixerGetLineControlsA/W https://gitlab.winehq.org/wine/wine/-/merge_requests/2545

2 3

[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