- wine-gitlab - winehq.org

[PATCH v2 0/1] MR2569: Draft: mshtml: Wine Gecko 2.47.4 release.
by Jacek Caban (＠jacek) 10 Apr '23

10 Apr '23

This draft is for tracking Wine Gecko 2.47.4. I tagged rc1 release and uploaded builds and this MR makes use of it. What's new in this release: - Gitlab CI integration. Official binaries are build by Gitlab now. - Improved window messages handling for FFXIV. - New DOM API and CSS extensions for better IE compatibility mode support. - Compatibility fixes. -- v2: mshtml: Wine Gecko 2.47.4 release. https://gitlab.winehq.org/wine/wine/-/merge_requests/2569

3 2

Re: [PATCH v6 0/1] MR2565: mmdevapi: Implement function 'AEV_SetMasterVolumeLevelScalar'
by Huw Davies (＠huw) 10 Apr '23

10 Apr '23

There's too much going on in this commit / MR. The changes to the drivers seem to be addressing a bug rather than implementing the Endpoint Volume API. Also, note that the values passed to the non-`Scalar` API are in decibels, the `Scalar` API appears to be somewhere between linear and logrithmic, and the `ISimpleAudioVolume` values are linear. Does your app call the `Scalar` versions of the API? If so, a good start would be to write some tests to figure out the mapping between `Scalar` and non-`Scalar` by e.g. setting using one and retreiving that value using the other. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2565#note_29455

1 0

[PATCH v3 0/3] MR136: vkd3d-shader/hlsl: Handle discard statement.
by Nikolay Sivov (＠nsivov) 10 Apr '23

10 Apr '23

-- v3: tests: Add a simple test for "discard". vkd3d-shader/hlsl: Handle discard statement. vkd3d-shader/trace: Add separate id for discard. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/136

4 6

[PATCH 0/1] MR2622: ntdll: Use log-linear bucketing for free lists.
by Tatsuyuki Ishi (＠ishitatsuyuki) 10 Apr '23

10 Apr '23

