- wine-gitlab - winehq.org

[PATCH v5 0/4] MR7634: ws2_32, server: Add initial support for AF_BTH sockets and BTHPROTO_RFCOMM.
by Vibhav Pant (＠vibhavp) 25 Mar '25

25 Mar '25

-- v5: ws2_32: Support bind for Bluetooth RFCOMM addresses. https://gitlab.winehq.org/wine/wine/-/merge_requests/7634

3 5

[PATCH v4 0/4] MR7634: ws2_32, server: Add initial support for AF_BTH sockets and BTHPROTO_RFCOMM.
by Vibhav Pant (＠vibhavp) 25 Mar '25

25 Mar '25

-- v4: ws2_32: Support bind for Bluetooth RFCOMM addresses. ws2_32: Add bind tests for Bluetooth RFCOMM sockets. server: Add support for creating Bluetooth RFCOMM sockets. https://gitlab.winehq.org/wine/wine/-/merge_requests/7634

2 4

[PATCH v3 0/4] MR7634: ws2_32, server: Add initial support for AF_BTH sockets and BTHPROTO_RFCOMM.
by Vibhav Pant (＠vibhavp) 25 Mar '25

25 Mar '25

-- v3: ws2_32: Support bind for Bluetooth RFCOMM addresses. ws2_32: Add bind tests for Bluetooth RFCOMM sockets. server: Add support for creating Bluetooth RFCOMM sockets. https://gitlab.winehq.org/wine/wine/-/merge_requests/7634

3 6

[PATCH v5 0/5] MR7630: winebth.sys part 7: Introduce support for authentication/pairing.
by Vibhav Pant (＠vibhavp) 25 Mar '25

25 Mar '25

