> ```diff
> -#if defined(SONAME_LIBDXCOMPILER) && !defined(VKD3D_CROSSTEST)
> +#if defined(SONAME_LIBDXCOMPILER) || defined(VKD3D_CROSSTEST)
> ```
Should that just be "#if defined(SONAME_LIBDXCOMPILER)"? We could perhaps consider defining SONAME_LIBDXCOMPILER to "dxcompiler.dll" if it isn't already defined and we have VKD3D_CROSSTEST, but in principle I don't think VKD3D_CROSSTEST needs special handling here.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/519#note_55909
The Wayland specification states about the keyboard leave event:
After this event client must assume that all keys, including
modifiers, are lifted and also it must stop key repeating if
there's some going on.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56001
---
To replicate a manifestation of the problem:
1. Open notepad
2. Hold down a key, wait for repetition to begin
3. While keeping key pressed, change focus to some other window (e.g. click away)
4. Key keeps repeating in notepad forever (lifting the key has no effect now, since the keyboard focus has been lost)
--
v2: winewayland.drv: Release all keys on keyboard focus loss.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4679
Fixes spurious crashes in Steam when downloading games.
The download causes a huge amount of SIGUSR1 signals, and it becomes
very likely that one signal will be received while being inside the
syscall or unix call dispatchers.
When this happens, it can be received within the small range of
instructions where %fs has been restored but we have not yet switched
to the syscall stack, or the other way around in the return path.
The signal handler then was restoring the 32bit %fs while returning to
the syscall dispatcher, then we are entering a syscall with %fs set to
the wrong value.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4683
--
v2: vkd3d-shader/dxil: Support 16-bit types.
vkd3d-shader/spirv: Introduce HALF and UINT16 types for minimum precision.
vkd3d-shader/spirv: Introduce a data_type_is_floating_point() helper function.
tests/shader-runner: Add tests for minimum-precision constants.
tests/shader-runner: Run Shader Model 6 tests in the crossbuild.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/519
--
v6: mf/tests: Test IMFClockStateSink in shutdown state.
mf/tests: Add initial tests for MPEG4 media sink sample processing.
mf/tests: Use IMFMediaEventGenerator interface in event wait helper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3369
Since Yousician's last update, it was throwing an error when initialising audio output. Unfortunately I don't have access to the old version, but they seem to have dropped win<10 support, and are using only IAudioClient3_InitializeSharedAudioStream. They also use IDeviceTopology to get the type of the first output connector.
This is the bare minimum I needed to get it working.
--
v13: mmdevapi: add stub for IDeviceTopology
mmdevapi/tests: add test for IDeviceTopology
mmdevapi: implement IAudioClient3_InitializeSharedAudioStream
mmdevapi/tests: add test for AudioClient3_InitializeSharedAudioStream
https://gitlab.winehq.org/wine/wine/-/merge_requests/3554
In order to validate SPIR-V code we have to fix a little bug that causes us to emit invalid SPIR-V code in some cases. That's technically a bug, so it should be good to fix it in 1.10; unfortunately the way the bug is fixed right now is not ideal, because in some cases it causes many push constants to be wasted, potentially reaching the Vulkan implementation limit, so some application that used to work might stop working. Eventually we should implement a better allocator for push constants, and include an alternative path if the Vulkan implementation doesn't offer enough push constants.
--
v6: ci: Build vkd3d with SPIRV-Tools.
vkd3d-shader/spirv: Honor force_validation after emitting SPIR-V code.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/504
In order to validate SPIR-V code we have to fix a little bug that causes us to emit invalid SPIR-V code in some cases. That's technically a bug, so it should be good to fix it in 1.10; unfortunately the way the bug is fixed right now is not ideal, because in some cases it causes many push constants to be wasted, potentially reaching the Vulkan implementation limit, so some application that used to work might stop working. Eventually we should implement a better allocator for push constants, and include an alternative path if the Vulkan implementation doesn't offer enough push constants.
--
v5: ci: Build vkd3d with SPIRV-Tools.
vkd3d-shader/spirv: Honor force_validation after emitting SPIR-V code.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/504
Like the previous MRs, this has the objective of:
* Preparing the way for SM1-specific tests.
* Running SM1 compilation tests, even if we don't have a runner available to execute them (yet).
* Allowing different runners to run through the shader_test file several times, targeting different shader model ranges.
The current plan is:
* We won't separate compilation tests from execution tests as in !418.
* Instead of naming individual shader models in the shader_test files as in !434, we will keep working with the shader model ranges provided in the [require] directives.
* We will test SM1 compilation going through the shader_test file twice with the vulkan runner, one for SM1 models and other for SM4 models, and for now we will just give a "todo" for execution tests until they are implemented (@zfigura patches).
This first part only includes facilities to properly mark SM1-specific tests (as required by !458) and some refactoring to better work with the idea of intersecting shader model ranges.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/473
--
v3: vkd3d-shader/d3d-asm: Add an "internal" mode for the ASM dumper.
vkd3d-shader/d3d-asm: Dump unknown types as "<unknown>".
vkd3d-shader/d3d-asm: Dump recently added types.
vkd3d-shader/d3d-asm: Write a single type in shader_dump_data_type().
vkd3d-shader/d3d-asm: Indent on IFC.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/502
--
v10: 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 'float64' requirement directive.
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/489
On Tue Dec 12 18:22:51 2023 +0000, Vladimir Panteleev wrote:
> Thank you again for working on this fix. The CI failure looks unrelated,
> perhaps rebase on `master` and it will go away?
Oh right, I thought I did that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3405#note_55829
On Tue Dec 12 18:22:51 2023 +0000, Rémi Bernon wrote:
> This was meant to fix a regression, anything wrong with it?
Thank you again for working on this fix. The CI failure looks unrelated, perhaps rebase on `master` and it will go away?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3405#note_55826
Implement effect related functions in Gdiplus.
This currently a WIP.
--
v10: gdiplus: Add GdipGetEffectParameters implementation.
gdiplus: Add GdipSetEffectsParameters implementation.
gdiplus: Add GdipGetEffectParameterSize implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661
The Wayland specification states about the keyboard leave event:
After this event client must assume that all keys, including
modifiers, are lifted and also it must stop key repeating if
there's some going on.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56001
---
To replicate a manifestation of the problem:
1. Open notepad
2. Hold down a key, wait for repetition to begin
3. While keeping key pressed, change focus to some other window (e.g. click away)
4. Key keeps repeating in notepad forever (lifting the key has no effect now, since the keyboard focus has been lost)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4679
Recap:
My previous proposals to extend the shader_runner to SM1 were focusing on separating compilation tests ([shader] directives) from execution tests ([test] directives), and let the generic shader_runner.c:compile_shader() in charge of the former.
However, Henri was more inclined to aim for making the parser agnostic to the language of the tests so we can potentially extend the shader_runner tests to other languages such as d3d-asm. This means, removing the burden of compilation from the parser altogether, and moving it to the runners, probably through a runner->compile function pointer (even if most of them end up doing the same thing, compiling with vkd3d-shader or the native compiler, depending on availability).
Agreeing with going in this general direction, this MR contains patches to do SM1 compilation calling run_shader_tests() for SM1 profiles from the Vulkan runner (skipping execution for now), and some improvements to the qualifiers syntax.
Despite this, there are a parallel discussion on:
- Whether to name the shader models individually in the [require] directives or expressing the range of shader models where the test should pass. In the latter case, whether to run for all shader models, only the lowest one in the SM1, SM4, and SM6 groups, or to allow the runner to select a shader model within the range (I feel strongly against this now, I think the runner should just retrieve a boolean in runner->check_requirements).
- Where to do the iteration across different shader models, if in run_shader_tests() or expect each runner to call run_shader_tests() several times as we do now.
But there is no need to settle on something yet.
---
Now, what may be the most noisy part of this MR is that even though we are calling run_shader_tests() through the Vulkan runner, this will result in calling shader_runner.c:compile_shader() instead of shader_runner_vulkan.c:compile_shader(), but if we follow the "making the parser agnostic" plan, we eventually should get rid of shader_runner.c:compile_shader() and introduce the runner->compile pointer instead.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514
On Tue Dec 12 00:19:53 2023 +0000, Nikolay Sivov wrote:
> No, sorry for confusion. Uninitialized access issue seems to be about
> that one record. It is documented in EMF+ specification.
According to the spec a previous location of 0 is assumed. For me, this implies that the first element should not always be `0`, but be `0 + points[0]`
IMHO, EmfPlusRecordTypeDrawImagePoints look correct and this wrong.
A test could clear this up, but I'm not exactly sure on how to write one. Any tips?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4666#note_55782
On Tue Dec 12 00:02:25 2023 +0000, Fabian Maurer wrote:
> This MR is about playback for EmfPlusRecordTypeFillClosedCurve, or is
> there something else I missed?
> Regarding EmfPlusRecordTypeDrawImagePoints, is that 'P' flag documented
> somehwere? Because we don't seem to have a test for that either.
No, sorry for confusion. Uninitialized access issue seems to be about that one record. It is documented in EMF+ specification.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4666#note_55775
On Tue Dec 12 00:02:25 2023 +0000, Nikolay Sivov wrote:
> Playback for EmfPlusRecordTypeFillClosedCurve has the same issue, and
> EmfPlusRecordTypeDrawImagePoints was already broken because it starts
> from first delta point instead of a zero origin.
This MR is about playback for EmfPlusRecordTypeFillClosedCurve, or is there something else I missed?
Regarding EmfPlusRecordTypeDrawImagePoints, is that 'P' flag documented somehwere? Because we don't seem to have a test for that either.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4666#note_55774
--
v5: 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
--
v7: tests/shader-runner: Add a non-const-indexing test for asfloat() result storage.
vkd3d-shader/spirv: Bitcast if necessary in the spirv_compiler_emit_mov() general implementation.
vkd3d-shader/dxil: Implement the DXIL STORE instruction.
vkd3d-shader/dxil: Implement the DXIL ALLOCA instruction.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/498
--
v3: 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
In order to validate SPIR-V code we have to fix a little bug that causes us to emit invalid SPIR-V code in some cases. That's technically a bug, so it should be good to fix it in 1.10; unfortunately the way the bug is fixed right now is not ideal, because in some cases it causes many push constants to be wasted, potentially reaching the Vulkan implementation limit, so some application that used to work might stop working. Eventually we should implement a better allocator for push constants, and include an alternative path if the Vulkan implementation doesn't offer enough push constants.
--
v4: ci: Build vkd3d with SPIRV-Tools.
vkd3d-shader/spirv: Honor force_validation after emitting SPIR-V code.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/504
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.
--
v3: bcrypt/tests: Add DH tests.
bcrypt: Set dh_params in key_import_dh/_public().
bcrypt: Assume we have a public key in key_export_dh_public().
bcrypt: Make sure key_asymmetric_derive_key() returns correct size.
bcrypt: Add support for generating DH keys from known parameters.
bcrypt: Reject DH keys smaller than 512 bits.
bcrypt: Make DH blob size validation more strict in key_import_pair().
bcrypt: Add helpers to create a public/private key pair.
bcrypt: Allow or disallow some operations based on whether keys are finalized.
bcrypt: Add support for retrieving DH parameters.
bcrypt: Add support for setting DH parameters.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4637
Fixes a regression from 1d337249f16ed61163315019f5dbbe4db3386390.
Prior to the commit, we were solving this case in a different way.
If `IDropTarget::DragOver()` returned `DROPEFFECT_NONE`, `X11DRV_XDND_DROPEFFECTToXdndAction()` would convert it to `XdndActionCopy`.
Wine-Bugs: https://bugs.winehq.org/show_bug.cgi?id=55179
--
v2: winex11: Do window search if IDropTarget::DragOver() returns DROPEFFECT_NONE.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4663
--
v6: tests/shader-runner: Add a non-const-indexing test for asfloat() result storage.
vkd3d-shader/spirv: Bitcast if necessary in the spirv_compiler_emit_mov() general implementation.
vkd3d-shader/dxil: Implement the DXIL STORE instruction.
vkd3d-shader/dxil: Implement the DXIL ALLOCA instruction.
tests/shader-runner: Test an uninitialised indexable temp.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/498
--
v3: gdiplus: Implement font linking for gdiplus.
gdiplus/tests: Add interactive test for font linking.
mlang: Fix bug with codepage priority in GetStrCodePages.
mlang/tests: Test codepages priority bug in GetStrCodepages.
mlang: Implement GetGlobalFontLinkObject.
mlang/tests: Test for GetGlobalFontLinkObject.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4082
In order to validate SPIR-V code we have to fix a little bug that causes us to emit invalid SPIR-V code in some cases. That's technically a bug, so it should be good to fix it in 1.10; unfortunately the way the bug is fixed right now is not ideal, because in some cases it causes many push constants to be wasted, potentially reaching the Vulkan implementation limit, so some application that used to work might stop working. Eventually we should implement a better allocator for push constants, and include an alternative path if the Vulkan implementation doesn't offer enough push constants.
--
v3: vkd3d-shader/spirv: Honor force_validation after emitting SPIR-V code.
ci: Build vkd3d with SPIRV-Tools.
vkd3d-shader/spirv: Move the SPIR-V dumper and validator below struct spirv_compiler.
vkd3d: Pad push constant ranges to 16 bytes.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/504
Latests MS compiler seem to emit an extra COFF entry.
Current code is too strict into accepting only predefined set
of references.
Just relax constraint for now. Will require a proper fix after
code freeze.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4670
Seen with PDB generated with "latest" MS compiler.
The data here is likely to be in the same form of other hash structures
we already handle.
(eg has a first vector to describe present entries, and a second one
to describe deleteid entries; we were incorrectly expecting an empty
deleted vector... so just skip for now the deleted vector in winedump
and dbghelp... this will probably end up with a more generic code
for reloading such hash structures, but after code freeze).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4669
--
v11: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten structured control flow instructions.
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
Currently, if a probe fails, it will print the line number of the [test]
block the probe is in, not the line number of the probe itself. This
makes it somewhat difficult to debug.
This commit makes it print the line number that a test fails at.
This code was actually written by @hverbeet for my first attempt at fixing this, !499.
CC @zfigura
--
v2: tests: Print the failing line numbers when a test fails.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/516
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.
--
v2: bcrypt/tests: Add DH tests.
bcrypt: Make sure key_asymmetric_derive_key() returns correct size.
bcrypt: Add support for generating DH keys from known parameters.
bcrypt: Reject DH keys smaller than 512 bits.
bcrypt: Make DH blob size validation more strict in key_import_pair().
bcrypt: Add helpers to create a public/private key pair.
bcrypt: Allow or disallow some operations based on whether keys are finalized.
bcrypt: Add support for retrieving DH parameters.
bcrypt: Add support for setting DH parameters.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4637
The is_window_managed function may acquire the (non-recursive) win_data lock
internally (is_window_managed->has_owned_popups->is_managed), so do not call
it with the win_data lock held.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55995
---
Note: WineX11 also calls `is_window_managed` with win_data locked, but its win_data mutex is recursive. I haven't found a compelling reason to use a recursive win_data mutex in the Wayland driver yet, hence this fix.
---
A simple way to reproduce the deadlock is:
1. Run winecfg
2. Go to the "Desktop Integration" tab
3. Click on OK
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4668
In order to validate SPIR-V code we have to fix a little bug that causes us to emit invalid SPIR-V code in some cases. That's technically a bug, so it should be good to fix it in 1.10; unfortunately the way the bug is fixed right now is not ideal, because in some cases it causes many push constants to be wasted, potentially reaching the Vulkan implementation limit, so some application that used to work might stop working. Eventually we should implement a better allocator for push constants, and include an alternative path if the Vulkan implementation doesn't offer enough push constants.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/504
Clang enables -Wenum-conversion by default. GCC does not, so this makes both configurations more similar.
The extra dwrite is for Clang -Wenum-float-conversion warning, which is not enabled by default, but it's enabled when -Wenum-conversion is specified.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4628