December 2023 - Wine-GitLab

[PATCH 0/5] MR4702: dmime/tests: Multiple fixes for various Windows test failures.
by Rémi Bernon Dec. 15, 2023

Dec. 15, 2023

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55637 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4702

2 6

[PATCH 0/1] MR4701: kernel32/tests: Fix ProcessMachineTypeInfo tests.
by Hans Leidekker (＠hans) Dec. 15, 2023

Dec. 15, 2023

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4701

2 1

[PATCH v6 0/5] MR519: vkd3d-shader/dxil: Support minimum precision.
by Conor McCarthy (＠cmccarthy) Dec. 15, 2023

Dec. 15, 2023

-- v6: 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

3 10

[PATCH v12 0/7] MR443: tests: Add some tests for effects groups syntax.
by Nikolay Sivov (＠nsivov) Dec. 15, 2023

Dec. 15, 2023

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v12: vkd3d-shader/tpf: Add 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

2 7

Re: [PATCH v3 0/1] MR4694: ntdll: Make sure executable is large address aware and enables dynamic base and high entropy va before free reserved memory
by Looming Linux (＠loominglinux) Dec. 15, 2023

Dec. 15, 2023

Already fixed by 7a7b82880a73e654933b7866e79f3e9a62a565ef! Thanks! Will close this MR! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4694#note_56056

1 0

Re: [PATCH v3 0/1] MR4694: ntdll: Make sure executable is large address aware and enables dynamic base and high entropy va before free reserved memory - closed
by Looming Linux (＠loominglinux) Dec. 15, 2023

Dec. 15, 2023

This merge request was closed by Looming Linux. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4694

1 0

[PATCH 0/1] MR4700: po: Update Simplified Chinese translation.
by Jactry Zeng (＠jactry) Dec. 15, 2023

Dec. 15, 2023

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4700

2 1

[PATCH v4 0/3] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) Dec. 15, 2023

Dec. 15, 2023

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. -- v4: 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

2 4

[PATCH v3 0/3] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) Dec. 14, 2023

Dec. 14, 2023

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. -- v3: 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

2 4

[PATCH v3 0/1] MR4674: comctl32/listview: Ignore the lParam to WM_PRINTCLIENT and add tests.
by Alex Henrie (＠alexhenrie) Dec. 14, 2023

Dec. 14, 2023

Based on simliar patch for comctl32/treeview: 231199bc46 WM_PRINTCLIENT paints the items of a listview, including the item backgrounds, but never the listview background. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54878 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55005 Co-authored-by: Alex Henrie <alexhenrie24(a)gmail.com> -- v3: comctl32/listview: Ignore the lParam to WM_PRINTCLIENT and add tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/4674

3 6