- wine-gitlab - winehq.org

[PATCH v2 0/2] MR7678: winewayland: Use system cursor shapes when possible.
by Alexandros Frantzis (＠afrantzis) 27 Mar '25

27 Mar '25

This MR uses the cursor-shapes-v1 protocol to tell the compositor which system cursor shape to use. If a shape match is not found (or cursor-shapes-v1 is not available) we fall back to setting the cursor buffer from the Windows cursor data as before. The second commit implements support for a "UseSystemCursors" driver option, similar to what winex11 has. Since this is the first winewayland driver option we also introduce all the related registry reading code. -- Side note: The registry code is a copy from winex11, and is the third copy in the codebase (x11, mac, wayland). Perhaps it's worth introducing a common ntuser function to perform the option reading for the drivers, something like `NtUserGetDriverOption("X11 Driver", buffer, buffer_size, TRUE /* whether to read app specific option if present */)`. With such a function there is the concern about each call reopening the registry, but we can see if that's actually a problem and how a different API (or some sort of caching) may help. -- v2: winewayland: Support "UseSystemCursors" driver option. winewayland: Use system cursor shapes when possible. https://gitlab.winehq.org/wine/wine/-/merge_requests/7678

2 3

[PATCH v2 0/1] MR7674: makedep: Fix a compilation warning.
by Sven Baars (＠sbaars) 27 Mar '25

27 Mar '25

-- v2: makedep: Fix a compilation warning. https://gitlab.winehq.org/wine/wine/-/merge_requests/7674

2 1

[PATCH 0/1] MR7674: makedep: Fix a compilation warning.
by Sven Baars (＠sbaars) 27 Mar '25

27 Mar '25

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

3 2

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

27 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. -- v9: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. bluetoothapis: Implement BluetoothRegisterForAuthenticationEx and BluetoothUnregisterForAuthentication. winebth.sys: Implement IOCTL_WINEBTH_AUTH_REGISTER. winebth.sys: Broadcast a WINEBTH_AUTHENTICATION_REQUEST PnP event on receiving a RequestConfirmation request from BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

2 5

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

27 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. -- v8: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

2 5

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

27 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. -- v7: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. bluetoothapis: Implement BluetoothRegisterForAuthenticationEx and BluetoothUnregisterForAuthentication. winebth.sys: Implement IOCTL_WINEBTH_AUTH_REGISTER. winebth.sys: Broadcast a BLUETOOTH_AUTHENTICATION_REQUEST PnP event on receiving a RequestConfirmation request from BlueZ. winebth.sys: Register a pairing agent with BlueZ during startup. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

2 6

[PATCH 0/6] MR7679: dinput: Test and fix some action maps regressions.
by Rémi Bernon (＠rbernon) 27 Mar '25

27 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57919 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57920 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7679

2 6

[PATCH 0/2] MR7678: winewayland: Use system cursor shapes when possible.
by Alexandros Frantzis (＠afrantzis) 27 Mar '25

27 Mar '25

This MR uses the cursor-shapes-v1 protocol to tell the compositor which system cursor shape to use. If a shape match is not found (or cursor-shapes-v1 is not available) we fall back to setting the cursor buffer from the Windows cursor data as before. The second commit implements support for a "UseSystemCursors" driver option, similar to what winex11 has. Since this is the first winewayland driver option we also introduce all the related registry reading code. -- Side note: The registry code is a copy from winex11, and is the third copy in the codebase (x11, mac, wayland). Perhaps it's worth introducing a common ntuser function to perform the option reading for the drivers, something like `NtUserGetDriverOption("X11 Driver", buffer, buffer_size, TRUE /* whether to read app specific option if present */)`. With such a function there is the concern about each call reopening the registry, but we can see if that's actually a problem and how a different API (or some sort of caching) may help. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7678

2 2

[PATCH 0/1] MR7677: win32u: Always set DriverVersion.
by Sven Baars (＠sbaars) 27 Mar '25

27 Mar '25

I think this should fix the recent wbemprox:query test failures. The alternative would be to accept NULL in the test. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7677

3 4

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

27 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. -- v5: 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

3 24

[PATCH v2 0/6] MR7618: Draft: comctl32: Updates to syslink accessibility.
by Esme Povirk (＠madewokherd) 27 Mar '25

27 Mar '25

-- v2: comctl32/tests: Test MSAA events for SysLink. comctl32/tests: Test SetWindowText and LM_GETITEM for SysLink. comctl32/tests: Test accLocation values on SysLink control. comctl32: Implement EVENT_OBJECT_NAMECHANGE for SysLink controls. comctl32: Implement accDoDefaultAction for SysLink controls. comctl32/tests: Add test for SysLink accDoDefaultAction. https://gitlab.winehq.org/wine/wine/-/merge_requests/7618

3 8

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

27 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. -- v6: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. bluetoothapis: Implement BluetoothRegisterForAuthenticationEx and BluetoothUnregisterForAuthentication. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

4 8

[PATCH 0/1] MR7676: winegstreamer: Make sure WMSyncReader never reads in the background.
by Yuxuan Shui (＠yshui) 27 Mar '25