Currently, the free list consists of a "small list" for sizes below 256, which are linearly spaced, and a "large list" which is manually split into a few chunks. This patch replaces it with a single log-linear policy, while expanding the range the large list covers. The old implementation had issues when a lot of large allocations happened. In this case, all the allocations went in the last catch-all bucket in the "large list", and what happens is: 1. The linked list grew in size over time, causing searching cost to skyrocket. 2. With the first-fit allocation policy, fragmentation was also making the problem worse. The new bucketing covers the entire range up until we start allocating large blocks, which will not enter the free list. It also makes the allocation policy closer to best-fit (although not exactly), reducing fragmentation. The increase in number of free lists does incur some cost when it needs to be skipped over, but the improvement in allocation performance outweighs it. For future work, these ideas (mostly from glibc) might or might not benefit performance: - Use an exact best-fit allocation policy. - Add a bitmap for freelist, allowing empty lists to be skipped with a single bit scan. Signed-off-by: Tatsuyuki Ishi <ishitatsuyuki(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2622

3 3

[PATCH 0/1] MR2611: iphlpapi: Fix the GAA_FLAG_INCLUDE_GATEWAYS constant name.
by Francois Gouget (＠fgouget) 10 Apr '23

10 Apr '23

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

4 3

[PATCH v5 0/2] MR131: vkd3d: Persistently map host-visible heaps on creation.
by Zebediah Figura (＠zfigura) 10 Apr '23

10 Apr '23

-- v5: tests: Add a test for readback map stability. vkd3d: Persistently map host-visible heaps on creation. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/131

4 3

[PATCH v4 0/4] MR2603: winecoreaudio: Move timer logic to unixlib, matching other drivers.
by Davide Beatrici (＠davidebeatrici) 10 Apr '23

10 Apr '23

-- v4: winecoreaudio: Implement and call timer_loop in unixlib. winecoreaudio: Implement and call set_event_handle in unixlib. winecoreaudio: Store flags in unixlib. winecoreaudio: Retain precision when storing period in unixlib. https://gitlab.winehq.org/wine/wine/-/merge_requests/2603

3 5

[PATCH v3 0/1] MR2032: winex11: Allow replacing either context in wglShareLists.
by Alex Henrie (＠alexhenrie) 10 Apr '23

10 Apr '23

The deleted test is a bad test: The behavior is different on different drivers, for example, the test fails on the Windows 10 and 11 testbot machines that have AMD video cards. Furthermore, MSDN does not say that the destination context "must not" have any display lists yet but rather that it "should not" have any.[1] The Khronos OpenGL Wiki similarly advises against calling wglShareLists after the source or destination context has at least one object, but if you do, it only says that "there is a chance that wglShareLists will fail", not that it will necessarily fail.[2] Since there's no clear "right" behavior here, we can adopt the more permissive behavior that some programs expect, as long as it doesn't corrupt the context. [1] https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-wglsha… [2] https://www.khronos.org/opengl/wiki/Platform_specifics:_Windows#wglShareLis… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=11436 -- v3: winex11: Allow replacing either context in wglShareLists. https://gitlab.winehq.org/wine/wine/-/merge_requests/2032

3 7

[PATCH 0/5] MR2621: Some IShellView improvements.
by Jactry Zeng (＠jactry) 10 Apr '23

10 Apr '23

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

2 5

[PATCH 0/2] MR2620: include: Add windows.ui.composition.interop.idl file.
by Mohamad Al-Jaf (＠maljaf) 10 Apr '23

10 Apr '23

Needed for mingw Firefox build. The WIDL error points to the wrong function, specifically the one after it. include/windows.ui.composition.interop.idl:35:63: error: parameter 'swapchain' of function 'CreateCompositionSurfaceForHandle' cannot derive from void * HRESULT CreateCompositionSurfaceForSwapChain([in] IUnknown *swapchain, [out, retval] ICompositionSurface **result); ^ make[1]: *** [Makefile:163749: include/windows.ui.composition.interop.h] Error 1 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2620

3 4

[PATCH v2 0/1] MR2619: mfplat: Handle more video subtypes in MFInitMediaTypeFromAMMediaType().
by Nikolay Sivov (＠nsivov) 09 Apr '23

09 Apr '23

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: mfplat: Handle more video subtypes in MFInitMediaTypeFromAMMediaType(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2619

2 1

[PATCH 0/1] MR2619: mfplat: Handle more video subtypes in MFInitMediaTypeFromAMMediaType().
by Nikolay Sivov (＠nsivov) 09 Apr '23

09 Apr '23

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2619

3 2

[PATCH 0/1] MR2618: ntdll: Increment offset by len in build_clr_surrogate_section.
by Alex Henrie (＠alexhenrie) 09 Apr '23

09 Apr '23

Instead of multiplying it by 2. I don't know how this ever worked. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54808 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2618

3 3

[PATCH v3 0/1] MR150: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops.
by Nikolay Sivov (＠nsivov) 08 Apr '23

08 Apr '23

-- v3: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/150

3 2

Re: [PATCH v5 0/5] MR2555: Draft: ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID (#18889)
by Jinoh Kang (＠iamahuman) 08 Apr '23

08 Apr '23

On Sat Apr 8 12:22:23 2023 +0000, Nikolay Sivov wrote: > As I recall, for original fix to accept a range of resource IDs the > question was how are those different from each other, meaning if there > are multiple resources, when one should be used but not another. From Micrsoft documentation, [Using Side-by-Side Assemblies as a Resource][sxs-rsrc] outlines the significance of each reserved manifest resource ID. Further investigation reveals the following: 1. `CREATEPROCESS_MANIFEST_RESOURCE_ID` (value: `1`): This is used for process-wide initial (`NULL`) activation context. - **Usage documentation**: [Enabling an Assembly in an Application Without Extensions](https://learn.microsoft.com/en-us/windows/win32/sbscs/enabling-… - **Intended container module type**: EXE only. - **Lifetime of the associated activation context**: Alive until the process is terminated. Owned by system (NTDLL). - **Isolation-aware**: No. 2. `ISOLATIONAWARE_MANIFEST_RESOURCE_ID` (value: `2`): This is used to specify the assembly manifest that the loader (Ldr) uses to resolve static imports. Also, this is used by isolation-aware wrappers defined in `*.inl` files included in the Windows SDK (`include\um`) when the `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value. - **Usage documentation**: [Enabling an Assembly in an Application Hosting a DLL, Extension, or Control Panel](https://learn.microsoft.com/en-us/windows/win32/sbscs/enabling-an-as… - **Intended container module type**: EXE and DLL. - **Lifetime of the associated activation context**: Alive until the module is unloaded (e.g., via `FreeLibrary`). Owned by system (NTDLL). - **Isolation-aware**: Yes. 3. `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID` (value: `3`): Ignored by the loader when resolving static imports. This is used by isolation-aware API wrappers defined in `*.inl` files included in the Windows SDK (`include\um`) when the `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value. - **Usage documentation**: [IsolationAwareCleanup function][IsolationAwareCleanup] - **Intended container module type**: EXE and DLL. - **Lifetime of the associated activation context**: Alive until the application calls [`IsolationAwareCleanup`][IsolationAwareCleanup][^ia-cleanup-note]. Owned by the isolation-aware API wrapper library (part of the Windows SDK, rather than being a system DLL). - **Isolation-aware**: Yes. The `ISOLATION_AWARE_ENABLED` macro is documented in [Isolating Components][sxs-ic] as well as [Specifying a Default Activation Context][sxs-def-actctx]. When `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value, then the isolation-aware API wrapper library is enabled. The isolation-aware API wrapper library is responsible for: - Creating (lazily) and destroying activation context (in `IsolationAwareCleanup`), if the manifest resource ID is `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID`.[^actctx-lifetime-remark] - Note: the isolation-aware API wrapper library does not manage the activation context's lifetime and delegates the responsibility to the system loader if the manifest resource ID is `ISOLATIONAWARE_MANIFEST_RESOURCE_ID`. - Intercepting Win32 API calls for automatic activation context activation. Each API wrapper activates the "isolation-aware" activation context (obtaining one if it did not exist) before calling the original procedure, and deactivates it before returning. The isolation-aware wrappers may be either be defined inline, or compiled into static libraries that are linked into the final application executable. From the information above as well as the tests included in this merge request, we can infer the following: 1. Although side-by-side awareness is a cross-cutting concern, the *activation* of activation contexts itself is *not* usually performed automatically by the system for the application (with the sole exception of process-wide activation context associated with `CREATEPROCESS_MANIFEST_RESOURCE_ID`, and static import resolution). 2. `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID` is treated like any other resource ID (from `0x0002` to `0xffff`) as far as the loader is concerned. 3. The resource ID of the manifest only concerns how the module containing the manifest intends to use the manifest. In fact, for DLLs that do not *statically* import symbols from side-by-side assemblies, the three resource IDs above are basically equivalent. A DLL can elect not to use manifest resources at all, and manage activation context and library loading by itself. This is why I believe that this merge request is sufficient in completing the isolation-aware component support in Wine; the heavy lifting is done in the application side, not the system. **EDIT**: Fix a few typos and unclear wording. --- [^ia-cleanup-note]: According to the documentation, the application is presumably responsible for calling `IsolationAwareCleanup` from `DllMain` on `fdwReason = DLL_PROCESS_DETACH`. [^actctx-lifetime-remark]: [IsolationAwareCleanup § Remarks](https://learn.microsoft.com/en-us/previous-versions/windows/deskto…, from Microsoft documentation. [sxs-rsrc]: https://learn.microsoft.com/en-us/windows/win32/sbscs/using-side-by-side-as… [IsolationAwareCleanup]: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/… [sxs-ic]: https://learn.microsoft.com/en-us/windows/win32/sbscs/isolating-components [sxs-def-actctx]: https://learn.microsoft.com/en-us/windows/win32/sbscs/specifying-a-default-… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2555#note_29411

1 0

Re: [PATCH v5 0/5] MR2555: Draft: ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID (#18889)
by Jinoh Kang (＠iamahuman) 08 Apr '23

08 Apr '23

On Sat Apr 8 12:22:23 2023 +0000, Nikolay Sivov wrote: > As I recall, for original fix to accept a range of resource IDs the > question was how are those different from each other, meaning if there > are multiple resources, when one should be used but not another. From Micrsoft documentation, [Using Side-by-Side Assemblies as a Resource][sxs-rsrc] outlines the significance of each reserved manifest resource ID. Further investigation shows the following: 1. `CREATEPROCESS_MANIFEST_RESOURCE_ID` (value: `1`): This is used for process-wide initial (`NULL`) activation context. - **Usage documentation**: [Enabling an Assembly in an Application Without Extensions](https://learn.microsoft.com/en-us/windows/win32/sbscs/enabling-… - **Intended container module type**: EXE only. - **Lifetime**: Alive until the process is terminated. Owned by system (NTDLL). - **Isolation-aware**: No. 2. `ISOLATIONAWARE_MANIFEST_RESOURCE_ID` (value: `2`): This is used to specify the assembly manifest that the loader (Ldr) uses to resolve static imports. Also, this is used by isolation-aware wrappers defined in `*.inl` files included in the Windows SDK (`include\um`) when the `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value. - **Usage documentation**: [Enabling an Assembly in an Application Hosting a DLL, Extension, or Control Panel](https://learn.microsoft.com/en-us/windows/win32/sbscs/enabling-an-as… - **Intended container module type**: EXE and DLL. - **Lifetime**: Alive until the module is unloaded (e.g., via `FreeLibrary`). Owned by system (NTDLL). - **Isolation-aware**: Yes. 3. `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID` (value: `3`): Ignored by the loader when resolving static imports. This is used by isolation-aware API wrappers defined in `*.inl` files included in the Windows SDK (`include\um`) when the `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value. - **Usage documentation**: [IsolationAwareCleanup function][IsolationAwareCleanup] - **Intended container module type**: EXE and DLL. - **Lifetime**: Alive until the application calls [`IsolationAwareCleanup`][IsolationAwareCleanup][^ia-cleanup-note]. Owned by the isolation-aware API wrapper library. - **Isolation-aware**: Yes. The `ISOLATION_AWARE_ENABLED` macro is documented in [Isolating Components][sxs-ic] as well as [Specifying a Default Activation Context][sxs-def-actctx]. When `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value, then the isolation-aware API wrapper library is enabled. The isolation-aware API wrapper library is responsible for: - Creating (lazily) and destroying activation context (in `IsolationAwareCleanup`), if the manifest resource ID is `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID`.[^actctx-lifetime-remark] - Note: the loader does not manage the activation context's lifetime and delegates the responsibility to the system loader if the manifest resource ID is `ISOLATIONAWARE_MANIFEST_RESOURCE_ID`. - Intercepting Win32 API calls for automatic activation context activation. Each API wrapper activates the "isolation-aware" activation context (obtaining one if it did not exist) before calling the original procedure, and deactivates it before returning. The isolation-aware wrappers may be either be defined inline, or compiled into static libraries that are linked to the final application executable. From the information above, we can infer the following: 1. Although side-by-side awareness is a cross-cutting concern, the *activation* of activation contexts itself is *not* usually performed automatically by the system (with the sole exception of process-wide activation context associated with `CREATEPROCESS_MANIFEST_RESOURCE_ID`). 2. `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID` is treated like any other resource ID as far as the loader is concerned. 3. The resource ID of the manifest only concerns how the module containing the manifest intends to use the manifest. In fact, for DLLs that do not *statically* import symbols from side-by-side assemblies, the three resource IDs above are basically equivalent. A DLL can elect not to use manifest resources at all, and manage activation context and library loading by itself. This is why I believe that this merge request is sufficient in completing the isolation-aware component support in Wine; the heavy lifting is done by the application side, not the system. --- [^ia-cleanup-note]: According to the documentation, the application is presumably responsible for calling `IsolationAwareCleanup` from `DllMain` on `fdwReason = DLL_PROCESS_DETACH`. [^actctx-lifetime-remark]: [IsolationAwareCleanup § Remarks](https://learn.microsoft.com/en-us/previous-versions/windows/deskto…, from Microsoft documentation. [sxs-rsrc]: https://learn.microsoft.com/en-us/windows/win32/sbscs/using-side-by-side-as… [IsolationAwareCleanup]: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/… [sxs-ic]: https://learn.microsoft.com/en-us/windows/win32/sbscs/isolating-components [sxs-def-actctx]: https://learn.microsoft.com/en-us/windows/win32/sbscs/specifying-a-default-… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2555#note_29410

1 0

[PATCH v4 0/1] MR2609: shlwapi: Implement StrFormatByteSizeEx
by David Kahurani (＠kahurani) 08 Apr '23

08 Apr '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54733 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v4: shlwapi: Implement StrFormatByteSizeEx https://gitlab.winehq.org/wine/wine/-/merge_requests/2609

2 1

[PATCH v3 0/1] MR2609: shlwapi: Implement StrFormatByteSizeEx
by David Kahurani (＠kahurani) 08 Apr '23

08 Apr '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54733 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v3: shlwapi: Implement StrFormatByteSizeEx https://gitlab.winehq.org/wine/wine/-/merge_requests/2609

2 1

[PATCH v2 0/1] MR2609: shlwapi: Implement StrFormatByteSizeEx
by David Kahurani (＠kahurani) 08 Apr '23

08 Apr '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54733 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v2: shlwapi: Implement StrFormatByteSizeEx https://gitlab.winehq.org/wine/wine/-/merge_requests/2609

2 1

[PATCH 0/1] MR2609: shlwapi: Implement StrFormatByteSizeEx
by David Kahurani (＠kahurani) 08 Apr '23

08 Apr '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54733 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2609

3 9

[PATCH v3 0/1] MR2617: kernel32/tests: Fix test for ACTCTX_FLAG_HMODULE_VALID with hModule = NULL case.
by Jinoh Kang (＠iamahuman) 08 Apr '23

08 Apr '23

Today, the test scenario "ACTCTX_FLAG_HMODULE_VALID but hModule if not set" is broken and unreliable. This problem is not evident in WineHQ batch test runs; rather, the test failure seems to only be triggered when the kernel32:actctx test is run in isolation. When the flag ACTCTX_FLAG_HMODULE_VALID is specified in ACTCTX but hModule is set to NULL, CreateActCtxW() may encounter different failure modes depending on the environment and/or the test executable file. Error codes observed so far include ERROR_SXS_CANT_GEN_ACTCTX and ERROR_SXS_MANIFEST_TOO_BIG. It appears that the inconsistent failure was caused by Windows trying to interpret the main executable file of the current process as an XML manifest file. This fails for the following reasons: - A valid PE executable that starts with the "MZ" signature is not a valid XML file. - The test executable's size exceeds the limit imposed by the manifest parser. This is much more likely for binaries with debugging symbols. Meanwhile, winetest bundles a stripped version of the test executable (kernel32_test-stripped.exe), which may end up masking the problem. Fix this by changing the FullDllName of the main executable module's LDR_DATA_TABLE_ENTRY to the pathname of a temporary manifest file (valid or invalid) before testing. The testing is performed in a child process, since it deliberately "corrupts" the process state. -- v3: kernel32/tests: Fix test for ACTCTX_FLAG_HMODULE_VALID with hModule = NULL case. https://gitlab.winehq.org/wine/wine/-/merge_requests/2617

2 2

[PATCH v2 0/1] MR2617: kernel32/tests: Fix test for ACTCTX_FLAG_HMODULE_VALID with hModule = NULL case.
by Jinoh Kang (＠iamahuman) 08 Apr '23

08 Apr '23

Today, the test scenario "ACTCTX_FLAG_HMODULE_VALID but hModule if not set" is broken and unreliable. This problem is not evident in WineHQ batch test runs; rather, the test failure seems to only be triggered when the kernel32:actctx test is run in isolation. When the flag ACTCTX_FLAG_HMODULE_VALID is specified in ACTCTX but hModule is set to NULL, CreateActCtxW() may encounter different failure modes depending on the environment and/or the test executable file. Error codes observed so far include ERROR_SXS_CANT_GEN_ACTCTX and ERROR_SXS_MANIFEST_TOO_BIG. It appears that the inconsistent failure was caused by Windows trying to interpret the main executable file of the current process as an XML manifest file. Note that a valid PE executable that starts with the "MZ" signature is not a valid XML file; furthermore, the test executable may simply be too large for a single manifest file. Fix this by changing the FullDllName of the main executable module's LDR_DATA_TABLE_ENTRY to the pathname of a temporary manifest file (valid or invalid) before testing. The testing is performed in a child process, since it deliberately "corrupts" the process state. -- Notes: - Deleting the temporary file should be done by the `create_temp_manifest_file` -- v2: kernel32/tests: Fix test for ACTCTX_FLAG_HMODULE_VALID with hModule = NULL case. https://gitlab.winehq.org/wine/wine/-/merge_requests/2617

2 1

[PATCH 0/1] MR2617: kernel32/tests: Fix test for missing ACTCTX hModule in 64-bit Windows.
by Jinoh Kang (＠iamahuman) 08 Apr '23

08 Apr '23

Today, the test scenario "ACTCTX_FLAG_HMODULE_VALID but hModule if not set" is broken and unreliable. This problem is not evident in WineHQ batch test runs; rather, the test failure seems to only be triggered when the kernel32:actctx test is run in isolation. When the flag ACTCTX_FLAG_HMODULE_VALID is specified in ACTCTX but hModule is set to NULL, CreateActCtxW() may encounter different failure modes depending on the environment and/or the test executable file. Error codes observed so far include ERROR_SXS_CANT_GEN_ACTCTX and ERROR_SXS_MANIFEST_TOO_BIG. It appears that the inconsistent failure was caused by Windows trying to interpret the main executable file of the current process as an XML manifest file. Note that a valid PE executable that starts with the "MZ" signature is not a valid XML file; furthermore, the test executable may simply be too large for a single manifest file. Fix this by changing the FullDllName of the main executable module's LDR_DATA_TABLE_ENTRY to the pathname of a temporary manifest file (valid or invalid) before testing. The testing is performed in a child process, since it deliberately "corrupts" the process state. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2617

2 1

[PATCH v6 0/5] MR2587: Support MF DXGI device manager in h264 decoder
by Paul Gofman (＠gofman) 08 Apr '23

08 Apr '23

The last patch is a huge optimization to what is done in patch 2. Without that the sample is first copied from GPU to CPU each time wg_transform_read_mf() locks the buffer (allocating extra linear buffer on the way) and then copies the data back to GPU. That happens even if there is no sample available from wg_transform. With the last patch there is just one memory copy to the (write-only) locked DXGI surface buffer. And CPU to GPU texture transfer (which would be there anyway in most cases on software path as most of the apps are going to get the image to GPU anyway). In principle we could also skip the explicit staging texture and use _UpdateSubresource instead directly from h264 decoder, but this is currently not supported in wined3d for chroma formats and the overall difference between _UpdateSubresource and explicit mapped staging texture is not that great probably. -- v6: winegstreamer: Pass temporary sample to wg_transform_read_mf() in h264 decoder. winegstreamer: Provide samples if DXGI device manager is set in h264 decoder. winegstreamer: Process MFT_MESSAGE_SET_D3D_MANAGER in h264 decoder. mf/tests: Test h264 decoder with dxgi device manager. https://gitlab.winehq.org/wine/wine/-/merge_requests/2587

2 7

[PATCH v5 0/5] MR2587: Support MF DXGI device manager in h264 decoder
by Paul Gofman (＠gofman) 07 Apr '23

07 Apr '23

The last patch is a huge optimization to what is done in patch 2. Without that the sample is first copied from GPU to CPU each time wg_transform_read_mf() locks the buffer (allocating extra linear buffer on the way) and then copies the data back to GPU. That happens even if there is no sample available from wg_transform. With the last patch there is just one memory copy to the (write-only) locked DXGI surface buffer. And CPU to GPU texture transfer (which would be there anyway in most cases on software path as most of the apps are going to get the image to GPU anyway). In principle we could also skip the explicit staging texture and use _UpdateSubresource instead directly from h264 decoder, but this is currently not supported in wined3d for chroma formats and the overall difference between _UpdateSubresource and explicit mapped staging texture is not that great probably. -- v5: winegstreamer: Pass temporary sample to wg_transform_read_mf() in h264 decoder. winegstreamer: Provide samples if DXGI device manager is set in h264 decoder. winegstreamer: Process MFT_MESSAGE_SET_D3D_MANAGER in h264 decoder. mf/tests: Test h264 decoder with dxgi device manager. mf/tests: Increase h264data.bin video length. https://gitlab.winehq.org/wine/wine/-/merge_requests/2587

3 7

Re: [PATCH v2 0/1] MR2600: wined3d: Add GPU information for AMD Raphael. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/1] MR2614: winevulkan: Add support for VK_KHR_map_memory2. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v5 0/1] MR2554: msvcp110: semi-stub _Rethrow_future_exception - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/1] MR2613: kernel32/tests: Improve the WideCharToMultiByte() null-termination and truncation tests. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/2] MR2612: Small wininet:internet cleanups - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v5 0/6] MR2598: imm32: Move IME UI window proc to the default implementation. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v3 0/4] MR2607: imm32/tests: Add more INPUTCONTEXT updates tests, and Imm(Set|Get)CompositionString. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/1] MR2610: dinput/tests: Fix the spelling of an ok() message. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v3 0/1] MR2557: msado15: Initialize all SYSTEMTIME members - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/2] MR2596: wined3d: Do not use glFramebufferTexture() to bind array RTVs with an array size of one. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v3 0/2] MR2605: ldap fixes - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/12] MR2608: msvcrt: Use still more functions from the bundled musl library. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/2] MR2604: light.msstyles: Use border fill background for progress parts. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v5 0/4] MR2159: winegstreamer: Stride and RGB formats, part 2/2. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/2] MR2606: wineps: Support more blit functions. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

