April 2024 - Wine-gitlab - list.winehq.org

[PATCH v12 0/3] MR734: vkd3d-shader/dxil: SamplePosition and SampleCount.
by Conor McCarthy (＠cmccarthy) 09 Apr '24

09 Apr '24

-- v12: vkd3d-shader/dxil: Implement DX intrinsic RenderTargetGetSampleCount. vkd3d-shader/dxil: Implement DX intrinsics Texture2DMSGetSamplePosition and RenderTargetGetSamplePosition. tests/hlsl: Add tests for GetSamplePosition() and GetSampleCount(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/734

2 3

[PATCH v4 0/1] MR3908: wineserver: Report non-zero exit code for abnormal process termination
by Adam Rehn (＠adamrehn) 09 Apr '24

09 Apr '24

**Overview:** Wine currently reports an exit code of zero for processes that terminate due to either of the following conditions: - The Linux process that represents the Windows process receives a signal such as `SIGKILL` (e.g. due to a user manually killing the process, or the Linux OOM killer targeting the process due to memory pressure) - The process fails to start because the image is a 32-bit executable and Wine has only been built with 64-bit support Both of these scenarios represent failures, and so a non-zero exit code is appropriate. This patch ensures that an exit code of 1 is reported for these abnormal process termination edge cases. **Underlying cause:** The following logic flow occurs in the Wine server for typical process termination: 1. When a `process` object is created by the Wine server, its `exit_code` field is [set to an initial value](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.… of `STILL_ACTIVE`, and the `exit_code` field in each of its corresponding `thread` objects is [set to a default value of zero](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/thread.c?…. 2. When a client process terminates, it sends a `terminate_process` protocol request to the server, and the handler [passes the specified exit code](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c… to the `terminate_process()` function. This function sets the `is_terminating` field of the process object [to a value of 1](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c?re…, and if the exit code is non-zero then it also [copies its value to each of the thread objects](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/proces… for the process. 3. The client process closes the pipe that it had been using to communicate with the server. 4. The server [detects the pipe close event](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.… and calls the `kill_process()` function, specifying a value of zero for the `violent_death` parameter. 5. The logic in the `kill_process()` function identifies this as a [normal termination on pipe close](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.…, and then subsequently calls the `kill_thread()` function to [kill each of the threads for the process](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/proces…. 6. The `kill_thread()` function [then calls](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/thread.c… `remove_process_thread()`, which [copies the exit code from the last thread object](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process… to the `exit_code` field of the process object. 7. The final value of the `exit_code` field is [reported when responding](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/pro… to `get_process_info` protocol requests, [as sent by](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/dlls/ntdll/unix/pr… `NtQueryInformationProcess()`. The abnormal process termination scenarios listed earlier will skip the `terminate_process` protocol request and immediately close the pipe. As a result, the `is_terminating` field of the process object will retain its default value of zero, and the `exit_code` field of each thread for the process will also remain at the default value of zero. Since the logic in `process_poll_event()` always treats a pipe close event as a non-violent termination, `remove_process_thread()` will simply copy the exit code value of zero from the last thread into the process object, and this will then be reported when querying the process exit code. **Fix details:** The fix modifies `process_poll_event()` to check the value of the `is_terminating` field of the process object, and to treat a pipe close event as a violent termination if the value of the field is zero. This triggers the alternative code path in `kill_process()` that calls `terminate_process()` and [specifies an exit code value of 1](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c?re…, which is copied to the thread objects and subsequently to the process object. In my testing, only the abnormal process termination scenarios listed above result in the value of the `is_terminating` field being zero when the pipe is closed. In all other scenarios, I have observed the value to be 1 when the pipe close event is detected. Non-abnormal scenarios tested include ordinary process completion with both zero and non-zero exit codes, crashes in Windows processes due to unhandled exceptions, and ending processes via the Wine implementation of Task Manager. -- v4: wineserver: Report non-zero exit code for abnormal process termination https://gitlab.winehq.org/wine/wine/-/merge_requests/3908

3 2

[PATCH v22 0/5] MR564: vkd3d-shader/ir: Transform clip/cull signature elements into an array.
by Conor McCarthy (＠cmccarthy) 09 Apr '24

09 Apr '24

-- v22: tests/d3d12: Test multiple clip distance inputs in test_clip_distance(). tests/d3d12: Use five clip distances for the multiple test in test_clip_distance(). vkd3d-shader/ir: Transform clip/cull outputs and patch constants into arrays. vkd3d-shader/ir: Transform clip/cull inputs into an array. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564

2 6

Re: [PATCH v3 0/1] MR761: tests/shader_runner: Report compilation errors on the block's starting line.
by Francisco Casas (＠fcasas) 08 Apr '24

08 Apr '24

> This seems a little fragile. I don't think it is that fragile, currently we handle directives in 3 points in run_shader_tests(): 1. The first switch, where we detect that we stopped reading the block because a new block starts or the file ended. 2. The reading of the tags at the beginning of new blocks. 3. The reading of individual lines using a second switch. We don't need to call update_line_number_context() in 1, and we always have to call it in 2 so we don't have to worry about forgetting to do so we add new functionalities. It is only in 3 that we have to remember to call update_line_number_context() for the switch cases when we want to update the line number context for each line instead of presenting it at the beginning of the block, but even if we forget, the error will be reported at the beginning of the block because of 2. > Could we just track the starting line for things touching "shader_source" and then setup/restore the test context in e.g. compile_shader()? Here is a patch for that proposal (how I see it), but I find it more complex. [0001-tests-shader-runner-Report-compilation-errors-on-the.patch](/uploads/02a5639e5c17c001d23e1d89105c949b/0001-tests-shader-runner-Report-compilation-errors-on-the.patch) -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/761#note_67306

1 0

[PATCH 0/2] MR5473: wow64: Mind generic xstate in a couple of missed places.
by Paul Gofman (＠gofman) 08 Apr '24

08 Apr '24

Fixes some wow64 mode regressions introduced by commit 29c73ee17335b30f3f49c8b3562742c6a35b482c ("ntdll: Support more xstate features."). That is actually covered by existing ntdll/tests/exception but there are a couple of tests (related to gs override) which crash those tests. Just in case, attaching an ad-hoc patch which comments out those and let the rest run (and succeed here in wow64 mode with these patches). Properly skipping those probably require Wine check I am afraid. [test.patch](/uploads/9db61a514f4242add75e96cb9493e8c0/test.patch) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5473

2 2

[PATCH 0/1] MR5472: winecoreaudio: Correctly handle devices whose UID contains non-ASCII characters.
by Brendan Shanks (＠bshanks) 08 Apr '24

08 Apr '24

This should fix audio issues for users with certain USB audio devices (possibly including the Creative Pebble V3 and RØDECaster Pro II). The Core Audio UID can contain non-ASCII characters and is converted to UTF-8 by `unix_get_endpoint_ids`. But we were using `CFStringGetLength` to calculate the resulting size, which returns the length in UTF-16 code pairs. This resulted in any UIDs containing non-ASCII characters being truncated, `dev_id_from_device` later failing, and audio not working. Instead use `CFStringGetBytes` to calculate the resulting UTF-8 size, and to do the conversion. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5472

2 1

[PATCH v3 0/10] MR768: Draft: vkd3d-shader/dxil: Tessellation part 2.
by Conor McCarthy (＠cmccarthy) 08 Apr '24

08 Apr '24

Goes atop !767. The last five commits belong here. -- v3: vkd3d-shader/dxil: Implement DX intrinsic OutputControlPointID. vkd3d-shader/dxil: Implement DX intrinsic DomainLocation. vkd3d-shader/dxil: Implement DX intrinsic StorePatchConstant. vkd3d-shader/dxil: Implement DX intrinsics LoadOutputControlPoint and LoadPatchConstant. vkd3d-shader/dxil: Support patch constant functions and signatures. vkd3d-shader/ir: Validate tessellation declarations. vkd3d-shader/dxil: Implement DX intrinsic PrimitiveID. vkd3d-shader/dxil: Load hull shader properties. vkd3d-shader/dxil: Load domain shader properties. tests/hlsl: Add a tessellation test. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/768

3 13

[PATCH v5 0/1] MR5188: Draft: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows.
by Tim Clem (＠tclem) 08 Apr '24

08 Apr '24

This is a change from the default behavior in macdrv for as long as it's existed, as far as I can tell. Previously, gaining a dock icon was a one-way path. However, that doesn't jive with the way taskbar entries work on Windows; if an app has no windows, it doesn't appear in the taskbar. This patch attempts to remedy cases where an app winds up with superfluous dock icons for exe's that no longer have windows (looking at you, basically every launcher and Steam). The major concern I can see with this is that if an app closes all of its windows but does not exit, there will be no indication that it is still running. Two thoughts on that: 1. That *should* be an anomalous case, such as the app hanging on exit. 2. Effectively the same behavior would happen on Windows. I would love to hear any other thoughts about this change. I'm open (though I would not prefer it) to defaulting the registry key to false if that would alleviate any concerns. -- v5: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows. https://gitlab.winehq.org/wine/wine/-/merge_requests/5188

2 1

[PATCH v5 0/1] MR333: vkd3d-shader/hlsl: Add refract() function.
by Nikolay Sivov (＠nsivov) 08 Apr '24

08 Apr '24

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v5: vkd3d-shader/hlsl: Add refract() function. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/333

2 2

[PATCH 0/1] MR770: tests/test-driver: Avoid "head" with negative line count.
by Henri Verbeet (＠hverbeet) 08 Apr '24

08 Apr '24

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/770

3 3