- Wine-gitlab - list.winehq.org

Re: [PATCH v2 0/1] MR9932: ncrypt: Support ECDSA_P256. - approved
by Alexandre Julliard (＠julliard) 21 Jan '26

21 Jan '26

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9932

1 0

Re: [PATCH v2 0/1] MR9933: fusion: Create the legacy GAC directory in CreateAssemblyCache(). - approved
by Alexandre Julliard (＠julliard) 21 Jan '26

21 Jan '26

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9933

1 0

Re: [PATCH v2 0/1] MR9934: propsys: Fix parameter type of PropVariantToGUID. - approved
by Alexandre Julliard (＠julliard) 21 Jan '26

21 Jan '26

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9934

1 0

Re: [PATCH v8 0/2] MR9660: jscript: Treat DISPATCH_PROPERTYGET | DISPATCH_METHOD as property getter in ES5+ modes. - approved
by Alexandre Julliard (＠julliard) 21 Jan '26

21 Jan '26

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9660

1 0

[PATCH v7 0/2] MR9660: jscript: Treat DISPATCH_PROPERTYGET | DISPATCH_METHOD as property getter in ES5+ modes.
by Gabriel Ivăncescu (＠insn) 20 Jan '26

20 Jan '26

-- v7: mshtml: Handle DISPATCH_PROPERTYGET | DISPATCH_METHOD in dispex_value as jscript: Treat DISPATCH_PROPERTYGET | DISPATCH_METHOD as property getter https://gitlab.winehq.org/wine/wine/-/merge_requests/9660

3 3

[PATCH v3 0/4] MR9915: mmedvapi: Device name changes.
by Bernhard Kölbl (＠besentv) 20 Jan '26

20 Jan '26

The test in the last commit would still need an implementation, which turned out to be more complicated than the possible benefits. -- v3: mmdevapi/tests: Test for DEVPKEY_Device_FriendlyName in the registry. mmdevapi: Adjust device names. mmdevapi/tests: Check device friendly name pattern. mmdevapi/tests: Simplify a trace. https://gitlab.winehq.org/wine/wine/-/merge_requests/9915

3 8

[PATCH v7 0/5] MR9572: opengl32: Implement GL_EXT_memory_object_win32 for base handle types.
by Derek Lesho (＠dlesho) 20 Jan '26

20 Jan '26

Not sure about the extension replacement mechanism. Also, should tests be failing when extensions aren't supported? -- v7: opengl32: Expose GL_EXT_memory_object_win32. win32u/opengl: Implement glImportMemoryWin32(Handle/Name)EXT for opaque handle types. opengl32, win32u: Move gl_error to wgl_context. https://gitlab.winehq.org/wine/wine/-/merge_requests/9572

3 6

[PATCH v3 0/6] MR9616: Draft: opengl32: Implement GL_EXT_semaphore_win32 for base handle types.
by Derek Lesho (＠dlesho) 20 Jan '26

20 Jan '26

Depends on !9574 and !9572 . -- v3: opengl32: Expose GL_EXT_memory_object_win32 and GL_EXT_semaphore_win32. win32u/opengl: Implement glImportSemaphoreWin32(Handle/Name)EXT for opaque handle types. win32u/opengl: Implement glImportMemoryWin32(Handle/Name)EXT for opaque handle types. opengl32, win32u: Move gl_error to wgl_context. win32u/opengl: Implement GL_DEVICE_LUID_EXT and GL_DEVICE_NODE_MASK_EXT. opengl32: Cleanup glGet* and fix typo in glGetDoublev. https://gitlab.winehq.org/wine/wine/-/merge_requests/9616

4 10

[PATCH 0/1] MR9937: winegstreamer: Protect wg_transform drain and flush by mutex.
by Charlotte Pabst (＠CharlottePabst) 20 Jan '26

20 Jan '26

When flushing and draining at the same time from different threads without synchronization, one of them may fail and in the worst case, both fail, and the pipeline gets permanently stuck in EOS state. I'm dealing with a game that drains the Video Decoder MFT immediately after sending a stop command to the media session. In some cases, after the session is started again, the decoder does not output any samples anymore. The simple instance of this bug (with only one of them failing) stems from either drain-related events being pushed while the src pad is flushing, or flush-related events being pushed while the src pad is EOS. This does not cause any problems in the application. In the more complex case, the flush-stop event is processed by some pads (src in particular) but not yet the entire pipeline when a context switch happens, meaning that when the draining thread pushes its EOS event, it fails at a later pad (complete_drain then also fails), but is still stored as sticky in the src pad. After flush-stop finishes propagating, the stored EOS event then also propagates, leaving all pads in EOS state. This is the main problem I'm concerned about. I'm attaching `GST_DEBUG="4,WINE:9,GST_PADS:6,GST_EVENT:6"` logs for the EOS bug, as well as a test program. Note that the EOS case is comparatively rare. I'm unsure if this is the best fix for this issue, feel free to suggest something different. [flush-drain.c](/uploads/4e48cdea79a32867974c49b0aa2637c6/flush-drain.c) [flush-drain-bug.log](/uploads/9e873f0e807ecc665565a152bbade9d7/flush-drain-bug.log) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9937

3 2

[PATCH 0/1] MR9936: msado15: Fix WrapDSOandSession usage in connection_Open.
by Piotr Caban (＠piotr) 20 Jan '26

20 Jan '26

Fixes regression introduced by 3bc4b5a9f. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9936

2 1