Re: [PATCH v2 0/3] MR2584: d3dx10: Port some additional D3DX10GetImageInfoFromMemory() tests from d3dx11. - approved
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

1 0

[PATCH 0/1] MR2600: wined3d: Add GPU information for AMD Raphael.
by Zhiyi Zhang (＠zhiyi) 07 Apr '23

07 Apr '23

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

4 3

[PATCH v4 0/3] MR2496: Fix hang when a program calls IMFMediaSession_Start with an invalid source.
by Santino Mazza (＠tati1454) 07 Apr '23

07 Apr '23

This fixes a bug when the session topology contains an invalid source, which makes the session thread to hang and stop executing commands. -- v4: mf: Handle error when IMFMediaSource_Start fails. mf: Handle errors when subscribing to events. mf/tests: Test media session error handling. https://gitlab.winehq.org/wine/wine/-/merge_requests/2496

2 4

[PATCH 0/1] MR2614: winevulkan: Add support for VK_KHR_map_memory2.
by Jacek Caban (＠jacek) 07 Apr '23

07 Apr '23

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

2 1

[PATCH v3 0/2] MR2496: Draft: Fix hang when a program calls IMFMediaSession_Start with an invalid source.
by Santino Mazza (＠tati1454) 07 Apr '23

07 Apr '23

