- Wine-GitLab - list.winehq.org

[PATCH v5 0/6] MR2712: winewayland.drv: part 3: Handle dynamic wl_output events
by Alexandros Frantzis (＠afrantzis) May 23, 2023

May 23, 2023

This MR introduces the driver mechanisms to handle dynamic events from the Wayland compositor, using wl_output events as the guiding use case (i.e., we want to update the win32u display settings when the host settings change). In this design we create a dedicated thread to read and dispatch Wayland events received from the compositor. If a Wayland event handler wants some code to be run in the context of a particular HWND's thread, it can add an internal event to a custom queue we have for each (GUI enabled) thread. The ProcessEvents driver callback processes internal events from that queue. In order to wake up waiting threads we use a pipe to notify about new internal events, with the read end acting as the thread's host queue fd. This is similar to how winemac.drv works. We use the aforementioned mechanisms to queue win32u display device updates to the desktop window thread. Since there are many pieces that need to fall into place, this MR gradually reaches the final design: 1. We first introduce the dedicated read/dispatch thread and handle events (and also display device updates if in the desktop process) in that thread. 2. We ensure access to Wayland output information is thread-safe and consistent (since in step 3 we will need to access it from a different thread). 3. We finally introduce per-thread internal event queues and, if we are in the desktop process, queue the display device update to the desktop window thread internal event queue. Note that the main portion of the wl_output event code is still handled in the dedicated read/dispatch thread. -- v5: winewayland.drv: Update desktop window size on display changes. winewayland.drv: Update display devices from the desktop window thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/2712

3 10

[PATCH 0/4] MR2884: uiautomationcore: Add support for creating/destroying HUIAEVENTs.
by Connor McAdams (＠cmcadams) May 23, 2023

May 23, 2023

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

3 5

Re: [PATCH v4 0/1] MR1919: winex11.drv: Fix compilation error: variable set but not used [-Werror=unused-but-set-variable]. - closed
by Bartosz Kosiorek (＠gang65) May 23, 2023

May 23, 2023

This merge request was closed by Bartosz Kosiorek. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1919

1 0

[PATCH v7 0/5] MR2555: ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID (#18889)
by Jinoh Kang (＠iamahuman) May 23, 2023

May 23, 2023

>From Microsoft 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 `0x0004` 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-… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=18889 -- v7: ntdll: Don't hard-code DLL manifest resource ID when looking up dependency assembly. kernel32/tests: Test loading assembly manifest resource inside dependencies. ntdll: Move ACTCTX lpResourceName validation to RtlCreateActivationContext. kernel32/tests: Test setting lpResourceName to NULL for CreateActCtxW. kernel32/tests: Remove test for ACTCTX_FLAG_HMODULE_VALID with hModule = NULL case. https://gitlab.winehq.org/wine/wine/-/merge_requests/2555

2 5

[PATCH v10 0/5] MR44: vkd3d-shader/dxil: Read and validate DXIL bitcode blocks.
by Conor McCarthy (＠cmccarthy) May 23, 2023

May 23, 2023

Block records are not processed; only the bitcode is validated. -- v10: vkd3d-shader/dxil: Read and validate global abbreviated operands. vkd3d-shader/dxil: Read and validate local abbreviated operands. vkd3d-compiler: Introduce dxbc-dxil and dxbc-auto source types. vkd3d-shader/dxbc: Introduce an option to autodetect the DXBC source type. vkd3d-shader/dxil: Read and validate DXIL bitcode unabbreviated blocks. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/44

3 7

[PATCH v10 0/5] MR2864: gdiplus: Improve performance of GdipDrawImagePointsRect
by Bartosz Kosiorek (＠gang65) May 23, 2023

May 23, 2023

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947 Improve performance of GdipDrawImagePointsRect by: 1. avoiding multiplication and use addition where it is possible. 2. avoid calculating `GdipInvertMatrix` if it is not used. 3. avoid not needed TransformMatrixPoints I divided MR to several commits, to better undestand what is going on. Application for testing (it needs logo.jpg file): [gdiplusdrawimagepoints.exe](/uploads/545ff7d8ab1d60386366f64999346825/gdiplusdrawimagepoints.exe) -- v10: test: try to fix failing test on 32 bit https://gitlab.winehq.org/wine/wine/-/merge_requests/2864

2 5

[PATCH v12 0/2] MR184: vkd3d-shader/hlsl: Add support for SampleGrad() method
by Ethan Lee (＠flibitijibibo) May 23, 2023

May 23, 2023

~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~ ~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~ ``` vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed. ``` ~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed! -- v12: vkd3d-shader/hlsl: Add support for SampleGrad() method tests: Add a test for SampleGrad() method https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184

3 4

[PATCH v4 0/6] MR2712: winewayland.drv: part 3: Handle dynamic wl_output events
by Alexandros Frantzis (＠afrantzis) May 23, 2023

May 23, 2023

This MR introduces the driver mechanisms to handle dynamic events from the Wayland compositor, using wl_output events as the guiding use case (i.e., we want to update the win32u display settings when the host settings change). In this design we create a dedicated thread to read and dispatch Wayland events received from the compositor. If a Wayland event handler wants some code to be run in the context of a particular HWND's thread, it can add an internal event to a custom queue we have for each (GUI enabled) thread. The ProcessEvents driver callback processes internal events from that queue. In order to wake up waiting threads we use a pipe to notify about new internal events, with the read end acting as the thread's host queue fd. This is similar to how winemac.drv works. We use the aforementioned mechanisms to queue win32u display device updates to the desktop window thread. Since there are many pieces that need to fall into place, this MR gradually reaches the final design: 1. We first introduce the dedicated read/dispatch thread and handle events (and also display device updates if in the desktop process) in that thread. 2. We ensure access to Wayland output information is thread-safe and consistent (since in step 3 we will need to access it from a different thread). 3. We finally introduce per-thread internal event queues and, if we are in the desktop process, queue the display device update to the desktop window thread internal event queue. Note that the main portion of the wl_output event code is still handled in the dedicated read/dispatch thread. -- v4: winewayland.drv: Update desktop window size on display changes. winewayland.drv: Update display devices from the desktop window thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/2712

3 9

[PATCH v3 0/1] MR2869: winepulse: Implement is_format_supported in unixlib.
by Davide Beatrici (＠davidebeatrici) May 23, 2023

May 23, 2023

-- v3: winepulse: Implement is_format_supported in unixlib. https://gitlab.winehq.org/wine/wine/-/merge_requests/2869

3 3

[PATCH 0/7] MR2882: d2d: Improve GDI interop support
by Nikolay Sivov (＠nsivov) May 23, 2023

May 23, 2023

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

2 7