Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v10: vkd3d-shader/tpf: Initial support for writing fx_4_0/fx_4_1 binaries.
vkd3d-shader: Add separate binary target type for effects.
vkd3d-shader/hlsl: Handle effect group statement.
vkd3d-shader/hlsl: Add variables for techniques.
vkd3d-shader/hlsl: Rename rule for top-level techniques.
vkd3d-shader/hlsl: Add 'fxgroup' token.
tests: Add some tests for effects groups syntax.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/443
Implement effect related functions in Gdiplus.
This currently a WIP.
--
v5: gdiplus: Add GdipGetEffectParameters implementation.
gdiplus: Add GdipSetEffectsParameters implementation.
gdiplus: Add GdipGetEffectParameterSize implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661
When updating the foreground window, even if both the old and new active
window belong to the same non-current thread, the win32u code currently
explicitly deactivates the old window. This will cause the transient
deactivation of the foreground thread which can lead to undesirable
side-effects (e.g., some apps may minimize when they become inactive).
Until this is fixed in Wine core, use an internal driver message to
ensure that we call NtUserSetForegroundWindow from the context of
the new foreground window thread, to avoid the problematic behavior.
---
Assuming that the aforementioned NtUserSetForegroundWindow behavior is indeed incorrect, this
should ideally be addressed in win32u, perhaps along the lines of https://gitlab.winehq.org/wine/wine/-/merge_requests/4593/diffs?commit_id=f….
However, given the time of year (freeze etc), the proposed mitigation is possibly a safer choice at this point for Wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4651
Implement effect related functions in Gdiplus.
This currently a WIP.
--
v4: gdiplus: Add GdipGetEffectParameters implementation.
gdiplus: Add GdipSetEffectsParameters implementation.
gdiplus: Add GdipGetEffectParameterSize implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661
Implement effect related functions in Gdiplus.
This currently a WIP.
--
v3: gdiplus: Add GdipGetEffectParameters implementation.
gdiplus: Add GdipSetEffectsParameters implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661
If a message is removed from the queue with PeekMessage/GetMessage,
the key state should get updated before calling the WH_KEYBOARD hooks.
--
v5: win32u: Fix key state not updating before WH_KEYBOARD hook
https://gitlab.winehq.org/wine/wine/-/merge_requests/4633
While using [x64dbg](https://x64dbg.com/) I was experiencing incredibly strange issue - `int3` was swallowed and `KiUserExceptionDispatcher` was never invoked.
Turns out that x64dbg ([TitanEngine](https://github.com/x64dbg/TitanEngine/blob/x64dbg/TitanEngine/…) expects system breakpoint to be first breakpoint that will be triggered and it always swallows it (it's hardcoded no setting to change it's behavior).
That means if you have a DLL with `int3` for example
```c
LONG ExceptionHandler(EXCEPTION_POINTERS *ExceptionInfo) {
ExceptionInfo->ContextRecord->Rip++;
return EXCEPTION_CONTINUE_EXECUTION;
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
if (fdwReason == DLL_PROCESS_ATTACH)
{
AddVectoredExceptionHandler(1, ExceptionHandler);
asm("int $0x03; nop; nop;");
}
return TRUE;
}
```
That `int3` would be swallowed and `ExceptionHandler` never invoked when running under x64dbg.
Now with this MR applied it works correctly and as expected (same as on Windows).
Another interesting thing is that without this MR it wouldn't just swallow `int3` but even skip first `nop` aswell and RIP would end up on 2nd `nop`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4655
When running `wine explorer.exe /desktop=shell` as a full-screen app,
there is no obvious way to close it and return to the Linux desktop.
Remedy that problem by adding an "Exit desktop" button to the Start menu
in the same place as the "Shut Down" button on Windows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4630
This fixes the layout of the tabcontrol when a font other than the
system font is used.
--
v9: comctl32/tests: Modify test_width to try different fonts
comctl32/tests: Check size initially and after changing padding only
comctl32/tests: Fix tabcontrol tests to work with different fonts
comctl32: Use selected font to determine default min tab width
https://gitlab.winehq.org/wine/wine/-/merge_requests/4484
--
v4: vkd3d: Co-locate all descriptor-related members.
vkd3d: Rename the device mutex to pipeline_cache_mutex.
vkd3d: Write Vulkan descriptors in a worker thread.
vkd3d: Update the descriptor `next` index before getting a reference for writing.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/292
This fixes various problems I've run into while trying to use Fusion 360 in wine.
- stacking issues in unmanaged mode
- I also attempted to apply the same fix for managed mode, but it looks difficult to do this in a way that plays well with window managers; I think it's best left up to them to keep override_redirect windows at the top of the stack)
- when the window manager sets our state to withdrawn, tell the window that it's been minimized, since the semantics are very similar
- the last one is a hack because I don't really know what to do about it, when clicking on the floating popups, they gain focus, which causes wine to incorrectly make them managed and that breaks everything
--
v3: winex11: don't let captionless popups be managed
winex11: pass ICCCM withdrawn state as minimized
winex11: restack a window's owned popups above it
https://gitlab.winehq.org/wine/wine/-/merge_requests/2343
On Thu Dec 7 18:47:06 2023 +0000, Rémi Bernon wrote:
> Well, code freeze is tomorrow so I don't intend to do anything soon.
> You can submit it in a separate MR if you think it's critical for the
> well behaving of the driver, and then @julliard will decide what to do
> with it, but I would personally wait until we try to fix these
> activation issues.
Thanks. As a possibly more freeze-safe alternative, I proposed a mitigation in the driver itself https://gitlab.winehq.org/wine/wine/-/merge_requests/4651 .
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4593#note_55533
These are all the patches in this area that I think make sense at this point in the release cycle (i.e. a couple of days before code freeze...)
I originally had many more. A few are not really suitable at this time; a couple turned out to not really make a difference or generally not feeling like it would be an improvement overall. Many ended up in the way (or not in the spirit) of what we probably want to do at some point, which is grouping the whole draw state setup data together with the draw itself. Not that I could find the time to explore that yet...
--
v2: wined3d: Add a bunch of d3d_perf traces.
wined3d: Add a frametime debug channel.
wined3d: Increase WINED3D_CS_QUERY_POLL_INTERVAL to 100.
wined3d: Sleep when waiting for the CS thread.
wined3d: Do a blocking wait for CS commands even when there are active queries.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4625
> I have also seen this with KDE, and my current inclination is to say that this is a compositor problem. Looking at the logs it seems the driver is issuing the proper requests, but the cursor remains visible.
Yeah, the wayland log looks okay.
```
[ 858989.759] -> wl_pointer(a)15.set_cursor(172832, nil, 0, 0)
[ 858989.762] -> zwp_relative_pointer_manager_v1(a)10.get_relative_pointer(new id zwp_relative_pointer_v1@59, wl_pointer@15)
[ 858990.080] -> wl_compositor(a)4.create_region(new id wl_region@57)
[ 858990.083] -> wl_region(a)57.add(1280, 720, 0, 0)
[ 858990.086] -> zwp_pointer_constraints_v1(a)9.confine_pointer(new id zwp_confined_pointer_v1@49, wl_surface@3, wl_pointer@15, wl_region@57, 2)
```
this should work, there's only one pointer enter event and no leave event before. Will check why kwin refuses to hide the cursor.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4593#note_55526
If a message is removed from the queue with PeekMessage/GetMessage,
the key state should get updated before calling the WH_KEYBOARD hooks.
--
v4: winu32: Fix key state not updating before WH_KEYBOARD hook
https://gitlab.winehq.org/wine/wine/-/merge_requests/4633
I know this breaks Windows behavior but having apps print out
special debug messages to the terminal provides a good look
into the applications' development (for example I know that NFS
Underground has some "done" messages likely used for debugging).
I also don't want to keep another revert in my Wine tree just
for this one feature either so that's why I'm MR'ing this.
I considered adding a registry/winecfg entry for this behavior
but it would make this change much larger (and there's no good
place in winecfg to put this behavior in).
To enable this behavior, you can set WINEDEBUG=+unixcon variable
before launching an application.
Xkcd-Entry: https://xkcd.com/1172/
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55435
--
v3: ntdll/unix: Add an option to inherit the Unix console handle.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4566
Support for generating keys from known DH parameters is not included unfortunately because even the latest stable GnuTLS release doesn't have the necessary support. I have a patch that implements it using _gnutls_dh_generate_key() but that requires a special GnuTLS 3.8.2 build (--enable-fips140-mode). With that patch all included tests pass here.
Paul, can you take a look? I included your tests so please approve this MR if you think it's okay.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4637
Goes atop !489. The last 7 commits belong to this MR. Many of these patches are small, but the series can be split further if necessary.
--
v3: vkd3d-shader/spirv: Handle ITOI and UTOU in spirv_compiler_map_alu_instruction().
vkd3d-shader/spirv: Support UINT64 source in spirv_compiler_emit_bool_cast().
vkd3d-shader/spirv: Support 64-bit sources in spirv_compiler_emit_int_div().
vkd3d-shader/spirv: Introduce a UINT64 component type.
vkd3d-shader/spirv: Introduce a data_type_is_64_bit() helper function.
vkd3d-shader/spirv: Use data_type_is_integer() in spirv_compiler_emit_neg().
vkd3d: Pass int64 capability info to vkd3d-shader.
vkd3d-shader/spirv: Introduce a compiler feature flag for int64 capability.
tests/shader-runner: Add 64-bit bitwise tests.
tests/shader-runner: Add 64-bit arithmetic tests.
tests/shader-runner: Introduce an 'int64' requirement directive.
vkd3d-shader/spirv: Emit an error if 64-bit integers are used.
vkd3d-shader: Introduce an instruction flag to suppress masking of bitwise shift counts.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/490
--
v6: vkd3d-shader/spirv: Introduce a compiler feature flag for int64 capability.
tests/shader-runner: Add 64-bit bitwise tests.
tests/shader-runner: Add 64-bit arithmetic tests.
tests/shader-runner: Introduce a 'shader int64' requirement directive.
vkd3d-shader/spirv: Emit an error if 64-bit integers are used.
vkd3d-shader: Introduce an instruction flag to suppress masking of bitwise shift counts.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/489
This is ready for review, but may not go upstream until after the release.
--
v5: vkd3d-shader/spirv: Introduce a compiler feature flag for int64 capability.
tests/shader-runner: Add 64-bit bitwise tests.
tests/shader-runner: Add 64-bit arithmetic tests.
tests/shader-runner: Introduce a 'shader int64' requirement directive.
vkd3d-shader/spirv: Emit an error if 64-bit integers are used.
vkd3d-shader/dxil: Introduce an instruction flag to suppress masking of bitwise shift counts.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/489
C99 checks depend on stddef.h and stdarg.h. Those headers are usually shipped with
compilers (and another copy of them as part of mingw-w64 for targets that use it),
but some providers skip them. We use our own version during the build anyway, so
we may use them for configure checks as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4642
Just some tiny fixes I found while creating !4449. No functional changes intended.
Wine's code review process, and commit history, is a lot more comprehensive than anything else I've seen. This means I can't just write code, submit patch, and call it a day; but it also means the codebase is clean and easy to work with, so fixing bugs and missing pieces is relatively straightforward. While this does increase the total time needed on my side (especially splitting commits), it's easy (though somewhat boring) work, so in total, it's a win. And splitting makes it easier for the maintainers - you have more to do than me, so if it saves your time at the expense of mine, I have no right to complain.
Thank you for your patience with my prior MRs. 8.2/10 would contribute again (I've seen a few other games with broken videos that I suspect have still-unfixed causes)
--
v2: winegstreamer: Delete duplicate WMT_ON check.
winegstreamer: Fix a memory leak in stream_props_GetMediaType.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4609
For h264 byte-stream format, we should set "streamheader".
"codec_data" is for avc.
We also set timestamp of the buffer to 0 because
mp4mux will be error if the PTS is none.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4600
This may be a matter of taste. I personally prefer to give variables a restricted scope, as I find this aids clarity, and -Wshadow can help prevent mistakes from this.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/506
--
v2: vkd3d-shader/dxil: No longer synthesize DCL instructions.
vkd3d-shader/spirv: Declare I/O registers from the signature.
vkd3d-shader/dxil: Map SEMANTIC_KIND_TARGET to VKD3D_SHADER_SV_TARGET.
vkd3d-shader/tpf: Do not uninvert used masks for domain shader patch constants.
vkd3d-shader/spirv: Do not use the output_info array for patch constants.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/464
Currently we are not properly handling register(cX) reservations for SM1, this is one of the things required for the SNK shaders (CW Bug Bug 18092).
register(cX) reservations also change the offset in the $Globals buffer in SM4, so support for this is also included.
---
Patch 1/4 is required to specify:
```
[require]
shader model < 4.0
```
so that the tests that follow do not get run with the vulkan backend on SM4. I think nobody disagreed with that patch.
--
v8: vkd3d-shader/hlsl: Turn register(cX) reservations into buffer offset for SM4.
vkd3d-shader/hlsl: Make register(cX) reservations work for SM1.
tests: Test register(cX) reservations.
tests: Rename register-reservations.shader_test to register-reservations-resources.shader_test.
tests/shader-runner: Run compilation tests with SM1 when SM1 models are selected.
tests/shader-runner: Allow passing (sm<4) and (sm>=4) to "fail" and "todo" qualifiers.
tests/shader-runner: Discern between the minimum_shader_model and the selected_shader_model.
tests/shader-runner: Add missing requirement checks for backends.
ci: Execute the shader runner on the correct test data on Windows.
ci: Deduplicate the CI configuration for Windows.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/458
--
v10: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten structured control flow instructions.
vkd3d-shader: Rename shader_instruction_array_add_icb() to shader_instruction_array_add_opaque_param().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
`winecoreaudio` currently uses the `AudioDeviceID` as the device string (stored in the registry and used to correlate between Core Audio devices and generated GUIDs passed to Windows applications), but an `AudioDeviceID` may change between boots or even when a device is connected/disconnected.
Use the UID instead, which is persistent across boots and connects/disconnects.
These are strings like `BuiltInSpeakerDevice` or `AppleUSBAudioEngine:Apple Inc.:Studio Display:00008030-000128469718180E:6,7`.
This only seems to be documented in the header files, from `AudioHardwareBase.h`:
"`kAudioDevicePropertyDeviceUID`: A CFString that contains a persistent identifier for the AudioDevice. An
AudioDevice's UID is persistent across boots. The content of the UID string
is a black box and may contain information that is unique to a particular
instance of an AudioDevice's hardware or unique to the CPU. Therefore they
are not suitable for passing between CPUs or for identifying similar models
of hardware."
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4632
This MR implements mouselook, which requires support for ClipCursor and relative motion events. The latter we can implement directly without using `SetCursorPos` for which no Wayland protocol exists at the moment.
1. Implement setting the foreground window, as this is required for clipping to work properly (i.e., for the ClipCursor driver callback to be called in the proper process/thread, see commit (2)). We can't unconditionally set the foreground window on keyboard focus, since compositors are eager to give the focus and some windows strongly dislike that (see https://gitlab.winehq.org/wine/wine/-/merge_requests/4102#note_51733). This MR borrows the "managed" window concept from WineX11 to detect windows that we shouldn't allow the compositor to manage, and avoids setting such windows as the foreground on keyboard focus.
2. Implement cursor clipping using the pointer-constraints protocol.
3. Switch to emitting relative motion events using the relative-pointer protocol when the cursor is not visible.
---
4. Finally, a potential fix for an issue I have been seeing where apps may transiently lose the active status (see commit message for more) as a result of the foreground state changes in this MR, which has undesirable side-effects. I have included this here for MR completeness/correctness, but it can be moved to a subsequent MR if preferred.
Note: the velocity of relative motion events when scaling is involved is somewhat inconsistent among Wayland compositors.
Thanks!
--
v5:
https://gitlab.winehq.org/wine/wine/-/merge_requests/4593