May 2023 - wine-gitlab

[PATCH v3 0/1] MR2773: include: Add xamlom.idl file.
by Biswapriyo Nath (＠Biswa96) 06 Jun '23

06 Jun '23

-- v3: include: Add xamlom.idl file. https://gitlab.winehq.org/wine/wine/-/merge_requests/2773

3 8

[PATCH v3 0/2] MR2883: evr: Respect RGB format stride in GetCurrentImage.
by Rémi Bernon (＠rbernon) 06 Jun '23

06 Jun '23

This fixes some upside-down videos in Secret of Mana. The game plays a NV12 video using MF session and EVR, then calls GetCurrentImage to get the frame RGB data and display it itself. -- v3: evr: Respect RGB format stride in GetCurrentImage. evr/tests: Test IMFVideoDisplayControl_GetCurrentImage orientation. https://gitlab.winehq.org/wine/wine/-/merge_requests/2883

3 5

[PATCH 0/2] MR199: Draft: tests: Make ddxddy.shader_test pass for different GPUs.
by Francisco Casas (＠fcasas) 05 Jun '23

05 Jun '23

On my Nvidia GeForce GTX 1050 Ti this test is not passing because of considerably different numeric results. As Giovanni pointed out, this is because my GPU uses the fine derivate and not the coarse derivate to implement ddx() and ddy(). Testing both ddx_coarse()|ddy_coarse() and ddx_fine()|ddy_fine() on the WARP driver shows that both these derivates are the same in coordinates where both X and Y are even, i.e. the first pixel of each 2x2 quad. So the test was modified to only probe on these coordinates. The new expected values were obtained from running the test using the WARP driver, and ulps adjusted for my GPU. However, this MR is marked as a draft because I would like to know if the test passes on other GPUs. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/199

3 6

[PATCH 0/2] MR219: vkd3d-shader: Implement text2Dproj().
by Nikolay Sivov (＠nsivov) 03 Jun '23

03 Jun '23

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

4 16

[PATCH 0/4] MR2931: uiautomationcore: Introduce helper function source file and more provider event adviser support.
by Connor McAdams (＠cmcadams) 02 Jun '23

02 Jun '23

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

3 5

[PATCH v4 0/5] MR207: vkd3d-shader/hlsl: Support non-constant offset dereferences, part 1
by Francisco Casas (＠fcasas) 02 Jun '23

02 Jun '23

Indexing with non-constants offsets requires relative addressing in SM4. In assembly, this is written like in the following example: ``` x1[r1.x + 3] ``` The first part of this patch series only includes support for indexing vectors with non-constant indexes. Following patches in https://gitlab.winehq.org/fcasas/vkd3d/-/commits/nonconst-offsets-3. --- Non-constant indexing of vectors cannot be implemented with relative addressing in SM4 because this indexation cannot be performed at the level of register-components, only whole registers. Mathematical operations must be used instead. For floats, the native compiler seems to index an identity matrix, to get the i-th column, and then proceedes to compute the dot product between that column and the vector. For ints, bit operations seem to be performed. While probably less efficient, this implementation complies with the type-checking at the IR level and when writing bytecode. -- v4: vkd3d-shader/hlsl: Support non-constant vector indexing. vkd3d-shader/hlsl: Lower dot for non-float types. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/207

3 6

[PATCH 0/6] MR2930: dxgi: Refactor D3D12 swapchain (first part)
by Giovanni Mascellani (＠giomasce) 02 Jun '23

02 Jun '23

The D3D12 swapchain code is currently quite messy, probably because it was originally designed around the direct usage of the Vulkan swapchain images, then the support for user buffers was added, and the original design was later phased out. Currently the internal state can be divided in two different sets of objects: the "D3D12 side", which is visible to the `IDXGISwapChain` client and must be preserved at all times (except on the client's request, i.e., when `UpdateBuffers()` is called) and the "Vulkan side" which is private and can be destroyed and recreated more or less transparently (in case the Vulkan swapchain goes out of date or some settings are updated). This MR begins the process of de-intertwining the helpers that act on one or the other sides, so that the structure of the code is made clearer. The full patch set is at https://gitlab.winehq.org/giomasce/wine/-/commits/chianti. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2930

3 7

[PATCH v2 0/5] MR2944: winewayland.drv: First window contents on screen
by Alexandros Frantzis (＠afrantzis) 02 Jun '23

02 Jun '23

The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps: 1. Associate a window with a Wayland surface and give it the `xdg_toplevel` role, so that the compositor can display it. We also have to implement the required initial `xdg_surface` configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2). 2. Implement the `window_surface` interface for the Wayland driver. For now we provide a simple (and suboptimal) `window_surface_flush` implementation: for each flush we create a new `wl_shm` buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the `window_surface` to minimize copying of data from the `window_surface` to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads. With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy `notepad` in all its blinking-cursor glory. Thanks! -- v2: winewayland.drv: Implement a simple window_surface flush. https://gitlab.winehq.org/wine/wine/-/merge_requests/2944

3 20

[PATCH 0/7] MR2942: jscript: Misc fixes and improvements.
by Gabriel Ivăncescu (＠insn) 02 Jun '23

02 Jun '23

Some of these fixes are subtle (like the first patch) and very annoying to debug. Although the first patch looks like a hack, surprisingly, it's how the spec itself says it is! It's not even an IE quirk, but a special case in the spec. For example, the variable name (which holds the builtin eval func) **does** matter: if it's called something other than 'eval', it gets treated differently (as if indirect), and this is verified by the tests + the spec's wording (so Microsoft's implementation follows it). Most of the patches other than the first 2 are pretty small so they're in same MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2942

3 15

[PATCH v3 0/2] MR2866: server: Update parent window region when exposing previously invisible window. (#54949)
by Jinoh Kang (＠iamahuman) 02 Jun '23

02 Jun '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54949 -- v3: server: Update parent window region when exposing previously invisible window. https://gitlab.winehq.org/wine/wine/-/merge_requests/2866

4 5

2025

2024

2023

2022

wine-gitlab May 2023