- wine-gitlab - winehq.org

Re: [PATCH v3 0/6] MR3165: dxgi: Introduce a worker thread for each D3D12 swapchain (first part). - approved
by Jan Sikorski (＠jsikorski) 04 Jul '23

04 Jul '23

This merge request was approved by Jan Sikorski. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3165

1 0

[PATCH v13 0/2] MR2778: mfmediaengine: Add support for video effects.
by Bernhard Kölbl (＠besentv) 04 Jul '23

04 Jul '23

The test has a little inspiration from the SDK samples. -- v13: mfmediaengine: Add support for inserting video effects. mfmediaengine/tests: Add tests for video effects. https://gitlab.winehq.org/wine/wine/-/merge_requests/2778

2 4

[PATCH v5 0/8] MR3218: wine{alsa,coreaudio,oss,pulse}: Move session_init_vols, create_session into mmdevapi.
by Davide Beatrici (＠davidebeatrici) 04 Jul '23

04 Jul '23

-- v5: https://gitlab.winehq.org/wine/wine/-/merge_requests/3218

3 9

[PATCH 0/4] MR3234: winewayland.drv: part 5: window_surface flush optimizations
by Alexandros Frantzis (＠afrantzis) 04 Jul '23

04 Jul '23

This MR optimizes and makes correctness improvements to the window_surface flush implementation: 1. Implement a buffer queue to avoid constantly allocating new buffers. 2. Take into account the bounds of the window_surface flush and track per-buffer damage to reduce copying from the window_surface. 3. Copy from the window_surface only pixel data that lies within the flushed bounds. Maintain the latest contents for pixels outside these bounds, by copying them from the latest valid buffer. 4. Communicate damaged surface regions to the compositor to allow it to perform more efficient pixel data transfers (e.g., texture uploads). Thanks! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3234

2 4

[PATCH v4 0/1] MR3114: comctl32: Make the correct linkid from fun SYSLINK_LinkAtPt.
by Zhao Yi (＠Zhaoyi) 04 Jul '23

04 Jul '23

Add a check condition for whether the type is slLink. Signed-off-by: Zhaoyi <zhaoyi(a)uniontech.com> -- v4: comctl32: Make the correct linkid from fun SYSLINK_LinkAtPt. https://gitlab.winehq.org/wine/wine/-/merge_requests/3114

3 3

[PATCH v6 0/6] MR3220: windows.devices.bluetooth: Implement IBluetoothAdapterStatics::GetDeviceSelector().
by Mohamad Al-Jaf (＠maljaf) 04 Jul '23

04 Jul '23

Needed for Revo Scan 5. -- v6: windows.devices.bluetooth: Implement IBluetoothAdapterStatics::GetDeviceSelector(). https://gitlab.winehq.org/wine/wine/-/merge_requests/3220

2 7

[PATCH v5 0/6] MR3220: windows.devices.bluetooth: Partially implement IBluetoothAdapterStatics::GetDeviceSelector().
by Mohamad Al-Jaf (＠maljaf) 04 Jul '23

04 Jul '23

Needed for Revo Scan 5. -- v5: windows.devices.bluetooth: Partially implement IBluetoothAdapterStatics::GetDeviceSelector(). windows.devices.bluetooth/tests: Add IBluetoothAdapterStatics::GetDeviceSelector() tests. windows.devices.bluetooth: Add IBluetoothAdapterStatics stub interface. windows.devices.bluetooth: Add stub DLL. include: Add windows.devices.bluetooth.idl file. https://gitlab.winehq.org/wine/wine/-/merge_requests/3220

3 10

[PATCH 0/4] MR263: vkd3d-shader/spirv: Refactor the type system.
by Conor McCarthy (＠cmccarthy) 04 Jul '23

04 Jul '23

Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type. Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263

2 4

[PATCH v3 0/1] MR3114: comctl32: Make the correct linkid from fun SYSLINK_LinkAtPt.
by Zhao Yi (＠Zhaoyi) 04 Jul '23

04 Jul '23

Add a check condition for whether the type is slLink. Signed-off-by: Zhaoyi <zhaoyi(a)uniontech.com> -- v3: comctl32: Make the correct linkid from fun SYSLINK_LinkAtPt. https://gitlab.winehq.org/wine/wine/-/merge_requests/3114

3 4

Re: [PATCH v3 0/6] MR3165: dxgi: Introduce a worker thread for each D3D12 swapchain (first part).
by Zhiyi Zhang (＠zhiyi) 04 Jul '23

04 Jul '23

On Mon Jul 3 18:50:55 2023 +0000, Zebediah Figura wrote: > > With this implementation it should be relatively easy to present with > whatever API is available, though I don't really know how the options > you mention work, so maybe there is some additional complexity I'm not > aware of. > Sounds great :-) > The "fullscreen window styles" problem (and one of the older d3d > contributors can correct me on this) is basically that some applications > use ddraw (and other versions?) to present to a fullscreen window, > expecting the presented area to cover the whole screen, but wgl (and > Vulkan) swapchains only present to the client rect. We currently get > around this by changing the window styles to remove all the nonclient > decorations, but that breaks some applications too. What we want is a > way to present to the actual window, and part of the idea is that using > D3DKMTPresent() is the architecturally correct way to do this. > I don't quite know what the concerns are for dcomposition either. Zhiyi > was looking at that and ran into a wall, but he probably can at least > describe the problem in greater detail. > There are also some thoughts about using D3DKMTPresent() to deal more > efficiently with some cases where we currently have to do a GDI blit. > I'm fuzzy on these details though; again Henri can explain it better. What D3DKMTPresent() does is that it sends a command to the compositor/DWM to display contents. Since DWM is responsible for drawing the window decoration, it allows the nonclient decorations to be overwritten without affecting window styles. The complexity here is that we don't have a DWM. Implementing a DWM and making it work with the host WM is not trivial, if not impossible. Also, the window decoration is currently handled by the host system, for example, Mutter. Having D3DKMTPresent() is certainly more architecturally correct. That way, DWM can intercept these surfaces and do the composition without tearing and not worry about the surface lifetime. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_37742

1 0

2025

2024

2023

2022

wine-gitlab