Fix comctl32/Combo : When a letter is typed while list is dropped down, combo shall move to the associated letter without closing the drop down list
eg, on WM_CHAR, if CBF_DROPPED is set (list dropped) it shall not close (CBF_NOROLLUP to be set)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4750
comctl32/IPAddress component background is incorrectly painted when disabled

This is due to an incorrect Brush being used
Fixed :

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4749
Fix comctl32/propsheet - should react to CTRL+TAB and CTRL+SHIFT+TAB
Currently not working as calling IsDialogMessageW instead of PROPSHEET_IsDialogMessage which is correctly implementing TAB key management
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4752
ComDlg32 / Color picker does not use "limited" value, leading to out of bound
This cause the lum bar to get crazy


--
v2: Update ipaddress.c
https://gitlab.winehq.org/wine/wine/-/merge_requests/4746
ComDlg32 / Color picker does not use "limited" value, leading to out of bound
This cause the lum bar to get crazy


--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4746
On Wed Dec 27 01:54:00 2023 +0000, Jinoh Kang wrote:
> You're correct that debuggers can be sensitive to the timing of the
> initial breakpoint.
> Adding a conformance test would let us confirm your observation, and
> ensure such regression won't happen in the future. For reference, see 2b40969c58a099f958c58909b666915991a42979.
> I'm still approving since the existing tests did not fail and I cannot
> find a particular reason `process_breakpoint();` must be placed exactly
> there in the commit history.
I'm not really sure how to write test case for this, seems quite complicated since basically need to load DLL with `int3` - if it's triggered after system breakpoint then it's a pass.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4655#note_56427
--
v9: tests: Mark loading from stencil as buggy on MoltenVK.
tests: Mark resource arrays as buggy on MoltenVK.
tests: Mark unbounded ranges as buggy on MoltenVK.
tests: Mark predicated rendering as buggy on MoltenVK.
tests: Mark streaming output as buggy on MoltenVK.
tests: Mark some sampling tests as buggy on MoltenVK.
vkd3d-shader/spirv: Specify behavior for bit field instructions.
tests: Use a uint target for rendering uint data.
vkd3d: Specify the aspect when creating NULL UAVs.
ci: Dumps the d3d12 summary line in the CI log.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531
Currently, a 15 character debug channel name (e.g. `WINE_DEFAULT_DEBUG_CHANNEL(mediacontroller)`) results in no null-terminator at the end of the debug channel name array (`char name[15]`), and no compiler warning. A 16+ character name does throw an excess-initializers warning.
Arguably, the debug channel name should be treated as a fixed-length string and not null-terminated, but this would require changes in a number of places (`winedbg`, `taskmgr`, `ntdll`, `winecrt0`). Also, overly-long channel names would still only result in truncation and a compiler warning rather than an error.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4743
--
v4: vkd3d-shader/spirv: Specify behavior for bit field instructions.
tests: Use a uint target for rendering uint data.
vkd3d: Specify the aspect when creating NULL UAVs.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531
You're correct that debuggers can be sensitive to the timing of the initial breakpoint.
Adding a conformance test would let us confirm your observation, and ensure such regression won't happen in the future. For reference, see 2b40969c58a099f958c58909b666915991a42979.
I'm still approving since the existing tests did not fail and I cannot find a particular reason `process_breakpoint();` must be placed exactly there in the commit history.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4655#note_56412
DMUS_PMSG::dwType is the type of the message, but we are comparing it to
curve types. We should be using DMUS_CURVE_PMSG::bType instead.
* * *
(I tried to write some test cases for this. I created a IDirectMusicPort implementation that checks the generated midi commands, but instead I cannot get Windows to generate any midi commands for CCCURVEs. )
--
v2: dmime: Fix handling of curve PMSG.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4703
A temporary variable is used here to assist with assignment
but this does not conform to the coding style in the rest of
gdiplus and introduces an unnecessary variable.
Signed-off-by: David Kahurani <k.kahurani(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4734
Currently there is `NtContinue()` test only for `aarch64` so implement it for amd64 aswell.
This implementation is very similar to `aarch64` and it's very basic test.
It doesn't change/test `ContextFlags` so it won't catch https://bugs.winehq.org/show_bug.cgi?id=56050 but that can be implemented later on top of this.
--
v2: ntdll/tests: Implement test_continue() for amd64
https://gitlab.winehq.org/wine/wine/-/merge_requests/4720
CreateClassEnumerator() can return S_FALSE and NULL moniker if the specified category is empty or doesn't exist (and devenum implementation can do that), build_directshowfilters_tree() will crash in that case. That's not new and AFAIU should not be normally hit as the category should not be empty, but I managed to hit that on some prefix (maybe with messed up direct show registration) and the change looks simple and sure enough probably (currently it will always crash if gets S_FALSE).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4733
The practical effect of the change is that boolean is 1 byte while BOOL is 4 bytes, so we are wrongly filling more bytes in those methods and wrongly expect full 4 byte BOOL value to be filled from apps IIterator implemenation (and thus depend on uninitialized data in implementation).
That fixes a hang on new game start in Phasmophobia (when it is configured to use windows.media.speech). That was originally attributed as a regression from commit 62173699c38453777c7d5638ed2e779790506b75 ("include: Don't align the stack for PE builds.") while before that commit it worked by chance only of course, the commit only changed stack data a bit so we were a bit more lucky in getting high bytes of BOOL as 0 in windows.media.speech/vector.c:vector_hstring_create_copy().
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4731
Regression in signature normalisation, however the old code was not
correct either because it would apply the interpolation mode to all
components. Found in an Assassin's Creed: Valhalla shader.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/511
We are preferring the thread input cursor over the global desktop
cursor, but if the thread input has no cursor yet, for instance when
thread is attached to another thread without a message queue yet,
it will end up being invisible.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55961
--
v3: server: Change desktop cursor only when inside the thread's windows.
server: Introduce a new get_desktop_cursor_thread_input helper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4676
This fixes an issue seen in Outlook 365 where the password prompt appears to lock up.
Technically this fixes a regression introduced in 25906eedd8679fdb474976563f4a05a92e11bbd6, but I think Outlook had other issues that would have masked this one at the time.
--
v3: server: Always release internal hardware messages
https://gitlab.winehq.org/wine/wine/-/merge_requests/4726
This fixes an issue seen in Outlook 365 where the password prompt appears to lock up.
Technically this fixes a regression introduced in 25906eedd8679fdb474976563f4a05a92e11bbd6, but I think Outlook had other issues that would have masked this one at the time.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4726
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.
--
v5: 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
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v15: 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
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v14: 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.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/443
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v13: 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.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/443
We are preferring the thread input cursor over the global desktop
cursor, but if the thread input has no cursor yet, for instance when
thread is attached to another thread without a message queue yet,
it will end up being invisible.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55961
--
v2: server: Use the desktop cursor as the default thread input cursor.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4676
Some driver, e.g. MoltenVK, fail in some cases if the image view usage is too broad or unknown.
--
v3: wined3d: Expose the image view usage for non-default views.
wined3d: Expose the image view usage for null views.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4022
Some driver, e.g. MoltenVK, fail in some cases if the image view usage is too broad or unknown.
--
v2: wined3d: Expose the image view usage for non-default views.
wined3d: Expose the image view usage for null views.
wined3d: Mark an extension as supported if it is core for the Vulkan version in use.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4022
Adds an env variable WINE_WAYLAND_UNACCELERATED_POINTER
which allows raw input. This makes it easier to calculate
the same sensitivity in different games, use sensitivity
calculators, and easily change values when changing DPI
and do not depend on the compositor or OS.
For example, you want to set the sensitivity to half as much,
and sensitivity curves in libinput are more difficult
to calculate than in the games themselves.
--
v4: winewayland.drv: Add unaccelerated pointer support
https://gitlab.winehq.org/wine/wine/-/merge_requests/4698
On Mon Dec 18 12:14:13 2023 +0000, beh 591 wrote:
> @afrantzis just a quick question
> ```plaintext
> 00d8:err:d3d:wined3d_caps_gl_ctx_create Failed to find a suitable pixel format.
> 00d8:err:d3d:wined3d_adapter_gl_init Failed to get a GL context for
> adapter 00007F53BC3F2D50.
> ```
> is this a bug that has to do with that opengl support you are talking about
> well genshin impact works but its launcher doesn't so yeah just woundering
> maybe this is already a known bug or something
> * it works in the x11 side
thats because opengl support isn't in the upstream winewayland driver so of course something that uses opengl won't work
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_56256