Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v7: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
Jinoh Kang (@iamahuman) commented about dlls/ntdll/unix/server.c:
> *
> * Read data from the reply buffer; helper for wait_reply.
> */
> -static void read_reply_data( void *buffer, size_t size )
> +static unsigned int read_reply_data( void *buffer, size_t size )
`read_reply_data` can now return failure. Shall we update its only caller, `wait_reply`, to handle it? The abandoned thread, detached from the server, is no longer forcibly aborted and thus let loose to do whatever it wants as long as it doesn't involve a server call, and in case of abnormally terminated server, a SIGQUIT might not have even arrived.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4811#note_56996
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v6: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
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 parallel discussions 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 for these 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.
--
v8: tests: Use the vulkan runner to run SM1 compilation tests.
tests/shader-runner: Call each runner only once.
tests/shader-runner: Support reading multiple model range args for qualifiers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514
--
v3: vkd3d-shader/tpf: Validate sysvals in index range declarations.
vkd3d-shader/ir: Trim non-arrayable sysvals from the last element of an index range.
tests: Test punned array access in patch constant functions.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/537
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v5: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v4: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
Description:
When flags does not include DT_CALCRECT, since len is calculated in the middle,
it will be reduced to zero. Resulting in the length of the processed string that
is finally returned to zero and the non-processing string length is unchanged.
But some application taking the non-processing string length to zero as the loop
end condition.
Log:
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: Icc0f250f5f4faba1bee8326fc911a4fc9cd7c012
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4812
--
v7: vkd3d-shader/hlsl: Allow non-numeric types in the ternary operator.
vkd3d-shader/hlsl: Separate an add_ternary() helper.
tests: Add many more tests for ternary expressions.
vkd3d-shader/hlsl: Do not try to lower ternaries of types other than scalar or vector.
vkd3d-shader/hlsl: Remove a redundant definition of the "float" type.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/463
It is inefficient to download Wine and build `widl` at each run of the `build-mac` job. And while for `widl` itself that's not a big deal, in the future I'd like to build MoltenVK on the CI, so we don't depend on the version available on the CI runner, which would make each CI run quite heavier.
So I came up with an `image` CI job that, similarly to Linux, collect together the required dependencies for running the pipeline. macOS doens't support a real Docker image, so this "image" is just a `.tar.gz` file hosted in the GitLab package registry.
There is a little problem with that: in GitLab uploading a new file in the package registry doesn't overwrite a file with the same name already available, even if the latest file is returned anyway. So the old versions basically pile up and have to be manually remove every now and then. Hopefully the environment is only seldom recreated, so the storage usage is not a concern.
As usual, pipelines for MRs that change the pipeline image itself are bound to fail. A demo pipeline is https://gitlab.winehq.org/giomasce/vkd3d/-/pipelines/20433.
--
v2: ci: Prepare the macOS build environment in a dedicated CI job.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/538
Capability Geometry allows to use the Layer builtin in geometry shaders.
For vertex shaders ShaderLayer should be used, but it's only available
starting from SPIR-V 1.5. ShaderViewportIndexLayerEXT can be used instead
with extension SPV_EXT_shader_viewport_index_layer.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/546
--
v16: tests: Mark a strip cut test as buggy in MoltenVK.
tests: Mark a depth sampling test as buggy on MoltenVK.
tests: Mark the tessellation pipeline as buggy on MoltenVK.
tests: Mark geometry shaders as buggy on MoltenVK.
tests: Mark ReadFromSubresource() and WriteToSubresource() as todo on MoltenVK.
tests: Mark a test related to instanced draws as buggy on MoltenVK.
tests: Mark count buffers as buggy on MoltenVK.
tests: Mark a timestamp query test as buggy on MoltenVK.
tests: Mark clip distance as unsupported on MoltenVK.
tests: Mark cull distance as buggy on MoltenVK.
tests: Mark unbounded descriptor ranges as buggy on MoltenVK.
tests: Mark loading from stencil as buggy on MoltenVK.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531
It is inefficient to download Wine and build `widl` at each run of the `build-mac` job. And while for `widl` itself that's not a big deal, in the future I'd like to build MoltenVK on the CI, so we don't depend on the version available on the CI runner, which would make each CI run quite heavier.
So I came up with an `image` CI job that, similarly to Linux, collect together the required dependencies for running the pipeline. macOS doens't support a real Docker image, so this "image" is just a `.tar.gz` file hosted in the GitLab package registry.
There is a little problem with that: in GitLab uploading a new file in the package registry doesn't overwrite a file with the same name already available, even if the latest file is returned anyway. So the old versions basically pile up and have to be manually remove every now and then. Hopefully the environment is only seldom recreated, so the storage usage is not a concern.
As usual, pipelines for MRs that change the pipeline image itself are bound to fail. A demo pipeline is https://gitlab.winehq.org/giomasce/vkd3d/-/pipelines/20433.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/538
--
v6: vkd3d-shader/hlsl: Allow non-numeric types in the ternary operator.
vkd3d-shader/hlsl: Separate an add_ternary() helper.
tests: Add many more tests for ternary expressions.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/463
MR !531 contains the rest.
--
v3: tests: Mark resource arrays as buggy on MoltenVK.
tests: Mark predicated rendering as buggy on MoltenVK.
tests: Mark streaming output as buggy on MoltenVK.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/532
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v3: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v2: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
This re-implementation removed unnecessary API call to GdipGetPathPoints and avoids allocating memory unnecessarily.
It is also quite likely that this API doesn't ever return OutOfMemory errors.
Signed-off-by: David Kahurani k.kahurani(a)gmail.com
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4789
Checking flags of the thread desktop to determine whether virtual desktop is on is unreliable.
For example, CEF applications create their own desktop and so is_virtual_desktop() could incorrectly
report that virtual desktop is off.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55810
--
v2: server: inherit DF_WINE_CREATE_DESKTOP when creating a non-root desktop.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4786
--
v4: vkd3d-shader/ir: Set merged signature element interpolation mode only from used elements.
tests: Test an interpolated PS input where component x is unused.
vkd3d-shader/ir: Revert "Do not merge signature elements which have different interpolation modes."
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/536
--
v3: vkd3d-shader/ir: Set merged signature element interpolation mode only from used elements.
tests: Test an interpolated PS input where component x is unused.
vkd3d-shader/ir: Revert "Do not merge signature elements which have different interpolation modes."
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/536
This replaces Wine's 10 copies of the function.
--
v2: strmbase: Use debugstr_reftime instead of reimplementing it.
wmvcore: Use debugstr_reftime instead of reimplementing it.
winegstreamer: Use debugstr_reftime instead of reimplementing it.
quartz: Use debugstr_reftime instead of reimplementing it.
qasf: Use debugstr_reftime instead of reimplementing it.
mfsrcsnk: Use debugstr_reftime instead of reimplementing it.
mfplat: Use debugstr_reftime instead of reimplementing it.
mf: Use debugstr_reftime instead of reimplementing it.
evr: Use debugstr_reftime instead of reimplementing it.
include: Introduce debugstr_reftime and wine_dbgstr_reftime.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4461
LANCommander calls NtMapViewOfSectionEx with alloc_type=0x4000, which
Wine does not handle, but you couldn't tell from the trace.
--
v2: ntdll: Include alloc_type argument in NtMapViewOfSection(Ex) traces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4788
The old code did indirect jmp with a misaligned operand address.
--
v2: ntdll/tests: Restore x86-64 #AC exception test in test_exceptions().
ntdll/tests: Avoid misaligned load in exception handler code in run_exception_test_flags().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4793
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 parallel discussions 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 for these 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.
--
v7: tests: Use the vulkan runner to run SM1 compilation tests.
tests/shader-runner: Call each runner only once.
tests/shader-runner: Support reading multiple model range args for qualifiers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514
I discovered a similar instance in `test_shader_eval_attribute()`:
```
VUID-RuntimeSpirv-OpTypeVector-06816(ERROR / SPEC): msgNum: 79036675 - Validation Error: [ VUID-RuntimeSpirv-OpTypeVector-06816 ] Object 0: handle = 0x240000000024, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0x250000000025, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x4b60103 | vkCreateGraphicsPipelines(): pCreateInfos[0] starting at Location 1 Component 0 the Output (VK_SHADER_STAGE_VERTEX_BIT) has a Vec4 while Input (VK_SHADER_STAGE_FRAGMENT_BIT) as a Vec2. Enable VK_KHR_maintenance4 device extension to allow relaxed interface matching between input and output vectors. The Vulkan spec states: Any OpTypeVector output interface variables must not have a higher Component Count than a matching OpTypeVector input interface variable (https://www.khronos.org/registry/vulkan/specs/1.2/html/vkspec.html#VUID-Run…)
```
Here again two different semantics are merged in the VS but not in the PS, which trigger a similar error. And again this seems to cause a failure in MoltenVK.
The difference is that this doesn't seem to be related to 66cb2815f0662713c3255113255cfd7cf5e406fb, it also happened before. But maybe it's useful to know anyway.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/464#note_56768
--
v2: vkd3d-shader/dxil: Implement DX intrinsic BufferLoad for typed buffers.
vkd3d-shader/dxil: Load typed UAV descriptors.
vkd3d-shader/dxil: Load typed SRV descriptors.
vkd3d-shader/spirv: Do not assert VKD3D_DATA_UINT in spirv_compiler_emit_ld_raw_structured_srv_uav().
vkd3d-shader/dxil: Pass the code block and instruction in a struct to intrinsic handlers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/533
This is my first time contributing wine and there are a lot of things I'm not sure about, so any comments are welcome. :)
--
v15: kernel32: add sync barrier test
kernel32: impl sync barrier
https://gitlab.winehq.org/wine/wine/-/merge_requests/4372
--
v5: vkd3d-shader/hlsl: Allow non-numeric types in the ternary operator.
vkd3d-shader/hlsl: Separate an add_ternary() helper.
tests: Add many more tests for ternary expressions.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/463
--
v19: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten SWITCH/CASE/DEFAULT/ENDSWITCH control flow instructions.
vkd3d-shader/ir: Flatten LOOP/BREAK/CONTINUE/ENDLOOP control flow instructions.
vkd3d-shader/ir: Flatten IF/ELSE/ENDIF control flow instructions.
vkd3d-shader/spirv: Handle RETP in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Handle DISCARD and TEXKILL in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
The pipeline in question has a float3 and a float which are COLOR1 and COLOR2 respectively, and they get packed into the same registers. The VS merges the two together, but the PS doesn't. I'm not sure why, but it may have something to do with the fact that the PS consumes the COLOR1 but not the COLOR2. Conor, do you have an immediate idea here?
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/464#note_56736
--
v18: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten SWITCH/CASE/DEFAULT/ENDSWITCH control flow instructions.
vkd3d-shader/ir: Flatten LOOP/BREAK/CONTINUE/ENDLOOP control flow instructions.
vkd3d-shader/ir: Flatten IF/ELSE/ENDIF control flow instructions.
vkd3d-shader/spirv: Handle RETP in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Handle DISCARD and TEXKILL in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450