March 2025 - Wine-GitLab - list.winehq.org

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

March 27, 2025

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 March 27, 2025

March 27, 2025

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

1 6

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

March 27, 2025

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) March 27, 2025

March 27, 2025

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) March 27, 2025

March 27, 2025

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) March 27, 2025

March 27, 2025

-- 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) March 27, 2025

March 27, 2025

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) March 27, 2025

March 27, 2025

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) March 27, 2025

March 27, 2025

-- 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 March 27, 2025

March 27, 2025

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

1 3