Normalise the incoming vkd3d_shader_instruction IR to the shader model 6 pattern where only one patch constant function is emitted. This allows generation of a single patch constant function in SPIR-V.
--
v14: vkd3d-shader/spirv: Declare the phase SPIR-V function in spirv_compiler_enter_shader_phase().
vkd3d-shader/spirv: Remove the hull shader phase array.
vkd3d-shader/trace: Trace the normalised instruction array after tracing the input.
vkd3d-shader/ir: Merge all shader IR fork and join phases into a single phase.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/84
Without this fix, the font cache was filling up with lots of duplicate entries,
and getting cache misses, thereby causing font-intensive applications
to be very slow (e.g. AvalonEdit) .
This fix provides 30x speed increase when processing glyphs.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2307
Support manually packing constant buffer elements through the `packoffset(·)` syntax.
Support not included yet for simultaneously having semantics, `register(·)`, and `packoffset(·)`, for abnormalities such as:
```hlsl
Texture2D tex;
cbuffer buff
{
float4 a : packoffset(c0);
sampler sam : packoffset(c0) : register(s1) : SEMANTIC;
}
float4 main() : sv_target
{
return tex.Sample(sam, float2(0, 0)) + a;
}
```
but this motivated the addition of the `hlsl_ir_var.offset_reservation` field instead of reusing `hlsl_ir_var.reg_reservation`.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/106
This patch addresses an issue in Second Life and potentially other
multi-threaded applications which process WM_KEYDOWN in one thread
and then verify that the key is "still down" with GetAsyncKeyState
from another thread. Wine uses a per-thread key cache, resulting
in inconsistent views of key status. Caches are now invalidated
when an input event is injected by the driver or via SendInput.
--
v5: win32u: invalidate all cached keys after input
https://gitlab.winehq.org/wine/wine/-/merge_requests/2153
This patch addresses an issue in Second Life and potentially other
multi-threaded applications which process WM_KEYDOWN in one thread
and then verify that the key is "still down" with GetAsyncKeyState
from another thread. Wine uses a per-thread key cache, resulting
in inconsistent views of key status. Caches are now invalidated
when an input event is injected by the driver or via SendInput.
--
v4: win32u: invalidate all cached keys after input
https://gitlab.winehq.org/wine/wine/-/merge_requests/2153
This patch addresses an issue in Second Life and potentially other
multi-threaded applications which process WM_KEYDOWN in one thread
and then verify that the key is "still down" with GetAsyncKeyState
from another thread. Wine uses a per-thread key cache, resulting
in inconsistent views of key status. Caches are now invalidated
when an input event is injected by the driver or via SendInput.
--
v2: win32u: invalidate all cached keys after input
https://gitlab.winehq.org/wine/wine/-/merge_requests/2153
ZusiDisplay sometimes loads the same font file into two different
PrivateFontCollections using two threads, so there is a race condition
when the file is opened without the FILE_SHARE_READ sharing mode. The
second call to GdipPrivateAddFontFile() might fail if the first one
hasn't closed the file handle yet.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2302
On Tue Feb 28 14:37:01 2023 +0000, Henri Verbeet wrote:
> It's probably worth pointing out that this has quite some potential for
> causing regressions in performance. swapchain_blit_gdi() is not fast,
> and ideally we'd work on reducing the number of cases where it's needed.
!2217 should avoid most of those cases I think, it probably makes sense to wait for that one to go in first.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_25759
--
v4: dxgi: Reset the back buffer index to zero on ResizeBuffers().
dxgi/tests: Test that ResizeBuffers() resets the back buffer index to zero.
dxgi: Always assume that a D3D12 swapchain always uses user images.
dxgi: Immediately error out when creating a D3D12 swapchain on a non-immediate queue.
dxgi/tests: Test that D3D12 swapchains can only be created on direct command queues.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2296
On Tue Feb 28 10:26:07 2023 +0000, Matteo Bruni wrote:
> I guess we could add a WARN("Using pixel format %u already set on DC
> %p.\n", current, dc); or something.
Actually the WARN() in wined3d_context_gl_set_gl_context() is probably enough already, so disregard this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_25755
Normalise the incoming vkd3d_shader_instruction IR to the shader model 6 pattern where only one patch constant function is emitted. This allows generation of a single patch constant function in SPIR-V.
--
v13: vkd3d-shader/spirv: Declare the phase SPIR-V function in spirv_compiler_enter_shader_phase().
vkd3d-shader/spirv: Remove the hull shader phase array.
vkd3d-shader/trace: Trace the normalised instruction array after tracing the input.
vkd3d-shader/ir: Merge all shader IR fork and join phases into a single phase.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/84
--
v5: vkd3d: Do not keep the CS queue locked while processing it.
vkd3d: Always enqueue CS operations, even if they can be executed right away.
vkd3d: Hold the queue mutex when adding the queue to a blocked list.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/94
Otherwise it's not clear which clauses in vkd3d_shader_compile() really
apply to other functions. For example, many of the functions currently
refering to vkd3d_shader_compile() don't even take a vkd3d_shader_compile_info
parameter.
--
v3: vkd3d-shader: Make documentation for "messages" parameters self contained.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/110
--
v3: vkd3d-shader/hlsl: Get rid of the check_invalid_matrix_modifiers() helper.
vkd3d-shader/hlsl: Apply latent majority modifiers to typedefs as well.
vkd3d-shader/hlsl: Do not set an initial latent matrix majority.
vkd3d-shader/hlsl: Store the matrix majority as a type modifiers bitmask.
vkd3d-shader/hlsl: Apply latent type modifiers to matrix array typedefs.
tests: Add more tests for pack_matrix pragmas.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/102
--
v3: dxgi: Reset the back buffer index to zero on ResizeBuffers().
dxgi/tests: Test that ResizeBuffers() resets the back buffer index to zero.
dxgi: Always assume that a D3D12 swapchain always uses user images.
dxgi: Immediately error out when creating a D3D12 swapchain on a non-immediate queue.
dxgi/tests: Test that D3D12 swapchains can only be created on direct command queues.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2296
On Tue Feb 28 12:09:51 2023 +0000, Brendan Shanks wrote:
> Thanks for this, I hadn't realized `IOPMCopyBatteryInfo` was so deprecated.
> Looking at [Chromium's use of
> `IOPSCopyPowerSources`](https://source.chromium.org/chromium/chromium/src/+/main:services/device/battery/battery_status_manager_mac.cc;drc=098756533733ea50b2dcb1c40d9a9e18d49febbe;l=127),
> they first check that the source is present and internal, which seems
> like a good idea.
I changed it so it it does similar checks to Chromium and uses the first power source that works (and removed the internal battery check on kIOPSTypeKey since that is always true in that case already)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283#note_25736
On Mon Feb 27 20:50:31 2023 +0000, Brendan Shanks wrote:
> The documentation for all these keys says that the type is
> `kCFNumberIntType` (equivalent to SInt32, but it would be better to use
> the documented type)
Thanks, should be fixed now!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283#note_25735
On Mon Feb 27 20:50:31 2023 +0000, Brendan Shanks wrote:
> You can `CFRelease(blob)` at this point, and then remove all the calls
> from later in the function
I believe it is still needed for `IOPSGetPowerSourceDescription`, but I released after it is no longer being called
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283#note_25734
The current implementation based on `IOPMCopyBatteryInfo` does not work (macOS 13.2, M2 Max, returns `kIOReturnUnsupported`) and is not recommended/supported by Apple:
> WARNING! IOPMCoyBatteryInfo is unsupported on ALL Intel CPU based systems. For PPC CPU based systems, it remains not recommended. For almost all purposes, developers should use the richer IOPowerSources API (with change notifications) instead of using IOPMCopyBatteryInfo. Keys to decipher IOPMCopyBatteryInfo's return CFArray exist in IOPM.h.
--
v8: ntdll: Use IOPowerSources API to fill battery info on macOS
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283
--
v2: dxgi: Reset the back buffer index to zero on ResizeBuffers().
dxgi/tests: Test that ResizeBuffers() resets the back buffer index to zero.
dxgi: Always assume that a D3D12 swapchain always uses user images.
dxgi: Immediately error out when creating a D3D12 swapchain on a non-immediate queue.
dxgi/tests: Test that D3D12 swapchains can only be created on direct command queues.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2296
It's probably worth pointing out that this has quite some potential for causing regressions in performance. swapchain_blit_gdi() is not fast, and ideally we'd work on reducing the number of cases where it's needed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_25724
Matteo Bruni (@Mystral) commented about dlls/wined3d/context_gl.c:
> current = gl_info->gl_ops.wgl.p_wglGetPixelFormat(dc);
> if (current == format) goto success;
>
> + if (current && !private)
> + return FALSE;
I guess we could add a WARN("Using pixel format %u already set on DC %p.\n", current, dc); or something.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_25713
--
v4: vkd3d: Do not keep the CS queue locked while processing it.
vkd3d: Always enqueue CS operations, even if they can be executed right away.
vkd3d: Hold the queue mutex when adding the queue to a blocked list.
vkd3d: Mention the correct mutex in a comment.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/94
--
v2: riched20/tests: Fix the EM_GETSELTEXT tests in Hindi on Windows.
riched20/tests: EM_GETSELTEXT's wparam is not used and should be 0.
riched32/tests: EM_GETSELTEXT's wparam is not used and should be 0.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2276
Signed-off-by: Fan WenJie <fanwj(a)mail.ustc.edu.cn>
calling unix funcions from PE must via unix_call, Because must switch fs register vaule and other context on wow64 mode. Currently calling some unix functions of win32u via function pointers. The patch modify the way of calling unix functions of win32u by unix_call
--
v4: win32u: replace calling unix functions by unix_call and remove callback unix_funcs
win32u: Use syscall interface for remaining functions.
win32u: Use syscall interface for user functions.
win32u: Use syscall interface for more GDI functions.
win32u: Use syscall interface for more clipping functions.
win32u: Use syscall interface for more font functions.
win32u: Use syscall interface for more font functions.
win32u: Use syscall interface for more GDI object functions.
win32u: Use syscall interface for more DC functions.
win32u: Use syscall interface for DIB functions.
win32u: Use syscall interface for D3DKMT functions.
win32u: Use syscall interface for more bitmap functions.
win32u: Use syscall interface for bitblt functions.
win32u: Use syscall interface for more path functions.
win32u: Use syscall interface for more printer functions.
win32u: Use syscall interface for more painting functions.
win32u: Use syscall interface for more painting functions.
win32u: Use syscall interface for NtGdiOpenDCW.
gdi HACK: Disable printer drivers.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2291
The idea I have is to use this module to declare class stubs until there is a good reason to split them to dedicated modules. WinRT modules aren't usually loaded directly, and instead the registry is queried to figure which module to load for which class.
This would help avoiding unnecessary proliferation of stub WinRT modules, while at the same time allowing to factor WinRT foundation code (such as vector / async, etc...) between the modules that seem to deserve to be implemented separately.
The relevant classes could then be split out to dedicated modules on a as-needed basis, when they get fleshed out.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2298
The current implementation based on `IOPMCopyBatteryInfo` does not work (macOS 13.2, M2 Max, returns `kIOReturnUnsupported`) and is not recommended/supported by Apple:
> WARNING! IOPMCoyBatteryInfo is unsupported on ALL Intel CPU based systems. For PPC CPU based systems, it remains not recommended. For almost all purposes, developers should use the richer IOPowerSources API (with change notifications) instead of using IOPMCopyBatteryInfo. Keys to decipher IOPMCopyBatteryInfo's return CFArray exist in IOPM.h.
--
v7: ntdll: Use IOPowerSources API to fill battery info on macOS
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283
Without this patch, dp3 and dp4 map src swizzles to the dst writemask,
which is not correct.
Before b84f560bdf59c35e093e51bfdf9a166c196d3a9b, these ops worked
despite this, because the dst register had, incorrectly, the full
writemask.
To solve this problem, `write_sm1_binary_op_dot()` is introduced,
similarly to `write_sm4_binary_op_dot()`.
This was pointed out by @nsivov in https://bugs.winehq.org/show_bug.cgi?id=54522.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/107
The extension is now part of Xlib. It might be disabled through the `XKB_DISABLE=1` environment variable (https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/src/xkb/XKBUse…) but I don't see why we have to support that case.
I think assuming that it is always usable will make the keyboard code simpler, though I have no idea if it exists some environment without it nowadays. All recent desktop environment rely on Xkb to support keyboard layouts, especially when multiple layouts are configured (which are grouped four by four in a single X keyboard mapping, using Xkb groups).
--
v3: winex11: Assume that Xkb extension is available.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2297
Introduction
------------
This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know.
A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland.
Part 1
-------
This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files. Please see the individual commit message for more details.
Some questions I would appreciate some feedback on in the context of this MR:
1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland)
2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland)
Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list.
Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2275
Otherwise it's not clear which clauses in vkd3d_shader_compile() really
apply to other functions. For example, many of the functions currently
refering to vkd3d_shader_compile() don't even take a vkd3d_shader_compile_info
parameter.
--
v2: vkd3d-shader: Make documentation for "messages" parameters self contained.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/110
The extension is now part of Xlib. It might be disabled through the `XKB_DISABLE=1` environment variable (https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/src/xkb/XKBUse…) but I don't see why we have to support that case.
I think assuming that it is always usable will make the keyboard code simpler, though I have no idea if it exists some environment without it nowadays. All recent desktop environment rely on Xkb to support keyboard layouts, especially when multiple layouts are configured (which are grouped four by four in a single X keyboard mapping, using Xkb groups).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2297
--
v2: vkd3d-shader/hlsl: Get rid of the check_invalid_matrix_modifiers() helper.
vkd3d-shader/hlsl: Apply latent majority modifiers to typedefs as well.
vkd3d-shader/hlsl: Do not set an initial latent matrix majority.
vkd3d-shader/hlsl: Store the matrix majority as a type modifiers bitmask.
vkd3d-shader/hlsl: Apply latent type modifiers to matrix array typedefs.
tests: Add more tests for pack_matrix pragmas.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/102
Otherwise it's not clear which clauses in vkd3d_shader_compile() really
apply to other functions. For example, many of the functions currently
refering to vkd3d_shader_compile() don't even take a vkd3d_shader_compile_info
parameter.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/110
The extension is now part of Xlib. It might be disabled through the `XKB_DISABLE=1` environment variable (https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/src/xkb/XKBUse…) but I don't see why we have to support that case.
I think assuming that it is always usable will make the keyboard code simpler, though I have no idea if it exists some environment without it nowadays. All recent desktop environment rely on Xkb to support keyboard layouts, especially when multiple layouts are configured (which are grouped four by four in a single X keyboard mapping, using Xkb groups).
--
v2: winex11: Assume that Xkb extension is availabe.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2297
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v12: winspool: Check dmSize in IsValidDevmodeW()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v11: winspool: Check dmSize in IsValidDevmodeWw
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262