This fixes a bug when the session topology contains an invalid source, which makes the session thread to hang and stop executing commands. -- v3: mf: Handle errors when subscribing to events. mf/tests: Test media session error handling. https://gitlab.winehq.org/wine/wine/-/merge_requests/2496

3 5

[PATCH v4 0/1] MR2554: msvcp110: semi-stub _Rethrow_future_exception
by Vijay Kiran Kamuju (＠infyquest) 07 Apr '23

07 Apr '23

https://bugs.winehq.org/show_bug.cgi?id=54110 -- v4: msvcp110: Add std::_Rethrow_future_exception implementation. https://gitlab.winehq.org/wine/wine/-/merge_requests/2554

3 2

[PATCH 0/2] MR2612: Small wininet:internet cleanups
by Francois Gouget (＠fgouget) 07 Apr '23

07 Apr '23

* wininet/tests: Avoid an unnecessary strlen() call in internet.c. * wininet/tests: Remove redundant quotes in an ok() message. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2612

3 3

Re: [PATCH v4 0/6] MR2598: imm32: Move IME UI window proc to the default implementation. - approved
by Jacek Caban (＠jacek) 07 Apr '23

07 Apr '23

This merge request was approved by Jacek Caban. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2598

1 0

[PATCH 0/1] MR2613: kernel32/tests: Improve the WideCharToMultiByte() null-termination and truncation tests.
by Francois Gouget (＠fgouget) 07 Apr '23

