February 2025 - Wine-GitLab

[PATCH 0/1] MR7435: user32/tests: Fix monitor dpi awareness test.
by Bernhard Übelacker Feb. 27, 2025

Feb. 27, 2025

This adds brackets to make the comparison work and therefore the variable `scaled` gets set. Otherwise `scaled` and later `expect_width` and `expect_height` stays all zeros. https://test.winehq.org/data/patterns-tb-wine.html#user32:monitor This testbot run has this change applied: https://testbot.winehq.org/JobDetails.pl?Key=151521 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7435

2 2

[PATCH v5 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła Feb. 27, 2025

Feb. 27, 2025

Related Wine issue: https://bugs.winehq.org/show_bug.cgi?id=52714 I'm starting work on updating/extending Linux force feedback API and one of my goals is to expose the number and an array that contains the device's ffb-enabled axes. As I'm mainly working with USB PID driver, I already have a POC of obtaining this data. What prompted this is that currently Wine always creates virtual joysticks with two PID ffb axes. This causes issues with [Richard Burns Rally](https://github.com/ValveSoftware/Proton/issues/6702#issuecomment-267…, as this game incorrectly initializes a `CONSTANT_FORCE` effect with all the FFB axes that contain `DIDOI_FFACTUATOR` flag and then trying to update `cAxes` and `rgdwAxes` values which leads to `DIERR_INVALIDPARAM`. Now, this flag is set by wine while enumerating virtual device's axes and while `(axis index < FFB axes)`, flag is applied. This means, that every device which has FFB functionality and at least two axes, will report FFB on `X`, `Y`. While updated API would mean a lot of steering wheels would correctly report only 1 axis, a lot of USB PID wheels still include `X` and `Y` in their `AXES_ENABLE` and `DIRECTION` usages. This, again, would lead to broken FFB (in affected games). On Windows, there's a possibility of overwriting some joystick capabilities with registry entries, which ends up removing `DIDOI_FFACTUATOR` flag from a selected axis. This doesn't work in Wine. This MR allows Wine to add an arbitrary number (up to `PID_AXES_MAX`) of axes to the PID descriptor, based on the value of Haptic Axes from SDL or from Linux FF api in the future (I'm working on it). Additionally, to work around RBR and other games with similar, wrong FFB handling, I introduced a [hint](https://github.com/libsdl-org/SDL/issues/12341) to SDL that allows a dynamic overwrite of the number of haptic axes. For the Linux API, I'll figure out a nice way to override when the number of axes will be exposed. With these changes, I was able to successfully get force feedback on my Moza Racing R9 with all axes usable. With additional traces in the dinput code, I confirmed that with one axis defined in the PID descriptor, the game created a constant force effect with just one axis and `cAxes = 1`. -- v5: dinput/tests: Fix the 3-axis joystick descriptor winebus: Get the number of haptic axes from SDL winebus: Support creation of arbitrary number of PID axes https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

1 8

[PATCH v4 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła Feb. 27, 2025

Feb. 27, 2025

Related Wine issue: https://bugs.winehq.org/show_bug.cgi?id=52714 I'm starting work on updating/extending Linux force feedback API and one of my goals is to expose the number and an array that contains the device's ffb-enabled axes. As I'm mainly working with USB PID driver, I already have a POC of obtaining this data. What prompted this is that currently Wine always creates virtual joysticks with two PID ffb axes. This causes issues with [Richard Burns Rally](https://github.com/ValveSoftware/Proton/issues/6702#issuecomment-267…, as this game incorrectly initializes a `CONSTANT_FORCE` effect with all the FFB axes that contain `DIDOI_FFACTUATOR` flag and then trying to update `cAxes` and `rgdwAxes` values which leads to `DIERR_INVALIDPARAM`. Now, this flag is set by wine while enumerating virtual device's axes and while `(axis index < FFB axes)`, flag is applied. This means, that every device which has FFB functionality and at least two axes, will report FFB on `X`, `Y`. While updated API would mean a lot of steering wheels would correctly report only 1 axis, a lot of USB PID wheels still include `X` and `Y` in their `AXES_ENABLE` and `DIRECTION` usages. This, again, would lead to broken FFB (in affected games). On Windows, there's a possibility of overwriting some joystick capabilities with registry entries, which ends up removing `DIDOI_FFACTUATOR` flag from a selected axis. This doesn't work in Wine. This MR allows Wine to add an arbitrary number (up to `PID_AXES_MAX`) of axes to the PID descriptor, based on the value of Haptic Axes from SDL or from Linux FF api in the future (I'm working on it). Additionally, to work around RBR and other games with similar, wrong FFB handling, I introduced a [hint](https://github.com/libsdl-org/SDL/issues/12341) to SDL that allows a dynamic overwrite of the number of haptic axes. For the Linux API, I'll figure out a nice way to override when the number of axes will be exposed. With these changes, I was able to successfully get force feedback on my Moza Racing R9 with all axes usable. With additional traces in the dinput code, I confirmed that with one axis defined in the PID descriptor, the game created a constant force effect with just one axis and `cAxes = 1`. -- v4: dinput/tests: Fix the 3-axis joystick descriptor winebus: Get the number of haptic axes from SDL winebus: Support creation of arbitrary number of PID axes https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

1 8

[PATCH v5 0/7] MR5814: d3dx9, d3dcompiler: Do not emit implicit truncation warnings before version 42.
by Elizabeth Figura (＠zfigura) Feb. 27, 2025

Feb. 27, 2025

-- v5: d3dx9: Link versions 42 and 43 to the corresponding d3dcompiler DLL. d3dx9: Reimplement D3DXCompileShader() for versions before 42. d3dcompiler: Use D3DCompile2VKD3D() from vkd3d-utils. d3dcompiler: Use D3DPreprocess() from vkd3d-utils. vkd3d: Import vkd3d-utils. d3dx9/tests: Test implicit truncation warnings. d3dx9/tests: Define D3DX_SDK_VERSION=36 for d3dx9_36. https://gitlab.winehq.org/wine/wine/-/merge_requests/5814

3 8

Re: [PATCH v18 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by eric pouech (＠epo) Feb. 27, 2025

Feb. 27, 2025

On Thu Feb 27 10:01:08 2025 +0000, Joe Souza wrote: > OK, latest change should fix it. Key was adding ENABLE_PROCESSED_INPUT > in the call to SetConsoleMode. However, although this now allows Ctrl-C > to break out of dir /p prompts, the user is still required to press a > key to exit. This seems like a bug in wine to me. I haven't tried > similar code on Windows and I don't have time to investigate further at > the moment. 1) concerning the mode for waiting a key, * ENABLE_PROCESS_INPUT is already set... default mode is 0x1f7 (so all flags except ENABLE_WINDOW_INPUT and ENABLE_VIRTUAL_TERMINAL_PROCESSING) * so IMO you just need to clear the ENABLE_LINE_INPUT flag to get key press without wating for end of line 2) for ctrl-c handling * likely the ctrl-c is reported through the ctrl-c handler and it's not clear to me if native does break the read operation in this case and whether we should wait on both read operation & ctrl-c event -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_96106

1 0

[PATCH v14 0/2] MR6904: ntdll.dll: Update NtQueryDirectoryFile to align with current Windows behaviour
by Eugene McArdle (＠eugenemcardle) Feb. 27, 2025

Feb. 27, 2025

This PR updates the behaviour of `NtQueryDirectoryFile`, bringing it in line with current Windows behaviour. The need for this update was discovered when attempting to build the Unreal Engine with MSVC under Wine. In certain cases conditional include statements do not behave as expected, due to MSVC depending on undocumented behaviour of `NtQueryDirectoryFile`. We ran tests on multiple versions of Windows, and discovered that the behaviour has changed since the original Wine implementation, but the documentation has not. The source code for our test tool, and a set of results can be found [here](https://github.com/TensorWorks/NtQueryDirectoryFile-Test). As of Windows 8, calling `NtQueryDirectoryFile` with a re-used handle, a new mask, and setting the `RestartScan` flag to True, causes the cached results to be erased and a new scan to be performed with the updated mask. Currently, Wine performs as did earlier versions of Windows, where the changed mask is ignored, and the cache is reused. This can cause `NtQueryDirectoryFile` under Wine to falsely report that files exist, when they do not. This PR corrects this behaviour, invalidating the cache when required. Implementing this exposed further undocumented behaviour of `NtQueryDirectoryFile`, where a search for a non-existent file will return either `STATUS_NO_MORE_FILES` or `STATUS_NO_SUCH_FILE`, depending on whether or not the handle had been previously used regardless of the value of `RestartScan`. This was reflected in a `winetest` which allowed for the response to be either `STATUS_SUCCESS` or `STATUS_NO_MORE_FILES`. This patch also adds unit tests for the new behaviour of `NtQueryDirectoryFile`. These tests pass when running `winetest` under Windows, and under Wine with these changes in place, but they will fail under older versions of Wine. If run under older versions of Windows the test suite will detect that this functionality is not supported, and will not run the updated tests. -- v14: ntdll.dll: Update NtQueryDirectoryFile to align with current Windows behaviour ntdll: Test updated NtQueryDirectoryFile mask reset behaviour https://gitlab.winehq.org/wine/wine/-/merge_requests/6904

3 4

[PATCH 0/3] MR7368: winex11: Use XFixes to hide cursor before warping it.
by Rémi Bernon Feb. 27, 2025

Feb. 27, 2025

XWayland only allows warping the cursor if it is not visible. Fixes a regression from the periodic cursor sync removal. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7368

3 8

[PATCH 0/1] MR7411: wined3d: Avoid double-free of swapchain surface on error.
by Rémi Bernon Feb. 27, 2025

Feb. 27, 2025

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

3 4

[PATCH v2 0/9] MR7378: wined3d: NV12 textures, part 2/2.
by Elizabeth Figura (＠zfigura) Feb. 27, 2025

Feb. 27, 2025

-- v2: d3d11/tests: Extend NV12 tests. wined3d: Implement planar NV12 in the Vulkan renderer. wined3d: Enable KHR_sampler_ycbcr_conversion. wined3d: Implement planar Vulkan blits. wined3d: Implement planar Vulkan downloads. wined3d: Implement planar Vulkan uploads. wined3d: Separate a wined3d_texture_vk_download_plane() helper. wined3d: Separate a wined3d_texture_vk_upload_plane() helper. wined3d: Use a separate format value for d3d10+ NV12. https://gitlab.winehq.org/wine/wine/-/merge_requests/7378

3 11

[PATCH v8 0/2] MR7392: server: Don't ceil poll timeouts to the next millisecond if higher resolution timeouts are supported.
by William Horvath (＠whrvt) Feb. 27, 2025

Feb. 27, 2025

This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls). By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout). This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter. -- v8: server: Use epoll_pwait2 for the main loop on Linux. server: Use a high precision timespec directly for poll timeouts on supported platforms. https://gitlab.winehq.org/wine/wine/-/merge_requests/7392

3 6