Introduce infrastructure necessary to support receiving, sending and replying (to) Bluetooth authentication/pairing requests: - During startup, the Bluetooth driver now creates a "pairing agent" and registers it with BlueZ. The pairing agent is a DBus object implementing the `org.bluez.Agent1` interface (documented [here](https://github.com/bluez/bluez/blob/master/doc/org.bluez.Agent.rst)), which receives authentication requests from BlueZ. The pairing agent then forwards the request data to the PE driver, in form of a `WINEBLUETOOTH_EVENT_AUTH_EVENT` event. The agent is unregistered during driver shutdown. - Right now, the agent only supports Numeric Comparison pairing requests. - Create a new auxiliary device, `\??\WINEBTHAUTH` during driver startup. This device handles authentication functionality that is independent of radio PDOs on the system, which allows the userspace APIs to not track individual Bluetooth radio objects to implement authentication. `WINEBTHAUTH` right now serves two purposes: - Serve as the device object for which `GUID_WINEBTH_AUTHENTICATION_REQUEST` PnP events are broadcasted. This event is sent whenever the Bluetooth event loop in (`bluetooth_event_loop_thread_proc`) receives `WINEBLUETOOTH_EVENT_AUTH_EVENT`. The event's buffer contains a `struct winebth_authentication_request` value, which contains data relevant to the incoming auth request. - Handle the `IOCTL_WINEBTH_AUTH_REGISTER` IOCTL. This simply calls the [`RequestDefaultAgent` BlueZ method](https://github.com/bluez/bluez/blob/master/doc/org.bluez.AgentManag… right now, which asks BlueZ to send all incoming Bluetooth authentication requests to Wine's pairing agent (described above). This is not always strictly necessary, but is useful if there already is a default pairing agent set. - `WINEBTHAUTH` will also ultimately be in charge of responding to authentication requests, which I'll be adding in the next-ish MR(s). - Implement `BluetoothRegisterForAuthenticationEx` and `BluetoothUnregisterAuthentication`. Registration is done by invoking `IOCTL_WINEBTH_AUTH_REGISTER`, and then listening for `GUID_WINEBTH_AUTHENTICATION_REQUEST` events on a `HANDLE` to `\??\WINEBTHAUTH` using the newly added `CM_Register_Notifications`. To keep the MR from getting any larger, I have not included support for `BluetoothSendAuthenticationResponseEx`. That will likely be introduced in the future. -- v5: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

3 6

[PATCH v6 0/6] MR7608: server: Avoid delegating console waits to other objects.
by Elizabeth Figura (＠zfigura) 25 Mar '25

25 Mar '25

Some console objects currently do several unique things: * Delegate waits onto the queue of another object. This is not really a problem for in-process waits, since we can just return the sync object for the delegate. However, it's also unnecessary, adds to the complexity of the server logic, and is one out of one places where this is done. * Make the wait state dependent on the process. This is difficult to emulate with ntsync and would require creating separate server objects for each process, hacking into duplicate_handle. * Fail a wait entirely in certain circumstances. This is pretty much impossible to emulate with in-process waits. Although ntsync has been in development for some time, I have regrettably failed to notice these problems until now. Fortunately, none of these behaviours happen on modern Windows. Although I/O on unbound handles delegates to the console of the current process, the signaled state does not. As the tests here show, the signaled state of a handle depends on the active console of the process in which the handle was created. If that console no longer exists, the signaled state is no longer updated [with one rather inexplicable exception]. Crucially, in current Windows waits never fail, and the state of an object is the same across all process which hold handles to it. Therefore this patch brings our behaviour to closer match current Windows. In theory these are fds and should use default_fd_signaled(). However, the points at which the handles are signaled are completely different, and I/O does not trigger console handles to become signaled when it normally would. Therefore for the time being I've kept the code using custom signaled ops. There is one other oddity related to consoles, which is the existence of console_add_queue(), which seeks to lazily create an input thread when a console is first waited on. This is one out of two places, after this patch, when the wait process is hijacked (the other being message queues). Fortunately this is easy to handle for in-process synchronization objects, by queueing the ioctl from the callback used to retrieve the in-process synchronization object itself. -- v6: server: Track unbound output signaled state based on its original console. https://gitlab.winehq.org/wine/wine/-/merge_requests/7608

2 7

[PATCH 0/1] MR7660: libtiff: Provide zlib allocation functions.
by Nikolay Sivov (＠nsivov) 25 Mar '25

25 Mar '25

This is required when zlib with -DZ_SOLO is used. Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> Same change submitted upstream https://gitlab.com/libtiff/libtiff/-/merge_requests/706 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7660

2 1

[PATCH 0/8] MR7645: powrprof.dll: Move PowerGet/SetActiveScheme to powersetting.c
by Robert Lippmann (＠rlippmann) 25 Mar '25

25 Mar '25

These functions were split out in Windows Vista. This commit also updates the .spec with newer power related SDK calls. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7645

2 9

[PATCH v3 0/9] MR7659: windows.devices.bluetooth: Add implementation for IBluetoothStatics::GetDefaultAsync(), BluetoothAdapter.
by Vibhav Pant (＠vibhavp) 25 Mar '25

25 Mar '25

This MR adds a basic implementation for the BluetoothAdapter interface in Windows.Devices.Bluetooth, including winebth.sys support for getting properties associated with the radio's Low Energy capabilities. -- v3: windows.devices.bluetooth/tests: Add tests for IBluetoothAdapter. windows.devices.bluetooth: Implement BluetoothAdapter::IsAdvertisementOffloadSupported. windows.devices.bluetooth: Implement BluetoothAdapter::IsCentralRoleSupported. windows.devices.bluetooth: Implement BluetoothAdapter::IsPeripheralRoleSupported. windows.devices.bluetooth: Implement BluetoothAdapter::IsLowEnergySupported. winebth.sys: Implement IOCTL_WINEBTH_RADIO_GET_LE_INFO. winebth.sys: Fetch BLE-related properties for BlueZ adapter objects as well. windows.devices.bluetooth: Implement IBluetoothAdapter::get_DeviceId(). windows.devices.bluetooth: Implement IBluetoothAdapterStatics::GetDefaultAsync(). https://gitlab.winehq.org/wine/wine/-/merge_requests/7659

2 9

[PATCH v2 0/8] MR7659: windows.devices.bluetooth: Add implementation for IBluetoothStatics::GetDefaultAsync(), BluetoothAdapter.
by Vibhav Pant (＠vibhavp) 25 Mar '25

25 Mar '25

This MR adds a basic implementation for the BluetoothAdapter interface in Windows.Devices.Bluetooth, including winebth.sys support for getting properties associated with the radio's Low Energy capabilities. -- v2: windows.devices.bluetooth: Implement BluetoothAdapter::IsAdvertisementOffloadSupported. windows.devices.bluetooth: Implement BluetoothAdapter::IsCentralRoleSupported. windows.devices.bluetooth: Implement BluetoothAdapter::IsPeripheralRoleSupported. windows.devices.bluetooth: Implement BluetoothAdapter::IsLowEnergySupported. winebth.sys: Implement IOCTL_WINEBTH_RADIO_GET_LE_INFO. winebth.sys: Fetch BLE-related properties for BlueZ adapter objects as well. https://gitlab.winehq.org/wine/wine/-/merge_requests/7659

2 8

[PATCH 0/8] MR7659: windows.devices.bluetooth: Add implementation for IBluetoothStatics::GetDefaultAsync(), BluetoothAdapter.
by Vibhav Pant (＠vibhavp) 25 Mar '25

25 Mar '25

This MR adds a basic implementation for the BluetoothAdapter interface in Windows.Devices.Bluetooth, including winebth.sys support for getting properties associated with the radio's Low Energy capabilities. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7659

2 8

[PATCH v3 0/1] MR7657: win32u: Store window styles in a DWORD (Coverity).
by Sven Baars (＠sbaars) 25 Mar '25

25 Mar '25

`WS_POPUP` for instance is `0x80000000`, which overflows a `LONG`. Coverity complained about this. The return type of `get_window_long()` already was `DWORD`. -- v3: win32u: Store window styles in a UINT (Coverity). https://gitlab.winehq.org/wine/wine/-/merge_requests/7657

4 4

[PATCH v2 0/1] MR7657: win32u: Store window styles in a DWORD (Coverity).
by Sven Baars (＠sbaars) 25 Mar '25

25 Mar '25

`WS_POPUP` for instance is `0x80000000`, which overflows a `LONG`. Coverity complained about this. The return type of `get_window_long()` already was `DWORD`. -- v2: win32u: Store window styles in a DWORD (Coverity). https://gitlab.winehq.org/wine/wine/-/merge_requests/7657

3 2

[PATCH 0/4] MR7658: winebus: Support creation of dynamic number of PID axes.
by Rémi Bernon (＠rbernon) 25 Mar '25

25 Mar '25

Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/7422 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7658

2 5

[PATCH 0/1] MR7646: winegcc: Don't call strendswith() with a NULL output_name.
by Aida Jonikienė (＠DodoGTA) 25 Mar '25

25 Mar '25

Fixes: e3bf6e5e773 ("winegcc: Store all the boolean options in global variables.") Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58006 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7646

3 4

[PATCH v9 0/14] MR7516: Server-side thread priorities implementation (Part 3)
by Marc-Aurel Zent (＠mzent) 25 Mar '25

25 Mar '25

This is the continuation of https://gitlab.winehq.org/wine/wine/-/merge_requests/7317. There are a lot of smaller commits (some even no-op renames), because there are some inconsistencies in the codebase currently of what an NT thread priority vs a base thread priority should be (or even constant names being wrong), and I hope that this clears that up a bit. I tried making the commits as atomic as possible. I hope this is fine... There are still a few tiny details missing, like boosting and `KeSetPriorityThread` and friends, which are either stubs or not correctly working as well and have been moved to the next part. I wrote a pretty extensive test for all this too, since pretty much none of how this works is documented (or even misrepresented quite often). For testing, thread priority boosting has been disabled in order to make the behavior on Windows not flaky and dynamic. In fact, on Windows, there is some thread priority boost decay going on after the message has been processed and other mechanisms. The `last` field of `get_thread_info` reply was moved to a flag in order to make space for the thread base priority, since it is already at the limit of 64 bytes. -- v9: ntdll/tests: Add tests for process and thread priority. server, ntdll: Fetch both process priority and base_priority. server: Add process base priority helper. kernelbase: Use ProcessPriorityClass info class in GetPriorityClass. kernelbase: Use correct priority in GetThreadPriority. server, ntdll: Fetch both thread priority and base_priority. server, ntdll: Move last thread information to get_thread_info flags. ntdll: Implement ThreadPriority class in NtSetInformationThread. server: Implement setting thread priority directly. server: Add set_thread_priority helper. server: Rename thread priority to base_priority. server: Rename base_priority to effective_priority in apply_thread_priority. server: Infer process priority class in set_thread_priority. https://gitlab.winehq.org/wine/wine/-/merge_requests/7516

2 17

[PATCH 0/1] MR7657: win32u: Store window styles in a DWORD (Coverity).
by Sven Baars (＠sbaars) 25 Mar '25

25 Mar '25

`WS_POPUP` for instance is `0x80000000`, which overflows a `LONG`. Coverity complained about this. The return type of `get_window_long()` already was `DWORD`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7657

2 1

[PATCH v6 0/6] MR6866: ntdll: On macOS x86_64, swap GSBASE between the TEB and macOS TSD when entering/leaving PE code.
by Brendan Shanks (＠bshanks) 25 Mar '25

25 Mar '25

x86_64 Windows and macOS both use `%gs` to access thread-specific data (Windows TEB, macOS TSD). To date, Wine has worked around this conflict by filling the most important TEB fields (`0x30`/`Self`, `0x58`/`ThreadLocalStorage`) in the macOS TSD structure (Apple reserved the fields for our use). This was sufficient for most Windows apps. CrossOver's Wine had an additional hack to handle `0x60`/`ProcessEnvironmentBlock`, and binary patches for certain CEF binaries which directly accessed `0x8`/`StackBase`. Additionally, Apple's libd3dshared could activate a special mode in Rosetta 2 where code executing in certain regions would use the Windows TEB when accessing `%gs`. Now that the PE separation is complete, GSBASE can be swapped when entering/exiting PE code. This is done in the syscall dispatcher, unix-call dispatcher, and for user-mode callbacks. GSBASE also needs to be set to the macOS TSD when entering signal handlers (in `init_handler()`), and then restored to the Windows TEB when exiting (in `leave_handler()`). Some changes to the syscall dispatcher were needed to ensure that the TEB is not accessed through `%gs` while on the kernel stack (since a SIGUSR1 while on the kernel stack will result in GSBASE being set to the TSD). --- I've tested this successfully on macOS 15 (Apple Silicon and Intel) and macOS 10.13 with several apps and games, including the `cefclient.exe` CEF sample. Encouragingly, in some simple tests I didn't see a noticeable performance regression from this MR. There are drawbacks though: - libraries which jump directly from PE code into Unix code (expecting that %gs is always pointing to the macOS TSD) will crash. Notable examples are D3DMetal and DXMT. These will need to be changed to use Unix calls. - If Windows code uses the `syscall` instruction directly, the stack pointer likely needs to be valid (which is probably not true on Windows). This is due to the syscall dispatcher saving registers onto the user stack and having to call `_thread_set_tsd_base`. I can't say I've ever seen direct syscalls done with an invalid `%rsp`, but it seems like something anticheat code might do. --- macOS does not have a public API for setting GSBASE, but the private `_thread_set_tsd_base()` works and was added in macOS 10.12. `_thread_set_tsd_base()` is a small thunk that sets `%esi`, `%eax`, and does the `syscall`: https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57…. The syscall instruction itself clobbers `%rcx` and `%r11`. I've tried to save as few registers as possible when calling `_thread_set_tsd_base()`, but there may be room for improvement there. --- I also tested an alternate implementation strategy for this which took advantage of the expanded "full" thread state which is passed to signal handlers when a process has set a user LDT. The full thread state includes GSBASE, so GSBASE is set back to whatever is in the sigcontext on return (like every other field in the context). This would avoid needing to explicitly reset GSBASE in `leave_handler()`. This strategy was simpler, but I'm not using it for 2 reasons: - the "full" thread state is only available starting with macOS 10.15, and we still support 10.13. - more crucially, Rosetta 2 doesn't seem to correctly implement the GS.base field of the full thread state. It's set to 0 on entry, and isn't read on exit. -- v6: ntdll: Remove x86_64 Mac-specific TEB access workarounds that are no longer needed. ntdll: On macOS x86_64, swap GSBASE between the TEB and macOS TSD when entering/leaving PE code. ntdll: Set %rsp to be inside syscall_frame before accessing %gs in x86_64 syscall dispatcher. https://gitlab.winehq.org/wine/wine/-/merge_requests/6866

5 15

[PATCH v15 0/1] MR7607: win32u: Add stub for NtUserSetAdditionalForegroundBoostProcesses.
by Louis Lenders (＠xe) 25 Mar '25

25 Mar '25

Microsoft Edge worked if windows version is set to win8.1 (or win7) but now crashes in current wine due to this unimplemented function. This patch makes it work again in win8.1 mode; (It's still broken in win10 mode, see https://bugs.winehq.org/show_bug.cgi?id=56378 for more info) -- v15: win32u: Add stub for NtUserSetAdditionalForegroundBoostProcesses. https://gitlab.winehq.org/wine/wine/-/merge_requests/7607

2 1

[PATCH v14 0/2] MR7607: win32u: Add stub for NtUserSetAdditionalForegroundBoostProcesses.
by Louis Lenders (＠xe) 25 Mar '25

25 Mar '25

Microsoft Edge worked if windows version is set to win8.1 (or win7) but now crashes in current wine due to this unimplemented function. This patch makes it work again in win8.1 mode; (It's still broken in win10 mode, see https://bugs.winehq.org/show_bug.cgi?id=56378 for more info) -- v14: v2: handle handles inside array and rename variable. win32u: Add stub for NtUserSetAdditionalForegroundBoostProcesses. https://gitlab.winehq.org/wine/wine/-/merge_requests/7607

2 2

[PATCH v4 0/5] MR7540: kernel32/tests: Add tests for maximum path length limitation.
by Yongjie Yao (＠yaoyongjie) 25 Mar '25

25 Mar '25

In CopyFileEx, and DeleteFile functions, by default, the file name and path are limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, need prepend "\\\\?\\" to the path. -- v4: kernelbase: Limit the maximum path length for DeleteFile. kernelbase: Fix DeleteFileA doesn't support long path. kernelbase: Limit the maximum path length for filesystem. ntdll: Load the value of longPathAware from manifest. kernel32/tests: Add tests for maximum path length limitation. https://gitlab.winehq.org/wine/wine/-/merge_requests/7540

2 7

[PATCH v2 0/3] MR7653: windowscodecs/metadata: Always initialize handler pointer.
by Nikolay Sivov (＠nsivov) 25 Mar '25

25 Mar '25

In case of empty block reader we currently return uninitialized pointer that is accessed later. Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: windowscodecs/tests: Add some tests for the App0 reader. https://gitlab.winehq.org/wine/wine/-/merge_requests/7653

2 4

[PATCH v2 0/2] MR7649: mf/tests: Add timestamp tests for audio decoders.
by Brendan McGrath (＠redmcg) 25 Mar '25

25 Mar '25

This MR is similar to MR !7563 but targets the MFT audio decoders rather than the video decoders. -- v2: mf/tests: Add timestamp tests for wma audio decoder. mf/tests: Add timestamp tests for aac audio decoder. https://gitlab.winehq.org/wine/wine/-/merge_requests/7649

2 5

[PATCH 0/3] MR7653: windowscodecs/metadata: Always initialize handler pointer.
by Nikolay Sivov (＠nsivov) 25 Mar '25

25 Mar '25

In case of empty block reader we currently return uninitialized pointer that is accessed later. Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7653

3 4

[PATCH v2 0/2] MR7647: Add single point support for GdipGetPathWorldBounds
by Bartosz Kosiorek (＠gang65) 25 Mar '25

25 Mar '25

-- v2: gdiplus: Add single point support for GdipGetPathWorldBounds gdiplus/test: add tests for GdipGetPathWorldBounds with single point https://gitlab.winehq.org/wine/wine/-/merge_requests/7647

3 5

[PATCH v3 0/5] MR7540: kernel32/tests: Add tests for maximum path length limitation.
by Yongjie Yao (＠yaoyongjie) 25 Mar '25

25 Mar '25

In CopyFileEx, and DeleteFile functions, by default, the file name and path are limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, need prepend "\\\\?\\" to the path. -- v3: kernelbase: Limit the maximum path length for DeleteFile. kernelbase: Fix DeleteFileA doesn't support long path. kernelbase: Limit the maximum path length for filesystem. user32: Load the value of longPathAware from manifest. kernel32/tests: Add tests for maximum path length limitation. https://gitlab.winehq.org/wine/wine/-/merge_requests/7540

3 8

[PATCH v5 0/1] MR7642: server: Fall back to epoll_wait if epoll_pwait2 isn't available at run-time.
by William Horvath (＠whrvt) 24 Mar '25

24 Mar '25

This fixes a real problem and improves behavior at the same time. - Fixes: hanging when trying to run Wine built with epoll_pwait2 headers available but epoll_pwait2 is missing in the run-time kernel (i.e. build 5.11->run 5.10) - Improvement: bring the improved timeout resolution to Wine builds which didn't have epoll_pwait2 at compile time, if the run-time kernel supports it (i.e. build 5.10->run 6.14) This last point is especially important in my opinion, as it applies to official Proton builds. Proton is (currently) built in Debian 11 with kernel 5.10, but SteamOS is a moving target with a much newer kernel version being used to run these Wine builds. These builds use the lower resolution timeouts if epoll_pwait2 is only checked for at compile-time, when it can cheaply and easily be done at run-time instead. Fixes: 87ca5db40e2c1b37423bdc25101a5c5e39e67e6f An alternative to !7640 that kills two birds with one stone. -- v5: server: Use dlsym() to check for epoll_pwait2 at run-time. https://gitlab.winehq.org/wine/wine/-/merge_requests/7642

4 6

[PATCH v5 0/6] MR7608: server: Avoid delegating console waits to other objects.
by Elizabeth Figura (＠zfigura) 24 Mar '25

24 Mar '25

Some console objects currently do several unique things: * Delegate waits onto the queue of another object. This is not really a problem for in-process waits, since we can just return the sync object for the delegate. However, it's also unnecessary, adds to the complexity of the server logic, and is one out of one places where this is done. * Make the wait state dependent on the process. This is difficult to emulate with ntsync and would require creating separate server objects for each process, hacking into duplicate_handle. * Fail a wait entirely in certain circumstances. This is pretty much impossible to emulate with in-process waits. Although ntsync has been in development for some time, I have regrettably failed to notice these problems until now. Fortunately, none of these behaviours happen on modern Windows. Although I/O on unbound handles delegates to the console of the current process, the signaled state does not. As the tests here show, the signaled state of a handle depends on the active console of the process in which the handle was created. If that console no longer exists, the signaled state is no longer updated [with one rather inexplicable exception]. Crucially, in current Windows waits never fail, and the state of an object is the same across all process which hold handles to it. Therefore this patch brings our behaviour to closer match current Windows. In theory these are fds and should use default_fd_signaled(). However, the points at which the handles are signaled are completely different, and I/O does not trigger console handles to become signaled when it normally would. Therefore for the time being I've kept the code using custom signaled ops. There is one other oddity related to consoles, which is the existence of console_add_queue(), which seeks to lazily create an input thread when a console is first waited on. This is one out of two places, after this patch, when the wait process is hijacked (the other being message queues). Fortunately this is easy to handle for in-process synchronization objects, by queueing the ioctl from the callback used to retrieve the in-process synchronization object itself. -- v5: server: Track unbound output signaled state based on its original console. server: Track unbound input signaled state based on its original console. server: Allow waiting on an orphaned screen buffer. server: Use a list of screen buffers per console. server: Fail to create an unbound input/output when there is no console. kernel32/tests: Add more tests for orphaned console handles. https://gitlab.winehq.org/wine/wine/-/merge_requests/7608

2 6

[PATCH v3 0/5] MR7636: d3dx9: Implement saving to DDS files in D3DXSaveTextureToFileInMemory().
by Connor McAdams (＠cmcadams) 24 Mar '25

24 Mar '25

The last of the saving patches for d3dx9. :) -- v3: d3dx9: Add support for saving IDirect3DVolumeTexture9 textures to DDS files in D3DXSaveTextureToFileInMemory(). d3dx9: Add support for saving IDirect3DCubeTexture9 textures to DDS files in D3DXSaveTextureToFileInMemory(). d3dx9: Add support for saving IDirect3DTexture9 textures to DDS files in D3DXSaveTextureToFileInMemory(). d3dx9/tests: Add more tests for saving textures to DDS files. https://gitlab.winehq.org/wine/wine/-/merge_requests/7636

3 12

Re: [PATCH v2 0/1] MR7637: wow64: skip memcpy for null pointer - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7637

1 0

Re: [PATCH v2 0/1] MR7625: winex11: Use the state tracker for the desktop window _NET_WM_STATE. - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7625

1 0

Re: [PATCH v2 0/1] MR7626: winex11: Use the current state when deciding how to reply to WM_TAKE_FOCUS. - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7626

1 0

Re: [PATCH v3 0/2] MR7619: comctl32: Implement EVENT_OBJECT_VALUECHANGE for edit controls. - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7619

1 0

Re: [PATCH v3 0/1] MR7640: server: Fall back to epoll_wait if epoll_pwait2 doesn't work - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7640

1 0

Re: [PATCH v2 0/1] MR7651: msvcrt: Update file position in _flsbuf() in append mode. - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7651

1 0

Re: [PATCH v2 0/5] MR7632: server, ntdll: Return the correct base/actual thread/process priority. - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7632

1 0

Re: [PATCH v3 0/1] MR7622: comctl32: Avoid segfault in PROPSHEET_DoCommand when psInfo is NULL. - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7622

1 0

Re: [PATCH v2 0/4] MR7562: wined3d: Move FFP extra states away from STATE_RENDER, part 1/4. - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7562

1 0

Re: [PATCH v2 0/4] MR7648: user32/tests: Add some tests for current selection with LBS_NOSEL. - approved
by Alexandre Julliard (＠julliard) 24 Mar '25

24 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7648

1 0

[PATCH v38 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v38: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 9

[PATCH 0/8] MR7656: wined3d: Two unrelated fixes.
by Elizabeth Figura (＠zfigura) 24 Mar '25

24 Mar '25

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

2 8

[PATCH v37 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v37: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v13 0/1] MR7607: Draft: win32u: Add stub for NtUserSetAdditionalForegroundBoostProcesses.
by Louis Lenders (＠xe) 24 Mar '25

24 Mar '25

Microsoft Edge worked if windows version is set to win8.1 (or win7) but now crashes in current wine due to this unimplemented function. This patch makes it work again in win8.1 mode; (It's still broken in win10 mode, see https://bugs.winehq.org/show_bug.cgi?id=56378 for more info) -- v13: win32u: Add stub for NtUserSetAdditionalForegroundBoostProcesses. https://gitlab.winehq.org/wine/wine/-/merge_requests/7607

3 2

[PATCH v36 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v36: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v35 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v35: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH 0/2] MR7649: mf/tests: Add timestamp tests for audio decoders.
by Brendan McGrath (＠redmcg) 24 Mar '25

24 Mar '25

This MR is similar to MR !7563 but targets the MFT audio decoders rather than the video decoders. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7649

3 5

[PATCH v11 0/6] MR7569: mfplat/tests: Add tests for Byte Stream Timestamps.
by Brendan McGrath (＠redmcg) 24 Mar '25

24 Mar '25

This MR adds tests to `mfplat` to illustrate the timestamp values output on the samples for the respective Byte Stream handlers. I have also included a fix for a bug in `winegstreamer` (and copied to `mfsrcsnk`) where a `NULL` value for the `pguidTimeFormat` parameter in `IMFMediaSource::Start` causes a segmentation fault. On Windows this is allowed. It is included in this MR as the `mfplat` tests pass NULL (so without this fix, the tests crash). -- v11: mfplat/tests: Add tests for Byte Stream Timestamps. mfsrcsnk: Allow NULL for time_format. winegstreamer: Allow NULL for time_format. mfplat/tests: Fix leak of media source. mfplat/tests: Fix leak of media events. https://gitlab.winehq.org/wine/wine/-/merge_requests/7569

3 8

[PATCH v34 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v34: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v33 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v33: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v32 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v32: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v31 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v31: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v5 0/1] MR7339: ntdll: implement create_logical_proc_info on FreeBSD.
by Damjan Jovanovic (＠dj) 24 Mar '25

24 Mar '25

Add Expat as a dependency, and use it to parse the XML returned from FreeBSD's kern.sched.topology_spec sysctl. -- v5: ntdll: implement create_logical_proc_info on FreeBSD. https://gitlab.winehq.org/wine/wine/-/merge_requests/7339

3 5

[PATCH v30 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v30: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v29 0/10] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v29: Little fix https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 10

[PATCH v28 0/9] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 24 Mar '25

24 Mar '25

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`. -- v28: Change few things around dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 9

[PATCH 0/1] MR7652: ntdll: Treat XDG_DATA_DIRS as special env variable.
by Louis Lenders (＠xe) 24 Mar '25

24 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49987 GTK apps seem to use this to find path to schemas, like Meld: https://download.gnome.org/binaries/win32/meld/3.22/Meld-3.22.2-mingw.msi which doesn't start at all without this patch. More info in https://bugs.winehq.org/show_bug.cgi?id=49987. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7652

3 3

Re: [PATCH v11 0/6] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Jinoh Kang (＠iamahuman) 24 Mar '25

24 Mar '25

On Mon Mar 24 15:33:24 2025 +0000, Jinoh Kang wrote: > 64-bit volatile stores are not atomic on `__i386__`. I'd advise to just use WriteRelease64. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7610#note_98867

1 0

[PATCH v2 0/5] MR7636: d3dx9: Implement saving to DDS files in D3DXSaveTextureToFileInMemory().
by Connor McAdams (＠cmcadams) 24 Mar '25

24 Mar '25

The last of the saving patches for d3dx9. :) -- v2: d3dx9: Add support for saving IDirect3DVolumeTexture9 textures to DDS files in D3DXSaveTextureToFileInMemory(). d3dx9: Add support for saving IDirect3DCubeTexture9 textures to DDS files in D3DXSaveTextureToFileInMemory(). d3dx9: Add support for saving IDirect3DTexture9 textures to DDS files in D3DXSaveTextureToFileInMemory(). d3dx9/tests: Add more tests for saving textures to DDS files. d3dx9/tests: Add a test for reading back a texture saved as D3DXIFF_JPG. https://gitlab.winehq.org/wine/wine/-/merge_requests/7636

3 14

Re: [PATCH v11 0/6] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Jinoh Kang (＠iamahuman) 24 Mar '25

24 Mar '25

Jinoh Kang (@iamahuman) commented about server/user.c: > + * need atomic intrinsics to guarantee that. */ > +#if defined(__i386__) || defined(__x86_64__) > + *ptr = value; > +#else > + __atomic_store_n(ptr, value, __ATOMIC_SEQ_CST); > +#endif > +} > + > +static void atomic_store_u64(volatile unsigned __int64 *ptr, unsigned __int64 value) > +{ > + /* on x86 there should be total store order guarantees, so volatile is > + * enough to ensure the stores aren't reordered by the compiler, and then > + * they will always be seen in-order from other CPUs. On other archs, we > + * need atomic intrinsics to guarantee that. */ > +#if defined(__i386__) || defined(__x86_64__) > + *ptr = value; 64-bit volatile stores are not atomic on `__i386__`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7610#note_98862

1 0

[PATCH v5 0/13] MR6944: Draft: winex11: Workaround various window manager bugs.
by Rémi Bernon (＠rbernon) 24 Mar '25

24 Mar '25

This workarounds KWin and Mutter window manager bugs/fanciness. The KWin bug is with maximized windows getting broken after sending a configure request, and which fix has been merged upstream already. The Mutter issue is unlikely to be fixed upstream, at least not its specific behavior, and we would instead better handle it as well as we can. -- v5: winex11: Workaround KWin bug with maximized windows. winex11: Set _NET_WM_USER_TIME to 0 to implement SWP_NOACTIVATE. winex11: Keep track of the SWP flags to be used when mapping windows. winex11: Keep _NET_WM_USER_TIME on the individual windows. winex11: Workaround Mutter bug when changing decorations. winex11: Update _MOTIF_WM_HINTS after _NET_WM_STATE and config. winex11: Avoid creating windows with override-redirect flag set. winex11: Track _MOTIF_WM_HINTS property in the state tracker. winex11: Introduce a new handle_state_change helper. winex11: Ignore transient state changes in other processes. winex11: Give focus to the expected window when unampping with focus. winex11: Use the current state when deciding how to reply to WM_TAKE_FOCUS. winex11: Use the state tracker for the desktop window _NET_WM_STATE. https://gitlab.winehq.org/wine/wine/-/merge_requests/6944

3 17

[PATCH 0/4] MR7648: user32/tests: Add some tests for current selection with LBS_NOSEL.
by Nikolay Sivov (＠nsivov) 24 Mar '25

24 Mar '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7648

3 5

[PATCH v10 0/6] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 24 Mar '25

24 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v10: win32u: Use the session shared object for user handle entries. win32u: Use the session shared object to implement is_window. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. include: Implement ReadAcquire64. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 6

[PATCH v7 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Patrick Hibbs (＠hibbsncc1701) 24 Mar '25

24 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46012 Signed-off-by: Patrick Hibbs <hibbsncc1701(a)gmail.com> -- v7: d3dx9/tests: Implement tests for d3dx_effect_SetRawValue(). d3dx9: Implement d3dx_effect_SetRawValue https://gitlab.winehq.org/wine/wine/-/merge_requests/979

5 13

[PATCH v9 0/6] MR7610: win32u: Create a shared object for user handle entries.
by Rémi Bernon (＠rbernon) 24 Mar '25

24 Mar '25

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v9: win32u: Use the session shared object for user handle entries. win32u: Use the session shared object to implement is_window. server: Move the user object handle table to the shared memory. server: Use NTUSER_OBJ constants for user object types. server: Create a shared memory object for the global session. include: Implement ReadAcquire64. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 6

[PATCH 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) 24 Mar '25

24 Mar '25

Follow-up of !2786, which appears to have been abandoned. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

2 7

[PATCH 0/4] MR7562: wined3d: Move FFP extra states away from STATE_RENDER, part 1/4.
by Elizabeth Figura (＠zfigura) 24 Mar '25

24 Mar '25

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

3 5

[PATCH 0/1] MR7651: msvcrt: Update file position in _flsbuf() in append mode.
by Piotr Caban (＠piotr) 24 Mar '25

24 Mar '25

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

2 1

[PATCH 0/6] MR7561: wined3d: Vulkan H.264 decode, part 3/3.
by Elizabeth Figura (＠zfigura) 24 Mar '25

24 Mar '25

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

3 7

[PATCH v2 0/1] MR7623: Draft: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 24 Mar '25

24 Mar '25

This MR modifies winegstreamer to match Windows behaviour in that: 1. the video decoders will output the PTS and duration of the input sample (if provided); and 2. the WMV decoder will set any value not provided to zero It also adds support for supplying a DTS value to the MFTs. I've marked this as draft as it fixes the tests in MR !7563 (in addition to fixing some existing `test_wmv_decoder` tests). Also, as demonstrated in MR !7569, our demuxers output different timestamps to Windows. This change will result in those different timestamps being forwarded from the decoder. So we may also want to address that difference prior to accepting this MR. -- v2: winegstreamer: Use provided PTS and duration in video_decoder. https://gitlab.winehq.org/wine/wine/-/merge_requests/7623

2 2

[PATCH v27 0/7] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v27: https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 7

[PATCH v26 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v26: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v25 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v25: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v24 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v24: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v23 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v23: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v22 0/11] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v22: edit https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 11

[PATCH v20 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v20: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v19 0/10] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v19: Update https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 10

[PATCH v18 0/9] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v18: Maybe fix tests https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 9

[PATCH v17 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v17: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v16 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v16: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH 0/2] MR7647: Add single point support for GdipGetPathWorldBounds
by Bartosz Kosiorek (＠gang65) 23 Mar '25

23 Mar '25

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

2 2

[PATCH v15 0/11] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v15: Update https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 11

[PATCH v13 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v13: dinput/tests: Add tests for 6-axis ff joystick https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v12 0/8] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v12: dinput/tests: Add tests for 6-axis ff joystick winebus: Get the number of haptic axes from SDL winebus: Support creation of arbitrary number of PID axes winebus: Use physical->num_axes to compute effect_update report size winebus: Store the number of FFB axes of a unix_device winebus: Use PID_AXES_MAX in unix_private.h dinput: Use PID_AXES_MAX in joystick_hid for axes, directions, conditions hid: Define the max number of supported PID axes https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 8

[PATCH v11 0/11] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v11: Try fixing some tests https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 11

[PATCH v10 0/10] MR7422: winebus/dinput: Support arbitrary number of axes in the virtual PID descriptor
by Tomasz Pakuła (＠TomaszPakula) 23 Mar '25

23 Mar '25

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`. -- v10: Update expected reports len https://gitlab.winehq.org/wine/wine/-/merge_requests/7422

2 10

[PATCH v2 0/1] MR7622: comctl32: Avoid segfault in PROPSHEET_DoCommand when psInfo is NULL.
by Yuri Hérouard (＠yurih) 23 Mar '25

23 Mar '25

Fixes https://bugs.winehq.org/show_bug.cgi?id=57987. In the case of that issue, it does not crash anymore, and the settings are now correctly saved. -- v2: comctl32: Avoid segfault in PROPSHEET_DoCommand when psInfo is NULL. https://gitlab.winehq.org/wine/wine/-/merge_requests/7622

4 4

[PATCH v10 0/7] MR7111: Draft: support building Wine with LTO
by Konstantin Demin (＠rockdrilla) 23 Mar '25

23 Mar '25

work is still in progress. todo: - ensure that all affected sources (i.e. C sources with any kind of assembly) are listed in either way for all architectures - test Wine built with LTO relevant bug reports: - https://bugs.winehq.org/show_bug.cgi?id=41712 - https://bugs.winehq.org/show_bug.cgi?id=51051 -- v10: LTO quirks configure: enable building Wine with LTO makedep: support skipping/disabling LTO makedep: support LTO builds winegcc: support LTO builds winebuild: support LTO builds tools: helper functions for LTO builds https://gitlab.winehq.org/wine/wine/-/merge_requests/7111

2 7

[PATCH v2 0/1] MR7640: server: Fall back to epoll_wait if epoll_pwait2 doesn't work
by Alfred Agrell (＠Alcaro) 23 Mar '25

23 Mar '25

Fixes hangs if Wine is built with newer headers than kernel -- v2: server: Fall back to epoll_wait if epoll_pwait2 doesn't work. https://gitlab.winehq.org/wine/wine/-/merge_requests/7640

5 6

[PATCH v13 0/1] MR6199: winewayland.drv: Fix alt-tabbing out opening the alt key menu
by Yuri Hérouard (＠yurih) 23 Mar '25

23 Mar '25

Fix the wayland side of https://bugs.winehq.org/show_bug.cgi?id=55336 ### ~~Exit menu key by default:~~ That's the actual behavior, any non-special key will exit the menu key, and be sent to the client. I was also wondering if we should add `menu_sys_key = f10_key = 0;` when receiving a `WM_ACTIVATE` in `win32u/defwnd.c`'s `default_window_proc` but I guess not ? ### ~~Fix repeated key for no reason:~~ For some reason when ALT is pressed, it is spammed and thus spams SYS_COMMAND. This fix that, but I don't know what I am doing here. I don't see any repeating key spamming with winex11 but I could be wrong. However alt/SYS_COMMAND should not be repeated. That wasn't happening with winex11.drv. ### Fix release_all_keys modifier filtering: That was the main reason why alt-tab leads to the menu key, NtUserGetAsyncKeyboardState also uses left and right system keys. -- v13: winewayland: Fix release_all_keys's modifier filtering. https://gitlab.winehq.org/wine/wine/-/merge_requests/6199

2 1

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Nikolay Sivov (＠nsivov) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:56:23 2025 +0000, Robert Lippmann wrote: > Sorry, I'm new to this :disappointed: > What would happen if it was just a stub? > I also figured, while I was there, I might as well implement it... What would happen depends on an application that you run. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98772

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 23:08:45 2025 +0000, Robert Lippmann wrote: > Oops. Well, they all actually just return errors. > Which is what I think the problem is. > Should I close this and just submit a patch that implements them? > I'd probably do it simpler with just a hack with a static variable anyway. Or should I keep the registry related code? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98771

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:59:02 2025 +0000, Nikolay Sivov wrote: > All 4 functions you mentioned are already present in current code, in a > form of stubs. So you don't need to update the spec file. Oops. Well, they all actually just return errors. Which is what I think the problem is. Should I close this and just submit a patch that implements them? I'd probably do it simpler with just a hack with a static variable anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98770

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Nikolay Sivov (＠nsivov) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:54:23 2025 +0000, Robert Lippmann wrote: > As for ordinal numbers, I just copied and pasted what winedump gave me. > Should I change them all to @'s? All 4 functions you mentioned are already present in current code, in a form of stubs. So you don't need to update the spec file. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98769

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:43:07 2025 +0000, Nikolay Sivov wrote: > Header is another thing, but source files do not have to match how > functions are arranged in the SDK. Sorry, just seemed like a good idea because the existing file is pretty big and full of functions returning not implemented. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98768

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:43:29 2025 +0000, Nikolay Sivov wrote: > So what does it need exactly, and why stubs are not enough? Sorry, I'm new to this :disappointed: What would happen if it was just a stub? I also figured, while I was there, I might as well implement it... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98767

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:53:43 2025 +0000, Robert Lippmann wrote: > From what I can tell, it uses: > PowerSetActiveScheme > PowerGetActiveScheme > PowerReadFriendlyName > PowerEnumerate > I'm hoping just implementing the first 2 will get it to work. As for ordinal numbers, I just copied and pasted what winedump gave me. Should I change them all to @'s? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98766

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Robert Lippmann (＠rlippmann) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:41:35 2025 +0000, Nikolay Sivov wrote: > I meant ordinal numbers, preceding calling convention marker "stdcall". > Does SteamVR require any of newer functions? From what I can tell, it uses: PowerSetActiveScheme PowerGetActiveScheme PowerReadFriendlyName PowerEnumerate I'm hoping just implementing the first 2 will get it to work. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98765

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Nikolay Sivov (＠nsivov) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:37:26 2025 +0000, Robert Lippmann wrote: > SteamVR's vrmonitor.exe tries to change the power profile and crashes > with an access violation. > Valve has been bugged about this for years, since they really shouldn't > be doing it. So, I figure it will never be fixed by them. So what does it need exactly, and why stubs are not enough? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98764

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Nikolay Sivov (＠nsivov) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:31:59 2025 +0000, Robert Lippmann wrote: > Well, according to the SDK, the header is now powersetting.h, not > powrprof.h, which is why I created the new file. Header is another thing, but source files do not have to match how functions are arranged in the SDK. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98763

1 0

Re: [PATCH v2 0/8] MR7644: powrprof.dll: Implement PowerGetActiveProfile and PowerSetActiveProfile
by Nikolay Sivov (＠nsivov) 22 Mar '25

22 Mar '25

On Sat Mar 22 22:41:16 2025 +0000, Robert Lippmann wrote: > Oops, I just took the output of winedump and didn't change the numbers > to @'s. I meant ordinal numbers, preceding calling convention marker "stdcall". Does SteamVR require any of newer functions? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7644#note_98762

1 0

2025

2024

2023

2022

wine-gitlab