07 Apr '23

Check the content of the output buffer in addition to checking the return value. Also show that multibyte characters are not truncated when the output buffer is too small. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2613

2 1

Re: [PATCH v4 0/6] MR2598: imm32: Move IME UI window proc to the default implementation.
by Jacek Caban (＠jacek) 07 Apr '23

07 Apr '23

On Fri Apr 7 14:53:00 2023 +0000, Rémi Bernon wrote: > > I'm not sure what you mean by very integrated with win32u. Exposing > builtin IMEs as "normal" IMEs is not affected by changes that I suggest. > For driver interface, it would just replace one driver entry by another. > I think I was confused by the idea of adding win32u specific interface > for the callbacks. I'll consider doing this, as I think it also make > sense to pass NtUserNotifyIMEStatus calls. > I'm curious then, is there any advantage of using `NtUserMessageCall` vs > `NtUserCallOneParam` or one of the other flavor? `NtUserMessageCall` > takes a hwnd as first parameter, it feels a bit wrong to use an HIMC there. I'd expect that `NtUserMessageCall` would be a bit nicer for wow64, because it may just pass through arguments like `NtUserSpyGetMsgName`, but yeah, handle type mismatch is not that nice. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2598#note_29322

1 0

Re: [PATCH v4 0/6] MR2598: imm32: Move IME UI window proc to the default implementation.
by Rémi Bernon (＠rbernon) 07 Apr '23

07 Apr '23

v4: Fix macOS build by removing its ime_private definition early, and merging it with winex11 in ntuser.h. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2598#note_29321

