December 2023 - wine-gitlab

[PATCH 0/1] MR4679: Draft: winewayland.drv: Release all keys on keyboard focus loss.
by Alexandros Frantzis (＠afrantzis) 12 Dec '23

12 Dec '23

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

2 1

[PATCH v2 0/1] MR4675: mf/tests: Workaround broken Win7 test_h264_decoder_concat_streams result.
by Rémi Bernon (＠rbernon) 12 Dec '23

12 Dec '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55638 -- v2: mf/tests: Workaround broken Win7 test_h264_decoder_concat_streams result. https://gitlab.winehq.org/wine/wine/-/merge_requests/4675

2 1

[PATCH 0/1] MR4675: mf/tests: Workaround broken Win7 test_h264_decoder_concat_streams result.
by Rémi Bernon (＠rbernon) 12 Dec '23

12 Dec '23

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

3 2

[PATCH 0/1] MR4678: winebus: Return backend init status from bus_main_thread_start.
by Rémi Bernon (＠rbernon) 12 Dec '23

12 Dec '23

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

2 1

Re: [PATCH v3 0/2] MR3405: server: Use the capture window as cursor window if it is set.
by Rémi Bernon (＠rbernon) 12 Dec '23

12 Dec '23

This was meant to fix a regression, anything wrong with it? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3405#note_55801

1 0

[PATCH 0/1] MR4677: server: Peek wine internal driver messages regardless of filter.
by Rémi Bernon (＠rbernon) 12 Dec '23

12 Dec '23

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

2 1

[PATCH 0/3] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) 12 Dec '23

12 Dec '23

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

4 7

[PATCH 0/1] MR3338: wined3d: Identity AMD as valid gl vendor string.
by Etaash Mathamsetty (＠etaash.mathamsetty) 12 Dec '23

12 Dec '23

Is it just me, or am I getting déjà vu from this (a third time ?) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3338

4 16

[PATCH v2 0/2] MR4672: Draft: msdelta: Add ApplyDelta stub.
by Vijay Kiran Kamuju (＠infyquest) 12 Dec '23

12 Dec '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56007 -- v2: msdelta: Add ApplyDelta stub. include: Add msdelta header file. https://gitlab.winehq.org/wine/wine/-/merge_requests/4672

3 3

Re: [PATCH v5 0/1] MR4666: gdiplus: Prevent uninitializd memory access (Coverity)
by Fabian Maurer (＠DarkShadow44) 12 Dec '23

12 Dec '23

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

1 0

2025

2024

2023

2022

wine-gitlab December 2023