27 Mar '25

WMSyncReader starts a background read thread that reads from the IStream passed to IWMSyncReader::OpenStream. This means it could use the IStream in the background even when no IWMSyncReader methods are being called. For well-behaved applications, this is probably OK. However, AQUARIUM (Steam 2515070) frees the IStream it passes to WMSyncReader _before_ it calls IWMSyncReader::Close, which stops the read thread. This causes the read thread to access freed memory. This is improper, but not unreasonable, as IWMSyncReader is supposed to be a synchronous interface, so one might assume when they weren't calling into IWMSyncReader methods, the IStream won't be used. This commit adds a `wg_parser_dont_read` function, which can be used to stop wg_parser from issuing read requests. This is used by IWMSyncReader to make sure read requests are only issued when IWMSyncReader methods are being called. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7676

2 1

[PATCH 0/2] MR7673: shell32 copy file tests.
by Ziqing Hui (＠zhui) 27 Mar '25

27 Mar '25

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

2 5

[PATCH v2 0/2] MR7627: winex11: Track _NET_ACTIVE_WINDOW property changes.
by Rémi Bernon (＠rbernon) 27 Mar '25

27 Mar '25

In preparation for more changes to properly track X11 active window and request active window changes, ultimately improving window focus consistency on X11. -- v2: winex11: Track _NET_ACTIVE_WINDOW property changes. winex11: Introduce a new handle_state_change helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/7627

2 3

[PATCH 0/1] MR7671: wintrust: Don't set desktop window when initializing provider data.
by Paul Gofman (＠gofman) 27 Mar '25

27 Mar '25

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

3 3

[PATCH v2 0/7] MR7672: Draft: mfplat/tests: Add tests for Byte Stream Output.
by Brendan McGrath (＠redmcg) 27 Mar '25

27 Mar '25

This MR adds tests that examine the values of the samples output by the byte stream handlers. It is marked as draft as it is dependent on the fixes included within MR !7569. I've also renamed the tests as they previously exclusively tested the sample output timestamps. The tests now also look at the number of buffers included in a sample and total size of the buffers within a sample. -- v2: mfplat/tests: Add tests for MP3 Byte Stream Output. mfplat/tests: Add tests for Byte Stream Output. https://gitlab.winehq.org/wine/wine/-/merge_requests/7672

2 7

[PATCH 0/7] MR7672: Draft: mfplat/tests: Add tests for Byte Stream Output.
by Brendan McGrath (＠redmcg) 27 Mar '25

27 Mar '25

This MR adds tests that examine the values of the samples output by the byte stream handlers. It is marked as draft as it is dependent on the fixes included within MR !7569. I've also renamed the tests as they previously exclusively tested the sample output timestamps. The tests now also look at the number of buffers included in a sample and total size of the buffers within a sample. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7672

2 7

[PATCH v5 0/8] MR7667: powrprof.dll: Implement functions to enable SteamVR launch
by Robert Lippmann (＠rlippmann) 27 Mar '25

27 Mar '25

Implemented the following functions with a bit of a hack: PowerGetActiveScheme PowerSetActiveScheme PowerEnumerate PowerReadFriendlyName -- v5: even more fixes https://gitlab.winehq.org/wine/wine/-/merge_requests/7667

2 8

[PATCH v4 0/7] MR7667: powrprof.dll: Implement functions to enable SteamVR launch
by Robert Lippmann (＠rlippmann) 27 Mar '25

27 Mar '25

Implemented the following functions with a bit of a hack: PowerGetActiveScheme PowerSetActiveScheme PowerEnumerate PowerReadFriendlyName -- v4: more fixes https://gitlab.winehq.org/wine/wine/-/merge_requests/7667

2 7

[PATCH v3 0/6] MR7667: powrprof.dll: Implement functions to enable SteamVR launch
by Robert Lippmann (＠rlippmann) 27 Mar '25

27 Mar '25

Implemented the following functions with a bit of a hack: PowerGetActiveScheme PowerSetActiveScheme PowerEnumerate PowerReadFriendlyName -- v3: fixes https://gitlab.winehq.org/wine/wine/-/merge_requests/7667

2 6

[PATCH 0/1] MR7670: windowscodecs/converter: Implement BW -> 24BGR conversion.
by Nikolay Sivov (＠nsivov) 27 Mar '25

27 Mar '25

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

2 1

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

27 Mar '25

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

3 7

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

27 Mar '25

Follow-up of !2786, which appears to have been abandoned. -- v4: Fixup deletion of socket files ws2_32/tests: Add test for AF_UNIX sockets. server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. server: Allow for deletion of socket files. ws2_32: Add support for AF_UNIX sockets. ws2_32: Add afunix.h header. https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

3 8

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

26 Mar '25

Follow-up of !2786, which appears to have been abandoned. -- v3: ws2_32/tests: Add test for AF_UNIX sockets. server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. server: Allow for deletion of socket files. ws2_32: Add support for AF_UNIX sockets. https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

4 14

2025

2024

2023

2022

wine-gitlab