Since dcf0bf1f, one could no longer kill a GUI application launched from
unix shell (with start.exe /exec) with ctrl-c.
(depends on https://gitlab.winehq.org/wine/wine/-/merge_requests/3310
to be fully functional).
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
v4: programs/cmd: Better handle ctrl-c events.
ntdll,server: Terminate GUI programs launched from unix shell.
kernel32/console: Add tests for GenerateConsoleCtrlEvent().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312
The issue can be reproduced with LIBGL_ALWAYS_SOFTWARE=1 on Mesa. The
Gitlab machines are affected.
--
v2: d3d9/tests: Skip big test_query loops if the d3d implementation is too slow.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3680
Since 1.20, gst_element_request_pad_simple is available and
gst_element_get_request_pad is marked as deprecated.
--
v7: winegstreamer: Add MFMPEG4SinkClassFactory.
mf/tests: Use h264 and aac in mp4 media sink tests.
mf/tests: Add tests for h264 encoder.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3636
SPIR-V says this is undefined behaviour, but Direct3D actually specifies that it
should clamp. Most drivers do clamp, but llvmpipe does not. Hence this fixes a
couple of tests with llvmpipe.
This does of course add overhead to the ftou instruction, but I cannot imagine
that it is a common instruction to execute. This also is not the first time we
perform such checks; cf. udiv.
--
v2: vkd3d-shader/spirv: Clamp ftoi upper bound to UINT_MAX.
vkd3d-shader/spirv: Clamp ftoi lower bound to -INT_MIN.
vkd3d-shader/spirv: Clamp ftou upper bound to UINT_MAX.
vkd3d-shader/spirv: Clamp ftou lower bound to zero.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/289
Some games with support for the haptic feedback and speaker features of the Sony DualSense controller select the controller's audio output by filtering on the ContainerId IMMDevice property to find one that matches the controller's HID's.
While MRs !359 and !360 implement getting the ContainerID of the IMMDevice, this MR implements getting the ContainerID from the HID device.
As for !360, I marked this MR as a draft because I understand that the way the ���GUID��� is generated is far from ideal. Furthermore, there is code duplication with !360 in the way the container's sysfspath is found and how a GUID is generated from it, so moving that part elsewhere would make sense. But as for !360, I think I will need help with those tasks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/535
And discard irrelevant parts in select request. We currently store something in CTX_PENDING and ignore it later in select request if we're currently running in wow context.
--
v5: ntdll/tests: Add tests for setting context on unsuspended thread.
server: Store both contexts in pending context object.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3566
This MR replaces `vkd3d_shader_register.immconst_type` with `vkd3d_shader_register.dimension` which is intended for all register types and not just immconsts.
This dimension is parsed in tpf.c, and initialized according to the register type in d3dbc.c.
Having this field in vkd3d_shader_register allows us to avoid hardcoding special cases for the register dimensions when writing sm4 bytecode (e.g. for the sampler src register in gather instructions). Also, it allows for some fixes to d3d_asm.c, which are introduced in part 2 (https://gitlab.winehq.org/fcasas/vkd3d/-/commits/add_vkd3d_reg_dim).
--
v2: vkd3d-shader: Initialize registers using shader_register_init().
vkd3d-shader: Make shader_register_init() extern.
vkd3d-shader/d3dbc: Initialize register dimension for all register types.
vkd3d-shader/tpf: Parse register dimension for all register types.
vkd3d-shader: Turn vkd3d_shader_register.immconst_type into vkd3d_shader_register.dimension.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/319
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.
--
v2: vkd3d-shader: Validate source parameters.
vkd3d-shader: Validate destination parameters.
vkd3d-shader: Check that registers are valid.
vkd3d-shader: Check that instructions are valid.
vkd3d-shader: Introduce a boilerplate to validate the generated IR.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317
---
See the added comment for details what is going on.
--
v4: d3d9/tests: Wait longer in test_occlusion_query for software renderers.
d3d9/tests: The device window may restore behind our back in test_wndproc.
d3d9/tests: Work around test_reset_fullscreen failing on gitlab CI.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3565