1 0

[PATCH 0/1] MR2610: dinput/tests: Fix the spelling of an ok() message.
by Francois Gouget (＠fgouget) 07 Apr '23

07 Apr '23

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

3 2

[PATCH v3 0/6] MR2598: imm32: Move IME UI window proc to the default implementation.
by Rémi Bernon (＠rbernon) 07 Apr '23

07 Apr '23

This adds a new `wine/ime.h` header, to share the `IMEPRIVATE` structure between `imm32`, `winex11` and `winemac`. This structure will be internal to `imm32` ultimately, but I intend to keep the header to define a new internal interface for driver to call back into `imm32` (through the UI window), and for a new interface to call from `imm32` into host IME implemented by the drivers. -- v3: imm32: Remove unnecessary HIMC check in IME UI window proc. imm32: Call DefWindowProcW from IME UI for unhandled messages. imm32: Cleanup default IME UI window proc traces. winemac: Use the default IME UI window proc implementation. winex11: Move IME UI proc to default IME implementation. winex11: Cleanup spaces in IME UI window proc. https://gitlab.winehq.org/wine/wine/-/merge_requests/2598

2 8

[PATCH v2 0/4] MR2607: imm32/tests: Add more INPUTCONTEXT updates tests, and Imm(Set|Get)CompositionString.
by Rémi Bernon (＠rbernon) 07 Apr '23

07 Apr '23

-- v2: imm32/tests: Add more ImmSetCompositionString tests. imm32/tests: Add more ImmGetCompositionString(W|A) tests. imm32/tests: Test WM_IME_NOTIFY messages target window. imm32/tests: Test setting the same HIMC statuses twice. https://gitlab.winehq.org/wine/wine/-/merge_requests/2607

3 6

[PATCH v2 0/6] MR2598: imm32: Move IME UI window proc to the default implementation.
by Rémi Bernon (＠rbernon) 07 Apr '23

07 Apr '23

This adds a new `wine/ime.h` header, to share the `IMEPRIVATE` structure between `imm32`, `winex11` and `winemac`. This structure will be internal to `imm32` ultimately, but I intend to keep the header to define a new internal interface for driver to call back into `imm32` (through the UI window), and for a new interface to call from `imm32` into host IME implemented by the drivers. -- v2: imm32: Remove unnecessary HIMC check in IME UI window proc. imm32: Call DefWindowProcW from IME UI for unhandled messages. imm32: Cleanup default IME UI window proc traces. winemac: Use the default IME UI window proc implementation. winex11: Move IME UI proc to default IME implementation. winex11: Cleanup spaces in IME UI window proc. https://gitlab.winehq.org/wine/wine/-/merge_requests/2598

3 8

[PATCH 0/12] MR2608: msvcrt: Use still more functions from the bundled musl library.
by Alexandre Julliard (＠julliard) 07 Apr '23

07 Apr '23

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

3 13

[PATCH 0/6] MR2598: imm32: Move IME UI window proc to the default implementation.
by Rémi Bernon (＠rbernon) 07 Apr '23

07 Apr '23

This adds a new `wine/ime.h` header, to share the `IMEPRIVATE` structure between `imm32`, `winex11` and `winemac`. This structure will be internal to `imm32` ultimately, but I intend to keep the header to define a new internal interface for driver to call back into `imm32` (through the UI window), and for a new interface to call from `imm32` into host IME implemented by the drivers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2598

4 11

[PATCH v2 0/3] MR2455: wined3d: Avoid VK_IMAGE_LAYOUT_GENERAL.
by Stefan Dösinger (＠stefan) 07 Apr '23

07 Apr '23

This series aims to improve GPU-side performance by avoiding VK_IMAGE_LAYOUT_GENERAL for textures that are used as render target and shader resource view. To do so, we have to transition them between VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL and VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL depending on use (and likewise for depth stencils). It improves performance of Rocket League from 80 fps to 100 fps in a GPU limited configuration on my Radeon Polaris GPU. This MR is marked as draft for now because I am not convinced by patch 3 yet. For actual submission I think I'll create separate MRs for patches 1-3 and 4-8. Patch 2 introduces a validation layer error in the d3d11 tests that gets fixed in patch 3. No new test failures are introduced, although none of the existing ones are fixed either. -- v2: wined3d: Fall back to general layout if necessary. wined3d: Avoid VK_IMAGE_LAYOUT_GENERAL. wined3d: Sync depth stencils to both early and late depth test. https://gitlab.winehq.org/wine/wine/-/merge_requests/2455

3 5

[PATCH v2 0/2] MR2605: ldap fixes
by Hans Leidekker (＠hans) 07 Apr '23

07 Apr '23

-- v2: https://gitlab.winehq.org/wine/wine/-/merge_requests/2605

2 3

[PATCH 0/2] MR2596: wined3d: Do not use glFramebufferTexture() to bind array RTVs with an array size of one.
by Zebediah Figura (＠zfigura) 07 Apr '23

07 Apr '23

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

3 3

[PATCH 0/3] MR2605: ldap fixes
by Hans Leidekker (＠hans) 07 Apr '23

07 Apr '23

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

3 4

[PATCH 0/4] MR2607: imm32/tests: Add more INPUTCONTEXT updates tests, and Imm(Set|Get)CompositionString.
by Rémi Bernon (＠rbernon) 07 Apr '23

07 Apr '23

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

3 6

Re: [PATCH v5 0/2] MR2545: winmm: Remove 'dwLineID' check when MIXER_GETLINECONTROLSF_ONEBYID
by Huw Davies (＠huw) 07 Apr '23

07 Apr '23

