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

[PATCH v11 0/3] MR7542: ws2_32: Implement WSALookupService for Bluetooth device discovery.
by Vibhav Pant (＠vibhavp) March 19, 2025

March 19, 2025

This MR adds an initial implementation of the winsock `WSALookupsService*` methods for performing Bluetooth device discovery (`LUP_CONTAINERS`). Pending !7472, the code will also eventually support performing device inquiry scans. -- v11: ws2_32: Implement WSALookupServiceNext for Bluetooth device discovery. ws2_32: Implement WSALookupServiceBegin for Bluetooth device discovery. ws2_32/tests: Add tests for Bluetooth device discovery in WSALookupServiceBegin/Next. https://gitlab.winehq.org/wine/wine/-/merge_requests/7542

2 3

[PATCH v10 0/3] MR7542: ws2_32: Implement WSALookupService for Bluetooth device discovery.
by Vibhav Pant (＠vibhavp) March 19, 2025

March 19, 2025

This MR adds an initial implementation of the winsock `WSALookupsService*` methods for performing Bluetooth device discovery (`LUP_CONTAINERS`). Pending !7472, the code will also eventually support performing device inquiry scans. -- v10: ws2_32: Implement WSALookupServiceNext for Bluetooth device discovery. ws2_32: Implement WSALookupServiceBegin for Bluetooth device discovery. ws2_32/tests: Add tests for Bluetooth device discovery in WSALookupServiceBegin/Next. https://gitlab.winehq.org/wine/wine/-/merge_requests/7542

3 8

[PATCH v5 0/5] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Rémi Bernon March 19, 2025

March 19, 2025

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v5: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. 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. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

1 5

[PATCH 0/5] MR7615: cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification.
by Rémi Bernon March 19, 2025

March 19, 2025

Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/7559 with couple of additional tests and fixes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7615

3 9

[PATCH v4 0/5] MR7559: cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification.
by Vibhav Pant (＠vibhavp) March 19, 2025

March 19, 2025

The methods are needed to implement Bluetooth device pairing in `bluetoothapis.dll` without having to create a dummy window for `RegisterDeviceNotification`, as that may break CLI applications. `CM_Register_Notification` is implemented as a thin wrapper over `I_ScRegisterDeviceNotification`, mapping `DBT_*` flags to their associated `CM_NOTIFY_*` constants. -- v4: user32: Remove incorrect FIXME warning while registering for DBT_DEVTYP_HANDLE notifications. cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification. dinput/tests: Add tests for CM_Register_Notification. https://gitlab.winehq.org/wine/wine/-/merge_requests/7559

2 7

[PATCH v4 0/5] MR7610: Draft: win32u: Create a shared object for user handle entries.
by Rémi Bernon March 19, 2025

March 19, 2025

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v4: win32u: Use the session shared object to implement is_window. win32u: Use the session shared object for user handle entries. 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. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

1 5

[PATCH v8 0/15] MR7516: Server-side thread priorities implementation (Part 3)
by Marc-Aurel Zent (＠mzent) March 19, 2025

March 19, 2025

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. -- v8: 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. include: Use correct PROCESS_PRIORITY_CLASS_* names. include: Add thread priority constants. https://gitlab.winehq.org/wine/wine/-/merge_requests/7516

3 17

[PATCH 0/8] MR7614: hidclass: Fix some possible crash when devices are unplugged.
by Rémi Bernon March 19, 2025

March 19, 2025

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

1 8

[PATCH 0/4] MR7613: winewayland: Clipboard support through core wl_data_device
by Alexandros Frantzis (＠afrantzis) March 19, 2025

March 19, 2025

This MR adds a fallback path that implements clipboard support using the core protocol (wl_data_device) when wlr-data-control-unstable-v1 is missing. The reasons we want this fallback path, in spite of the extra complexity it introduces, are: 1. Some compositors don't (and likely won't ever) support {wlr,ext}-data-control-unstable-v1. 2. Even compositors that do support {wlr,ext}-data-control-unstable-v1, may not expose it to sandboxed applications. This MR allows Wine to support clipboard operations in such scenarios, in a way that's good enough for many common user clipboard interactions. A more comprehensive discussion of the limitations can be found in !7236. This MR differs from !7236 in that it creates a per-process clipboard thread and window, instead of using the desktop process clipboard thread and manually forwarding messages. Note that the per-process clipboard threads/windows are created only if we fall back to wl_data_device. In the wlr-data-control-unstable-v1 case nothing changes, we still use the desktop process clipboard thread as before. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7613

2 4

Re: [PATCH v7 0/15] MR7516: Server-side thread priorities implementation (Part 3)
by Marc-Aurel Zent (＠mzent) March 19, 2025

March 19, 2025

On Tue Mar 18 15:03:51 2025 +0000, Rémi Bernon wrote: > I haven't found neither the PROCESS_PRIOCLASS nor the > PROCESS_PRIORITY_CLASS constants in the SDK headers, where are you > seeing them? I was originally looking into that since the reported process base priority was not matching what windows reported and they were set to these values, so I thought they were wrong (which turned out to be not true for a different reason...). In any case, [System Informer](https://systeminformer.sourceforge.io), which is luckily open-source and MIT licensed, displays them like so: ``` static CONST PH_KEY_VALUE_PAIR ProcessPriorityClassTypePairs[] = { SIP(SREF(L"Unknown"), PROCESS_PRIORITY_CLASS_UNKNOWN), SIP(SREF(L"Idle"), PROCESS_PRIORITY_CLASS_IDLE), SIP(SREF(L"Normal"), PROCESS_PRIORITY_CLASS_NORMAL), SIP(SREF(L"High"), PROCESS_PRIORITY_CLASS_HIGH), SIP(SREF(L"Real time"), PROCESS_PRIORITY_CLASS_REALTIME), SIP(SREF(L"Below normal"), PROCESS_PRIORITY_CLASS_BELOW_NORMAL), SIP(SREF(L"Above normal"), PROCESS_PRIORITY_CLASS_ABOVE_NORMAL), }; ``` A quick GitHub code search shows that these are used like so in a wide range of projects, whereas the current Wine naming of `PROCESS_PROCLASS_*` is basically only used by Wine. This also adds the unknown case and starts from `0`, which are both nice-to-haves, and leads me to believe that this is also the original private API naming scheme. If this is still not worth it to do, I can also just drop the commit as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7516#note_98393

1 0