On Fri Mar 31 08:39:53 2023 +0000, **** wrote: > Marvin replied on the mailing list: > ``` > Hi, > It looks like your patch introduced the new failures shown below. > Please investigate and fix them before resubmitting your patch. > If they are not new, fixing them anyway would help a lot. Otherwise > please ask for the known failures list to be updated. > The tests also ran into some preexisting test failures. If you know how > to fix them that would be helpful. See the TestBot job for the details: > The full results can be found at: > https://testbot.winehq.org/JobDetails.pl?Key=131332 > Your paranoid android. > === w7u_2qxl (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w7u_adm (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w7u_el (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w8 (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w8adm (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w864 (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w1064v1507 (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w1064v1809 (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w1064_tsign (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w10pro64 (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w11pro64 (32 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w7pro64 (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w864 (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w1064v1507 (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w1064v1809 (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w1064_2qxl (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w1064_adm (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w1064_tsign (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w10pro64 (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w10pro64_en_AE_u8 (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w10pro64_ar (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w10pro64_ja (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > === w10pro64_zh_CN (64 bit report) === > winmm: > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:441: Test failed: > mixerGetLineControlsA(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > mixer.c:872: Test failed: > mixerGetLineControlsW(MIXER_GETLINECONTROLSF_ONEBYID): MMSYSERR_NOERROR > expected, got MIXERR_INVALCONTROL > ``` Did these failures get addressed? I don't see testbot runs for the later versions of the commits in this MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2545#note_29281

1 0

[PATCH v3 0/1] MR2603: winecoreaudio: Move timer logic to unixlib, matching other drivers.
by Davide Beatrici (＠davidebeatrici) 07 Apr '23

07 Apr '23

-- v3: winecoreaudio: Move timer logic to unixlib, matching other drivers. https://gitlab.winehq.org/wine/wine/-/merge_requests/2603

3 4

[PATCH 0/1] MR140: vkd3d-shader/hlsl: Handle SV_IsFrontFace semantic.
by Nikolay Sivov (＠nsivov) 07 Apr '23

07 Apr '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/140

3 5

[PATCH 0/2] MR2606: wineps: Support more blit functions.
by Piotr Caban (＠piotr) 07 Apr '23

07 Apr '23

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

3 3

[PATCH 0/3] MR2584: d3dx10: Port some additional D3DX10GetImageInfoFromMemory() tests from d3dx11.
by Zebediah Figura (＠zfigura) 07 Apr '23

07 Apr '23

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

4 5

[PATCH v2 0/2] MR2546: winegstreamer: Create extra decodebin to decode compressed stream.
by Ziqing Hui (＠zhui) 07 Apr '23

07 Apr '23

-- v2: wingstreamer: Create extra decodebin to decode compressed stream. winegstreamer: Implement wg_format_from_caps_video_wmv. https://gitlab.winehq.org/wine/wine/-/merge_requests/2546

3 14

[PATCH 0/2] MR2604: light.msstyles: Use border fill background for progress parts.
by Zhiyi Zhang (＠zhiyi) 07 Apr '23

07 Apr '23

These parts only contain simple images that can be achieved with border fill backgrounds as well. So visually, this change is a no-op. The reason for using image file backgrounds is that I tend to use the same background type as the theme files for Windows. However, drawing border fill background is much more efficient. Pro Evolution Soccer 2008 demo is buggy and generates ~570,000 WM_PAINT messages for the progress control. On Windows, it's ~1,140,000 WM_PAINT messages. DrawThemeBackground() on Wine is 10x more expensive than that of Windows and I found little room for optimization. 60% of the time in DrawThemeBackground() is spend for CreateCompatibleDC() and other 30% for actually drawing. So I decided to change light.msstyles instead. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54728 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2604

2 2

[PATCH v2 0/7] MR2535: wined3d: Recreate swapchain textures in wined3d_swapchain_resize_buffers().
by Zebediah Figura (＠zfigura) 07 Apr '23

07 Apr '23

Stop changing their attributes in place. This is complex, somewhat brittle, and currently broken for the Vulkan backend. Restrict wined3d_texture_update_desc() to changing user memory and pitch. -- v2: wined3d: Remove no longer used arguments from wined3d_texture_update_desc(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2535

3 12

[PATCH v2 0/1] MR2603: winecoreaudio: Move timer logic to unixlib, matching other drivers.
by Davide Beatrici (＠davidebeatrici) 07 Apr '23

07 Apr '23

-- v2: winecoreaudio: Move timer logic to unixlib, matching other drivers. https://gitlab.winehq.org/wine/wine/-/merge_requests/2603

2 1

[PATCH 0/1] MR2603: winecoreaudio: Move timer logic to unixlib, matching other drivers.
by Davide Beatrici (＠davidebeatrici) 06 Apr '23

06 Apr '23

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

2 2

[PATCH 0/5] MR153: hlsl: Return hlsl_ir_node pointers from instruction constructors, part 1.
by Zebediah Figura (＠zfigura) 06 Apr '23

06 Apr '23

The motivation for this is twofold. Firstly, this makes code a little nicer to read, by virtue of removing a ubiquitous &(...)->node. Secondly, and more importantly, this allows for the possibility of constructors returning a different instruction type than intended. The ultimate goal here is to return a preallocated "error" instruction when allocation fails, instead of returning NULL and propagating out-of-memory handling to the caller. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/153

2 5

[PATCH v3 0/6] MR2577: d3dcompiler: Use the vkd3d-shader DXBC API.
by Henri Verbeet (＠hverbeet) 06 Apr '23

06 Apr '23

The main advantage is that this way we're getting valid DXBC checksums for DXBC blobs generated by d3dcompiler. See also https://bugs.winehq.org/show_bug.cgi?id=54464. -- v3: d3dcompiler: Use vkd3d_shader_parse_dxbc() in d3dcompiler_shader_reflection_init(). d3dcompiler: Use vkd3d_shader_parse_dxbc() in d3dcompiler_strip_shader(). d3dcompiler: Use vkd3d_shader_parse_dxbc() in d3dcompiler_get_blob_part(). d3dcompiler: Use vkd3d_shader_serialize_dxbc() in d3dcompiler_strip_shader(). d3dcompiler: Use vkd3d_shader_serialize_dxbc() in d3dcompiler_get_blob_part(). d3dcompiler: Store DXBC sections as vkd3d_shader_dxbc_section_desc structures. https://gitlab.winehq.org/wine/wine/-/merge_requests/2577

3 11

Re: [PATCH v2 0/1] MR2580: psapi: Test FS redirection wrt. EnumProcessModulesEx. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v8 0/3] MR2449: win32u: Add a few device GPU properties. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v5 0/3] MR2593: winex11.drv: UpdateDisplayDevice regression fixes - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/12] MR2601: msvcrt: Use more functions from the bundled musl library. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v3 0/1] MR2599: dinput/tests: Mark some tests as flaky to workaround fvwm bug. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/28] MR2595: include: Add windows.ui.composition.idl file. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/1] MR2597: advapi32: Print ReportEvent() messages one line at a time. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/1] MR2594: cryptowinrt/tests: Remove racey refcount test. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/3] MR2592: gdi32: Support DIB_PAL_INDICES in SetDIBits() - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/2] MR151: vkd3d-shader/hlsl: Always align section sizes. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/2] MR149: Add const to a few variables. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/4] MR147: vkd3d-shader: Refactor SPIR-V compilation a bit. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/1] MR145: vkd3d-shader/hlsl: Treat half as float for casts. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v2 0/1] MR139: vkd3d-shader/hlsl: Add support for ternary operator. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

Re: [PATCH v5 0/5] MR2555: Draft: ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID (#18889)
by Nikolay Sivov (＠nsivov) 06 Apr '23

06 Apr '23

As I recall, for original fix to accept a range of resource IDs the question was how are those different from each other, meaning if there are multiple resources, when one should be used but not another. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2555#note_29222

1 0

Re: [PATCH v2 0/3] MR138: hlsl: Introduce some hlsl_block helpers. - approved
by Alexandre Julliard (＠julliard) 06 Apr '23

06 Apr '23

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

1 0

[PATCH v4 0/4] MR2159: winegstreamer: Stride and RGB formats, part 2/2.
by Zebediah Figura (＠zfigura) 06 Apr '23

06 Apr '23

-- v4: https://gitlab.winehq.org/wine/wine/-/merge_requests/2159

3 8

[PATCH v4 0/4] MR2587: Support MF DXGI device manager in h264 decoder
by Paul Gofman (＠gofman) 06 Apr '23

06 Apr '23

The last patch is a huge optimization to what is done in patch 2. Without that the sample is first copied from GPU to CPU each time wg_transform_read_mf() locks the buffer (allocating extra linear buffer on the way) and then copies the data back to GPU. That happens even if there is no sample available from wg_transform. With the last patch there is just one memory copy to the (write-only) locked DXGI surface buffer. And CPU to GPU texture transfer (which would be there anyway in most cases on software path as most of the apps are going to get the image to GPU anyway). In principle we could also skip the explicit staging texture and use _UpdateSubresource instead directly from h264 decoder, but this is currently not supported in wined3d for chroma formats and the overall difference between _UpdateSubresource and explicit mapped staging texture is not that great probably. -- v4: winegstreamer: Pass temporary sample to wg_transform_read_mf() in h264 decoder. https://gitlab.winehq.org/wine/wine/-/merge_requests/2587

4 7

[PATCH 0/1] MR2602: mfplat: Fix returned buffer length in dxgi_surface_buffer_lock().
by Paul Gofman (＠gofman) 06 Apr '23

06 Apr '23

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

4 3

[PATCH v2 0/1] MR2602: mfplat: Fix returned buffer length in dxgi_surface_buffer_lock().
by Paul Gofman (＠gofman) 06 Apr '23

06 Apr '23

-- v2: mfplat: Fix returned buffer length in dxgi_surface_buffer_lock(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2602

3 3

[PATCH v3 0/4] MR2587: Support MF DXGI device manager in h264 decoder
by Paul Gofman (＠gofman) 06 Apr '23

06 Apr '23

The last patch is a huge optimization to what is done in patch 2. Without that the sample is first copied from GPU to CPU each time wg_transform_read_mf() locks the buffer (allocating extra linear buffer on the way) and then copies the data back to GPU. That happens even if there is no sample available from wg_transform. With the last patch there is just one memory copy to the (write-only) locked DXGI surface buffer. And CPU to GPU texture transfer (which would be there anyway in most cases on software path as most of the apps are going to get the image to GPU anyway). In principle we could also skip the explicit staging texture and use _UpdateSubresource instead directly from h264 decoder, but this is currently not supported in wined3d for chroma formats and the overall difference between _UpdateSubresource and explicit mapped staging texture is not that great probably. -- v3: winegstreamer: Pass temporary sample to wg_transform_read_mf() in h264 decoder. winegstreamer: Provide samples if DXGI device manager is set in h264 decoder. winegstreamer: Process MFT_MESSAGE_SET_D3D_MANAGER in h264 decoder. https://gitlab.winehq.org/wine/wine/-/merge_requests/2587

4 7

[PATCH v3 0/5] MR2159: winegstreamer: Stride and RGB formats, part 2/2.
by Zebediah Figura (＠zfigura) 06 Apr '23

06 Apr '23

-- v3: winegstreamer: Output BGRx video from the media source. winegstreamer: Move flipping based on RGB to the frontends. winegstreamer: Translate the MF_MT_DEFAULT_STRIDE attribute to flipped video in mf_media_type_to_wg_format(). winegstreamer: Set the MF_MT_DEFAULT_STRIDE attribute in mf_media_type_from_wg_format(). winegstreamer: Initialize media source video types from a wg_video_format array. https://gitlab.winehq.org/wine/wine/-/merge_requests/2159

5 21

[PATCH 0/2] MR151: vkd3d-shader/hlsl: Always align section sizes.
by Zebediah Figura (＠zfigura) 06 Apr '23

06 Apr '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/151

3 3

[PATCH 0/2] MR149: Add const to a few variables.
by Zebediah Figura (＠zfigura) 06 Apr '23

06 Apr '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/149

5 5

[PATCH 0/4] MR147: vkd3d-shader: Refactor SPIR-V compilation a bit.
by Zebediah Figura (＠zfigura) 06 Apr '23

06 Apr '23

The idea here is to eventually use vkd3d_shader_parser_compile() for d3dbc. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/147

3 5

[PATCH 0/1] MR145: vkd3d-shader/hlsl: Treat half as float for casts.
by Nikolay Sivov (＠nsivov) 06 Apr '23

06 Apr '23

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/145

6 5

2025

2024

2023

2022

wine-gitlab