- wine-gitlab - winehq.org

[PATCH v5 0/7] MR6640: propsys: Support converting to BSTR for PropVariantToVariant.
by Ziqing Hui (＠zhui) 22 Oct '24

22 Oct '24

This is based on top of !6526, will mark ready after !6526 is merged. -- v5: DEBUG the gitlab CI test failure. https://gitlab.winehq.org/wine/wine/-/merge_requests/6640

3 8

[PATCH 0/1] MR6701: winex11: Avoid processing RRNotify events in xrandr14_get_id.
by Rémi Bernon (＠rbernon) 22 Oct '24

22 Oct '24

This reverts commit b3eb55227aef198a637f80a2fa0bce74aa0a7190. Since 278b98f5b21b56abdf9229b12b2a747be6917018 it should be unnecessary to process the events as the current display mode is written to the registry. This fixes a random deadlock that happens when a window is updating its state while another thread changes the current display settings. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6701

3 2

[PATCH 0/5] MR6716: winex11: Misc window state refactoring.
by Rémi Bernon (＠rbernon) 22 Oct '24

22 Oct '24

This MR should be no-op and doesn't change much, but makes some small refactoring in preparation for an improved window state tracker as designed in https://gitlab.winehq.org/wine/wine/-/merge_requests/6569. Overall with that full MR not much would be changed either, and instead some existing fields are replaced with a cleaner design, until the end of the MR where state requests are made asynchronous and where the new information is used to decide whether to apply or delay client state updates. I believe that the whole MR would fix the currently often failing d3d/ddraw tests, and more generally fix race conditions that happen with window state updates. I believe that it should also ultimately make it easier/safer to change the current design, to delay the client state updates a bit more and apply them outside of the driver ProcessEvent calls: tracking the pending and host states accurately and independently of the win32 state will let us decide what change needs to be requested to make them match, at any moment. The latter would fix some existing bug where applications stop responding as they start a new message loop in response to SC_RESTORE commands, and as we do not process X11 events recursively. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6716

2 5

[PATCH v6 0/45] MR6569: Draft: winex11: Refactor window state/config tracker to fix race conditions.
by Rémi Bernon (＠rbernon) 22 Oct '24

22 Oct '24

This completely refactors the winex11 window state tracking, keeping track of the desired/pending/current window state and config in a fully asynchronous way, and avoiding duplicate requests. I believe this mitigates various race conditions that we're suffering from, solving most spurious event feedback loops when the X11 state is being applied while some win32 state change is being requested, and fixing the spurious d3d/ddraw/user32 test failures. -- v6: d3d9/tests: Remove now unnecesary d3d9ex todo_wine / flaky. winex11: Try updating client window config on (_NET_)_WM_STATE updates. winex11: Try updating client window state on ConfigureNotify. winex11: Request only one _NET_WM_STATE bit change at a time. winex11: Remove now unnecessary (net_)wm_state window members. winex11: Get rid of the now unnecessary unmap_window helper. winex11: Request window state updates asynchronously. winex11: Try updating the client window state in net_wm_state_notify. winex11: Request window config updates asynchronously. winex11: Introduce a new window_update_client_config helper. winex11: Simplify the control flow in ConfigureNotify handlers. winex11: Introduce a new window_update_client_state helper. winex11: Simplify the control flow in WM_STATE handlers. winex11: Avoid updating _NET_WM_STATE on iconic windows. winex11: Tweak the WM_TAKE_FOCUS event time to workaround a FVWM bug. winex11: Ignore focus changes during WM_STATE updates. winex11: Get rid of the now unnecessary mapped window data flag. winex11: Use desired_state wm_state to decide of the mapped flag. winex11: Call window_set_wm_state when unmapping embedded windows. winex11: Get rid of the unnecessary net_wm_state window data member. winex11: Get rid of the now unnecessary iconic window data flag. winex11: Use pending_state wm_state to decide whether a window is currently iconic. winex11: Use pending_state to decide whether to set fullscreen monitor property. winex11: Use pending_state wm_state to decide if requests can be made directly. winex11: Compute WM_STATE notify updates in term of style changes. winex11: Compute ConfigureNotify updates in term of style changes. winex11: Compute WindowPosChanged updates in term of style changes. winex11: Avoid requesting unnecessary window config changes. winex11: Avoid requesting unnecessary _NET_WM_STATE changes. winex11: Track window config requests and updates. winex11: Introduce a new window_set_config helper. winex11: Track _NET_WM_STATE window property requests and updates. winex11: Introduce a new window_set_net_wm_state helper. winex11: Introduce a new window_set_wm_state helper. winex11: Track _XEMBED_INFO window property changes. winex11: Introduce a new window state tracker. winex11: Move embedded check in update_net_wm_states / sync_window_style. winex11: Move ConfigureNotify checks after computing visible rect. winex11: Rename read_net_wm_state to get_window_net_wm_state. winex11: Set configure_serial when resizing on display mode change. winex11: Avoid processing RRNotify events in xrandr14_get_id. d3d9/tests: Use static class for the dummy window. d3d9/tests: Avoid creating visible windows concurrently. wined3d: Check that format_id is >= 0 before assuming it's an index. DEBUG: gitlab: Only build the last commit. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/6569

1 1

[PATCH 0/1] MR6714: winecrt0: Use version 2 of CHPE metadata.
by Jacek Caban (＠jacek) 22 Oct '24

22 Oct '24

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

3 2

[PATCH v5 0/44] MR6569: Draft: winex11: Keep a list of pending window config requests.
by Rémi Bernon (＠rbernon) 22 Oct '24

22 Oct '24

Instead of a single configure serial, which is simply not enough to mitigate event feedback loops. This should (hopefully) address the recent d3d8:device / d3d9:device test failures on the Gitlab CI, without having to add more `flush_events` calls to the tests. I believe it should also provide a more general fix to this race condition than the configure_serial mechanism. -- v5: d3d9/tests: Remove now unnecesary d3d9ex todo_wine / flaky. winex11: Try updating client window config on (_NET_)_WM_STATE updates. winex11: Try updating client window state on ConfigureNotify. winex11: Request only one _NET_WM_STATE bit change at a time. winex11: Remove now unnecessary (net_)wm_state window members. winex11: Get rid of the now unnecessary unmap_window helper. winex11: Request window state updates asynchronously. winex11: Try updating the client window state in net_wm_state_notify. winex11: Request window config updates asynchronously. winex11: Introduce a new window_update_client_config helper. winex11: Simplify the control flow in ConfigureNotify handlers. winex11: Introduce a new window_update_client_state helper. winex11: Simplify the control flow in WM_STATE handlers. winex11: Avoid updating _NET_WM_STATE on iconic windows. winex11: Tweak the WM_TAKE_FOCUS event time to workaround a FVWM bug. winex11: Ignore focus changes during WM_STATE updates. winex11: Get rid of the now unnecessary mapped window data flag. winex11: Use desired_state wm_state to decide of the mapped flag. winex11: Call window_set_wm_state when unmapping embedded windows. winex11: Get rid of the unnecessary net_wm_state window data member. winex11: Get rid of the now unnecessary iconic window data flag. winex11: Use pending_state wm_state to decide whether a window is currently iconic. winex11: Use pending_state to decide whether to set fullscreen monitor property. winex11: Use pending_state wm_state to decide if requests can be made directly. winex11: Compute WM_STATE notify updates in term of style changes. winex11: Compute ConfigureNotify updates in term of style changes. winex11: Compute WindowPosChanged updates in term of style changes. winex11: Avoid requesting unnecessary window config changes. winex11: Avoid requesting unnecessary _NET_WM_STATE changes. winex11: Track window config requests and updates. winex11: Introduce a new window_set_config helper. winex11: Track _NET_WM_STATE window property requests and updates. winex11: Introduce a new window_set_net_wm_state helper. winex11: Introduce a new window_set_wm_state helper. winex11: Track _XEMBED_INFO window property changes. winex11: Introduce a new window state tracker. winex11: Move embedded check in update_net_wm_states / sync_window_style. winex11: Move ConfigureNotify checks after computing visible rect. winex11: Rename read_net_wm_state to get_window_net_wm_state. winex11: Set configure_serial when resizing on display mode change. winex11: Avoid processing RRNotify events in xrandr14_get_id. d3d9/tests: Use static class for the dummy window. d3d9/tests: Avoid creating visible windows concurrently. wined3d: Check that format_id is >= 0 before assuming it's an index. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/6569

1 1

[PATCH 0/8] MR6709: Code refactor reduced variable inner scope
by Herman Semenov (＠GermanAizek) 22 Oct '24

22 Oct '24

Micro-optimization works only in Debug build, therefore, it is more correct to name this code refactoring, in my GCC with -O2 flag it does not affect count and decrease cost per CPU clock cycle instructions generated in any way. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6709

4 12

[PATCH 0/3] MR6704: d3dx9: Some changes to pixel format handling on the WIC image decode path.
by Connor McAdams (＠cmcadams) 22 Oct '24

22 Oct '24

This adds support for converting to different WIC formats, in one case to more closely match native d3dx9, and in the other to convert to a format that can actually be represented by d3d9. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6704

3 5

[PATCH v4 0/7] MR6640: propsys: Support converting to BSTR for PropVariantToVariant.
by Ziqing Hui (＠zhui) 22 Oct '24

22 Oct '24

This is based on top of !6526, will mark ready after !6526 is merged. -- v4: DEBUG the gitlab CI test failure. propsys: Support converting to BSTR for PropVariantToVariant. propsys: Use debugstr_variant for the trace in VariantToPropVariant. propsys: Implement PropVariantToBSTR. propsys/tests: Test truncating for PropVariantToString. propsys/tests: Test PropVariantToBSTR. propsys: Add PropVariantToBSTR stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/6640

4 12

[PATCH 0/9] MR6712: wintypes: Add IPropertyValueStatics and IPropertyValue.
by Zhiyi Zhang (＠zhiyi) 22 Oct '24

22 Oct '24

React Native apps require these. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6712

2 9

[PATCH 0/1] MR6708: win32u: Sync cursor position on window position change.
by Paul Gofman (＠gofman) 22 Oct '24

22 Oct '24

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

3 3

[PATCH v5 0/7] MR6158: Replaced on simpler functions with char, wchar_t parameter if possible
by Herman Semenov (＠GermanAizek) 22 Oct '24

22 Oct '24

Example my assembly with gcc -02 flag Before: ![screen_before](/uploads/f2bf5f4c793c159c31ac42b635c46d5a/screen_before.jpg) After: ![screen_after](/uploads/051315ad1e3c064046446782d36e1a29/screen_after.jpg) -- v5: d3dcompiler_43: micro-optimization using strstr -> strchr implementation if possible wusa: micro-optimization using strstr -> strchr implementation if possible oledb32: micro-optimization using strstr -> strchr implementation if possible wbemprox: micro-optimization using strstr -> strchr implementation if possible oledb32: micro-optimization using strstr -> strchr implementation if possible wusa: micro-optimization using strstr -> strchr implementation if possible msidb: micro-optimization using strstr -> strchr implementation if possible https://gitlab.winehq.org/wine/wine/-/merge_requests/6158

2 8

Re: [PATCH v6 0/7] MR6703: msvcrt: Improve DBCS support for _strnicmp_l(). - approved
by Alexandre Julliard (＠julliard) 21 Oct '24

21 Oct '24

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

1 0

Re: [PATCH v2 0/3] MR6706: windows.gaming.input: Invoke event handlers outside of the critical section. - approved
by Alexandre Julliard (＠julliard) 21 Oct '24

21 Oct '24

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

1 0

Re: [PATCH v10 0/8] MR6649: winex11: Replace foreign windows with a driver-only host window tracking. - approved
by Alexandre Julliard (＠julliard) 21 Oct '24

21 Oct '24

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

1 0

Re: [PATCH v2 0/1] MR6705: win32u: Do not adjust old valid rect when moving child window bits. - approved
by Alexandre Julliard (＠julliard) 21 Oct '24

21 Oct '24

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

1 0

Re: [PATCH v2 0/1] MR6702: include: Add new property keys in propkey.h. - approved
by Alexandre Julliard (＠julliard) 21 Oct '24

21 Oct '24

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

1 0

Re: [PATCH v3 0/2] MR6696: mciseq: Don't seek to the end of the root chunk in RMID files. - approved
by Alexandre Julliard (＠julliard) 21 Oct '24

21 Oct '24

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

1 0

Re: [PATCH v2 0/5] MR6681: dplayx, dpwsockx: CreatePlayer() part 2. - approved
by Alexandre Julliard (＠julliard) 21 Oct '24

21 Oct '24

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

1 0

[PATCH v3 0/1] MR6666: ntdll: Implement NtWow64QueryInformationProcess64.
by Alex Henrie (＠alexhenrie) 21 Oct '24

21 Oct '24

Needed for GOG Galaxy. -- v3: ntdll: Implement NtWow64QueryInformationProcess64. https://gitlab.winehq.org/wine/wine/-/merge_requests/6666

4 4

[PATCH v2 0/1] MR6666: ntdll: Implement NtWow64QueryInformationProcess64.
by Alex Henrie (＠alexhenrie) 21 Oct '24

21 Oct '24

Needed for GOG Galaxy. -- v2: ntdll: Implement NtWow64QueryInformationProcess64. https://gitlab.winehq.org/wine/wine/-/merge_requests/6666

4 6

[PATCH v4 0/2] MR6158: Replaced on simpler functions with char, wchar_t parameter if possible
by Herman Semenov (＠GermanAizek) 21 Oct '24

21 Oct '24

Example my assembly with gcc -02 flag Before: ![screen_before](/uploads/f2bf5f4c793c159c31ac42b635c46d5a/screen_before.jpg) After: ![screen_after](/uploads/051315ad1e3c064046446782d36e1a29/screen_after.jpg) -- v4: d3dcompiler: replaced to char, wchar_t parameter if possible wcmdmain: replaced to char, wchar_t parameter if possible https://gitlab.winehq.org/wine/wine/-/merge_requests/6158

4 10

[PATCH v5 0/7] MR6703: msvcrt: Improve DBCS support for _strnicmp_l().
by Jactry Zeng (＠jactry) 21 Oct '24

21 Oct '24

-- v5: msvcrt/tests: Add tests of _strnicmp_l(). include: Add _strnicmp_l() declaration. msvcrt/tests: Test _stricmp() with multiple bytes characters. msvcrt: Correct the result of non-ASCII characters for _strnicmp_l(). msvcrt/tests: Test _tolower_l() with DBCS. msvcrt: Improve DBCS support for _tolower_l(). msvcrt/tests: Test tolower() with DBCS. https://gitlab.winehq.org/wine/wine/-/merge_requests/6703

3 8

[PATCH v2 0/2] MR6707: Fix compilation for gcc 4.7
by Fabian Maurer (＠DarkShadow44) 21 Oct '24

21 Oct '24

-- v2: mf/tests: Fix compilation for gcc 4.7 https://gitlab.winehq.org/wine/wine/-/merge_requests/6707

2 4

[PATCH v2 0/1] MR6169: comctl32: fixed first we check index then array access by index is safe
by Herman Semenov (＠GermanAizek) 21 Oct '24

21 Oct '24

I think this PR changes will protect against situation if out-of-bounds access array. -- v2: comctl32: fixed first we check index then array access by index is safe https://gitlab.winehq.org/wine/wine/-/merge_requests/6169

6 8

[PATCH v8 0/2] MR498: server: Allow creating named pipes using \Device\NamedPipe\ as RootDirectory. (#52105)
by Jinoh Kang (＠iamahuman) 21 Oct '24

21 Oct '24

On Windows, \Device\NamedPipe\ is the root directory of the named pipe file system (NPFS), and can be used as RootDirectory to skip its path when accessing the NPFS namespace. --- **Note**: `subpath->str` may look hacky, but it's used to indicate trailing `\\`[^bks] and existing code already does it too: - `server/directory.c` checks `name->str`[^dir] to test if this is the last component. This is evident by the fact that changing it to `name->len` will lead to major regression. - `server/registry.c` has similar lookup logic.[^reg1][^reg2] [^bks]: https://gitlab.winehq.org/wine/wine/-/blob/c64aa0006e4a33d755a57a693cd81dc1… [^dir]: https://gitlab.winehq.org/wine/wine/-/blob/c64aa0006e4a33d755a57a693cd81dc1… [^reg1]: <https://gitlab.winehq.org/wine/wine/-/blob/c64aa0006e4a33d755a57a693cd81dc1…> [^reg2]: <https://gitlab.winehq.org/wine/wine/-/blob/c64aa0006e4a33d755a57a693cd81dc1…> -- v8: server: Implement more FSCTLs on \Device\NamedPipe and \Device\NamedPipe\. server: Allow creating named pipes using \Device\NamedPipe\ as RootDirectory. https://gitlab.winehq.org/wine/wine/-/merge_requests/498

3 4

[PATCH v4 0/7] MR6703: msvcrt: Improve DBCS support for _strnicmp_l().
by Jactry Zeng (＠jactry) 21 Oct '24

21 Oct '24

-- v4: msvcrt/tests: Add tests of _strnicmp_l(). include: Add _strnicmp_l() declaration. msvcrt/tests: Test _stricmp() with multiple bytes characters. msvcrt: Correct the result of non-ASCII characters for _strnicmp_l(). msvcrt/tests: Test _tolower_l() with DBCS. msvcrt: Improve DBCS support for _tolower_l(). msvcrt/tests: Test tolower() with DBCS. https://gitlab.winehq.org/wine/wine/-/merge_requests/6703

3 9

[PATCH 0/2] MR6707: Fix compilation for gcc 4.7
by Fabian Maurer (＠DarkShadow44) 21 Oct '24

21 Oct '24

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

4 4

[PATCH v3 0/7] MR6703: msvcrt: Improve DBCS support for _strnicmp_l().
by Jactry Zeng (＠jactry) 21 Oct '24

21 Oct '24

-- v3: msvcrt/tests: Add tests of _strnicmp_l(). include: Add _strnicmp_l() declaration. msvcrt/tests: Test _stricmp() with multiple bytes characters. msvcrt: Correct the result of non-ASCII characters for _strnicmp_l(). msvcrt/tests: Test _tolower_l() with DBCS. msvcrt: Improve DBCS support for _tolower_l(). msvcrt/tests: Test tolower() with DBCS. https://gitlab.winehq.org/wine/wine/-/merge_requests/6703

3 9

[PATCH v25 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 21 Oct '24

21 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v25: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. dlls/winebth.sys: Add a basic unixlib stub using DBus. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

3 6

[PATCH 0/3] MR6706: windows.gaming.input: Invoke event handlers outside of the critical section.
by Rémi Bernon (＠rbernon) 21 Oct '24

21 Oct '24

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

3 5

[PATCH v24 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 21 Oct '24

21 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v24: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. dlls/winebth.sys: Add a basic unixlib stub using DBus. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

3 6

[PATCH v9 0/8] MR6649: winex11: Replace foreign windows with a driver-only host window tracking.
by Rémi Bernon (＠rbernon) 21 Oct '24

21 Oct '24

Making all the windows handled by the driver to be either GL/VK client surfaces, or top-level windows. This avoids leaking host windows into the Win32 space, and makes it possible to get rid of some remaining NtUserMapWindowPoints in `map_event_coords` for mouse input. -- v9: winex11: Get rid of the now unnecessary foreign windows. winex11: Generate relative ConfigureNotify on parent ConfigureNotify events. winex11: Use the new host windows to register foreign window events. winex11: Keep track of the host windows children window rects. winex11: Keep track of the host windows relative rects. winex11: Keep track of the host window children of interest. winex11: Create host windows recursively up to root_window. winex11: Introduce a new struct host_window for host-only windows. https://gitlab.winehq.org/wine/wine/-/merge_requests/6649

2 9

[PATCH v23 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 21 Oct '24

21 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v23: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. dlls/winebth.sys: Add a basic unixlib stub using DBus. dlls/winebth.sys: Add base winebth.sys driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 5

[PATCH 0/1] MR6705: win32u: Do not adjust old valid rect when moving child window bits.
by Rémi Bernon (＠rbernon) 21 Oct '24

21 Oct '24

The child window is moved within its parent surface, the old / new visible rects have moved with the child, but the surface did not and valid rects are correctly positionned already. Fixes: 602040c58cecb778972c2ade6efabaf3b9f963ff Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57334 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6705

2 1

[PATCH v2 0/2] MR6696: mciseq: Don't seek to the end of the root chunk in RMID files.
by Sebastian Krzyszkowiak (＠dos1) 21 Oct '24

21 Oct '24

Commit 9e1008f13735 added mmioSeek call that skips the whole data portion of the RMID chunk, breaking the handling of RMID (RIFF-based MIDI) files as it effectively skips the whole content of the RIFF file. Since mmioDescend expects the file position to be somewhere within the specified parent chunk, it's guaranteed to fail. $ WINEDEBUG=+mcimidi wine wintest.exe mcishell mci.c:178: Type your commands to the MCI, end with Ctrl-Z/^D open BOSSNOVA.RMI mci.c:188: command: open BOSSNOVA.RMI 0764:trace:mcimidi:MIDI_mciOpen (1, 00000200, 0051FB98) 0764:trace:mcimidi:MIDI_mciOpen wDevID=1 (lpParams->wDeviceID=1) 0764:trace:mcimidi:MIDI_mciOpen MCI_OPEN_ELEMENT L"bossnova.rmi"! 0764:trace:mcimidi:MIDI_mciOpen hFile=00000001 0764:trace:mcimidi:MIDI_mciOpen ParentChunk ckid=RIFF fccType=RMID cksize=000052DA mci.c:191: Test failed: mci open BOSSNOVA.RMI error: 296(40 MCIERR_INVALID_FILE) Its introduction seems unrelated to the rest of that commit and there's no reason given for placing it there, so let's remove the mmioSeek call to fix RMID file handling in MCI. Previous mmioDescend call will set the position to just after the chunk's form type, which is exactly where it should be when calling mmioDescend the second time to find the data chunk. Other parts of Wine code that deal with RIFF files don't seek in analogous situations either. Fixes: 9e1008f13735 ("Removed fixed size array to store specific data") -- v2: mciseq: Don't seek to the end of the root chunk in RMID files. midiseq: Reduce race window when closing sequencer. https://gitlab.winehq.org/wine/wine/-/merge_requests/6696

5 6

[PATCH v2 0/7] MR6703: msvcrt: Improve DBCS support for _strnicmp_l().
by Jactry Zeng (＠jactry) 20 Oct '24

20 Oct '24

-- v2: msvcrt/tests: Add tests of _strnicmp_l(). include: Add _strnicmp_l() declaration. msvcrt/tests: Test _stricmp() with multiple bytes characters. msvcrt: Improve DBCS support for _strnicmp_l(). msvcrt/tests: Test _tolower_l() with DBCS. msvcrt: Improve DBCS support for _tolower_l(). msvcrt/tests: Test tolower() with DBCS. https://gitlab.winehq.org/wine/wine/-/merge_requests/6703

5 17

[PATCH 0/5] MR6703: msvcrt: Improve DBCS support for _strnicmp_l().
by Jactry Zeng (＠jactry) 20 Oct '24

20 Oct '24

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

4 7

[PATCH 0/1] MR6696: mciseq: Don't seek to the end of the root chunk in RMID files.
by Sebastian Krzyszkowiak (＠dos1) 19 Oct '24

19 Oct '24

Commit 9e1008f13735 added mmioSeek call that skips the whole data portion of the RMID chunk, breaking the handling of RMID (RIFF-based MIDI) files as it effectively skips the whole content of the RIFF file. Since mmioDescend expects the file position to be somewhere within the specified parent chunk, it's guaranteed to fail. $ WINEDEBUG=+mcimidi wine wintest.exe mcishell mci.c:178: Type your commands to the MCI, end with Ctrl-Z/^D open BOSSNOVA.RMI mci.c:188: command: open BOSSNOVA.RMI 0764:trace:mcimidi:MIDI_mciOpen (1, 00000200, 0051FB98) 0764:trace:mcimidi:MIDI_mciOpen wDevID=1 (lpParams->wDeviceID=1) 0764:trace:mcimidi:MIDI_mciOpen MCI_OPEN_ELEMENT L"bossnova.rmi"! 0764:trace:mcimidi:MIDI_mciOpen hFile=00000001 0764:trace:mcimidi:MIDI_mciOpen ParentChunk ckid=RIFF fccType=RMID cksize=000052DA mci.c:191: Test failed: mci open BOSSNOVA.RMI error: 296(40 MCIERR_INVALID_FILE) Its introduction seems unrelated to the rest of that commit and there's no reason given for placing it there, so let's remove the mmioSeek call to fix RMID file handling in MCI. Previous mmioDescend call will set the position to just after the chunk's form type, which is exactly where it should be when calling mmioDescend the second time to find the data chunk. Other parts of Wine code that deal with RIFF files don't seek in analogous situations either. Fixes: 9e1008f13735 ("Removed fixed size array to store specific data") -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6696

3 3

[PATCH 0/1] MR6702: include: Add new property keys in propkey.h.
by Biswapriyo Nath (＠Biswa96) 19 Oct '24

19 Oct '24

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

3 3

Re: [PATCH v3 0/1] MR6674: xml2: Import upstream release 2.12.8.
by darkblaze69 (＠darkblaze69) 19 Oct '24

19 Oct '24

Office 2013 setup fails since this commit ![Screenshot_From_2024-10-19_11-18-54](/uploads/89b3c675a00c707dfc330232baa2afbe/Screenshot_From_2024-10-19_11-18-54.png) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6674#note_85508

1 0

[PATCH 0/5] MR6681: dplayx, dpwsockx: CreatePlayer() part 2.
by Anton Baskanov (＠baskanov) 19 Oct '24

19 Oct '24

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

4 10

[PATCH v3 0/1] MR6662: win32u/zibdrv: Round get_arc_max_points() value to a multiple of 4.
by Aida Jonikienė (＠DodoGTA) 19 Oct '24

19 Oct '24

This seems like a weird solution to me (so I'm not sure if the tests pass) -- v3: win32u/dibdrv: Round get_arc_max_points() value to a multiple of 4. https://gitlab.winehq.org/wine/wine/-/merge_requests/6662

3 6

[PATCH v2 0/1] MR6693: mlang: Only consider true type fonts in map_font().
by Danyil Blyschak (＠blyss) 18 Oct '24

18 Oct '24

-- v2: mlang: Only consider true type fonts in map_font(). https://gitlab.winehq.org/wine/wine/-/merge_requests/6693

3 2

Re: [PATCH v4 0/6] MR6688: d3dx9: Move targa decoding into d3dx9, part 2. - approved
by Alexandre Julliard (＠julliard) 18 Oct '24

18 Oct '24

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

1 0

Re: [PATCH v2 0/1] MR6699: user32/tests: Flush events after test_SetForegroundWindow. - approved
by Alexandre Julliard (＠julliard) 18 Oct '24

18 Oct '24

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

1 0

Re: [PATCH v3 0/1] MR6690: sort: New program. - approved
by Alexandre Julliard (＠julliard) 18 Oct '24

18 Oct '24

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

1 0

Re: [PATCH v2 0/2] MR6685: win32u: Fixes for arc drawing. - approved
by Alexandre Julliard (＠julliard) 18 Oct '24

18 Oct '24

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

1 0

Re: [PATCH v3 0/4] MR6695: ntdll/tests: Add reserve object tests. - approved
by Alexandre Julliard (＠julliard) 18 Oct '24

18 Oct '24

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

1 0

Re: [PATCH v2 0/6] MR6694: user32: Move DND code from winex11 XDND. - approved
by Alexandre Julliard (＠julliard) 18 Oct '24

18 Oct '24

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

1 0

[PATCH v3 0/6] MR6688: d3dx9: Move targa decoding into d3dx9, part 2.
by Connor McAdams (＠cmcadams) 18 Oct '24

18 Oct '24

These patches finish moving targa file handling into d3dx9. -- v3: d3dx9: Add support for decoding targa files with a color map in d3dx9. d3dx9: Add support for decoding targa files with run length encoding in d3dx9. d3dx9: Add support for decoding targa files with different pixel orders in d3dx9. d3dx9: Add support for loading basic targa images without WIC. d3dx9/tests: Add more tests for loading targa files. https://gitlab.winehq.org/wine/wine/-/merge_requests/6688

3 12

[PATCH v2 0/3] MR6680: msvcp140: Use current locale to convert path in _Fiopen.
by Daniel Lehman (＠dlehman25) 18 Oct '24

18 Oct '24

-- v2: msvcp140: Use current locale to convert path in _Fiopen. msvcp120/tests: Add tests for _Fiopen. msvcp140/tests: Add tests for _Fiopen. https://gitlab.winehq.org/wine/wine/-/merge_requests/6680

4 8

[PATCH 0/1] MR6699: user32/tests: Flush events after test_SetForegroundWindow.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

Making sure there's no pending X11 event to be processed that would cause spurious failures with later tests. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6699

2 1

Re: [PATCH v12 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Anton Baskanov (＠baskanov) 18 Oct '24

18 Oct '24

On Fri Oct 18 14:05:23 2024 +0000, Rémi Bernon wrote: > I see, I think this should not be necessary anymore since !6573, the new > display mode will be written to the registry and other processes/threads > should get their cache invalidate immediately. > Later on, when the XRandR events are processed the cache might get > invalidated again but should end up with the same display settings. The issue was specifically with seeing mode changes from other processes. The test calls `EnumDisplaySettings()` in a loop waiting for the expected mode change. If we don't process `RRNotify` events in `xrandr14_get_id()` we won't see the new mode until some thread processes the messages. Since there are no such threads in the test process, the test will fail. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5060#note_85467

1 0

[PATCH v8 0/8] MR6649: winex11: Replace foreign windows with a driver-only host window tracking.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

Making all the windows handled by the driver to be either GL/VK client surfaces, or top-level windows. This avoids leaking host windows into the Win32 space, and makes it possible to get rid of some remaining NtUserMapWindowPoints in `map_event_coords` for mouse input. -- v8: winex11: Get rid of the now unnecessary foreign windows. winex11: Generate relative ConfigureNotify on parent ConfigureNotify events. winex11: Use the new host windows to register foreign window events. winex11: Keep track of the host windows children window rects. winex11: Keep track of the host windows relative rects. winex11: Keep track of the host window children of interest. winex11: Create host windows recursively up to root_window. winex11: Introduce a new struct host_window for host-only windows. https://gitlab.winehq.org/wine/wine/-/merge_requests/6649

3 12

[PATCH v3 0/4] MR6602: explorer, services: Use admin tokens when appropriate.
by Tim Clem (＠tclem) 18 Oct '24

18 Oct '24

Let me know if you'd like me to split this up. As per feedback, I'm now doing the admin token-setting via an extension to NtSetInformationProcess. Testing on Windows shows that the owner of GetDesktopWindow() always has a default admin token with `TokenElevationTypeDefault`, no matter the token of the process/thread that is responsible for creating it. We've had issues in this area in the past - 99e2fad1 was a case where it was important that explorer not inherit the token of the *process* spawning it, but instead the token of the *thread*. This patch keeps that app working, since now explorer will set a default token regardless. In addition to the privilege issues from 99e2fad1, it is a relatively common pattern to duplicate the token of the owner of GetDesktopWindow to acquire a default token. Services are also currently launched with limited tokens, so this series also has services.exe elevate itself. -- v3: services: Apply a default admin token to the process. ntdll: Count default-elevation admin tokens as elevated from NtQueryInformationToken(TokenElevation). https://gitlab.winehq.org/wine/wine/-/merge_requests/6602

4 6

Re: [PATCH v12 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

On Fri Oct 18 13:56:14 2024 +0000, Zhiyi Zhang wrote: > If I remember correctly, it's for other threads other than the > explorer's main thread to see the new display mode immediately. Without > it, a rather large delay is causing tests to fail. I see, I think this should not be necessary anymore since !6573, the new display mode will be written to the registry and other processes/threads should get their cache invalidate immediately. Later on, when the XRandR events are processed the cache might get invalidated again but should end up with the same display settings. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5060#note_85457

1 0

Re: [PATCH v12 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Zhiyi Zhang (＠zhiyi) 18 Oct '24

18 Oct '24

On Fri Oct 18 13:56:14 2024 +0000, Rémi Bernon wrote: > Do you recall why b3eb55227aef198a637f80a2fa0bce74aa0a7190 is actually > required? Can't we just wait until the RRNotify events are received and > processed from whichever thread listens to them? > Fwiw it is causing some rare deadlocks with this kind of pattern: > 1) thread A holds `display_lock` and wants `user_lock`: > ``` > #4 0x00007f3f11236940 in user_lock () at ./dlls/win32u/sysparams.c:295 > #5 0x00007f3f11246551 in get_user_handle_ptr (type=1, handle=0x10020) > at ./dlls/win32u/window.c:90 > #6 get_win_ptr (hwnd=0x10020) at ./dlls/win32u/window.c:249 > #7 0x00007f3f11246e2b in get_window_thread (hwnd=0x10020, process=0x0) > at ./dlls/win32u/window.c:320 > #8 0x00007f3f1124ce8d in NtUserCallHwndParam (hwnd=hwnd@entry=0x10020, > param=param@entry=0, code=code@entry=16) at ./dlls/win32u/window.c:5892 > #9 0x00007f3f10c6803f in NtUserGetWindowThread (process=0x0, > hwnd=0x10020) at ./include/ntuser.h:1431 > #10 xrandr14_device_change_handler (hwnd=0x10020, event=<optimized out>) > at ./dlls/winex11.drv/xrandr.c:1221 > #11 0x00007f3f10c3535f in call_event_handler > (display=display@entry=0x55558c2bdcd0, event=event@entry=0x7ffffe0f9a80) > at ./dlls/winex11.drv/event.c:460 > #12 0x00007f3f10c37e27 in process_events (display=<optimized out>, > filter=filter@entry=0x7f3f10c65c30 <filter_rrnotify_event>, > arg=<optimized out>) at ./dlls/winex11.drv/event.c:518 > #13 0x00007f3f10c68f4f in process_rrnotify_events () at ./dlls/winex11.drv/xrandr.c:1270 > #14 xrandr14_get_id (device_name=<optimized out>, is_primary=<optimized > out>, id=0x7ffffe0f9c98) at ./dlls/winex11.drv/xrandr.c:1288 > #15 0x00007f3f10c33fe7 in X11DRV_UpdateDisplayDevices > (device_manager=0x7f3f1129f700 <device_manager>, param=0x7ffffe0fa680) > at ./dlls/winex11.drv/display.c:453 > #16 0x00007f3f11236ba8 in update_display_devices (ctx=0x7ffffe0fa680) at ./dlls/win32u/sysparams.c:2027 > #17 update_display_cache (force=force@entry=1) at ./dlls/win32u/sysparams.c:2072 > #18 0x00007f3f11238e5f in display_mode_changed (broadcast=1) at ./dlls/win32u/sysparams.c:3473 > #19 0x00007f3f11239cd2 in apply_display_settings > (target=target@entry=0x0, devmode=devmode@entry=0x0, > hwnd=hwnd@entry=0x0, flags=flags@entry=0, lparam=lparam@entry=0x0) at ./dlls/win32u/sysparams.c:3566 > #20 0x00007f3f1123d57d in NtUserChangeDisplaySettings > (devname=0x7ffffe2fe600, devmode=0x0, hwnd=0x0, flags=0, lparam=0x0) at ./dlls/win32u/sysparams.c:3583 > #21 <signal handler called> > #22 0x00006ffffe08bd74 in NtUserChangeDisplaySettings () from /home/rbernon/Code/build-wine-remote/build64/dlls/win32u/x86_64-windows/win32u.dll > #23 0x00006ffffe0dfdc3 in ChangeDisplaySettingsExW > (devname=devname@entry=0x0, devmode=devmode@entry=0x0, > hwnd=hwnd@entry=0x0, flags=flags@entry=0, lparam=lparam@entry=0x0) at ./dlls/user32/sysparams.c:549 > #24 0x00006ffffa591779 in wined3d_restore_display_modes > (wined3d=0x7ffffe2fec48) at ./dlls/wined3d/directx.c:1636 > #25 0x00006ffffa59d54e in wined3d_swapchain_activate > (swapchain=0x7fffff26eaa0, activate=0, activate@entry=32767) at ./dlls/wined3d/swapchain.c:1899 > ``` > 2) thread B holds `user_lock` and wants `display_lock`: > ``` > #4 0x00007f3f1123adcc in lock_display_devices () at ./dlls/win32u/sysparams.c:2100 > #5 get_virtual_screen_rect (dpi=dpi@entry=0, type=<optimized out>) at ./dlls/win32u/sysparams.c:2520 > #6 0x00007f3f112439a7 in NtUserCallTwoParam > (arg1=arg1@entry=140737480547808, arg2=arg2@entry=0, code=code@entry=10) > at ./dlls/win32u/sysparams.c:6758 > #7 0x00007f3f10c5a208 in NtUserGetVirtualScreenRect > (type=MDT_EFFECTIVE_DPI) at ./include/ntuser.h:1155 > #8 X11DRV_ReleaseDC (hwnd=<optimized out>, hdc=0x22010048) at ./dlls/winex11.drv/window.c:2700 > #9 0x00007f3f111842bd in release_dce (dce=dce@entry=0x55558c2a97b0) at ./dlls/win32u/dce.c:887 > #10 0x00007f3f11184810 in release_dce (dce=0x55558c2a97b0) at ./dlls/win32u/dce.c:1138 > #11 0x00007f3f11187118 in invalidate_dce (win=win@entry=0x7f3ec00aa020, > old_rect=old_rect@entry=0x7fffff88dfd0) at ./dlls/win32u/dce.c:1201 > #12 0x00007f3f1124e25c in apply_window_pos (hwnd=hwnd@entry=0x6004e, > insert_after=insert_after@entry=0x0, swp_flags=6207, > swp_flags@entry=6175, new_surface=new_surface@entry=0x7f3ec009f210, > new_rects=new_rects@entry=0x7fffff88e170, > valid_rects=valid_rects@entry=0x7fffff88e150) at ./dlls/win32u/window.c:2084 > #13 0x00007f3f112519fa in update_window_state (hwnd=0x6004e) at ./dlls/win32u/window.c:4523 > #14 0x00007f3f1120dedd in handle_internal_message (hwnd=<optimized out>, > msg=<optimized out>, wparam=0, lparam=<optimized out>) at ./dlls/win32u/message.c:2125 > #15 0x00007f3f112122a1 in peek_message (msg=msg@entry=0x7fffff88e9f0, > filter=filter@entry=0x7fffff88e9d0) at ./dlls/win32u/message.c:2923 > #16 0x00007f3f112138c8 in NtUserPeekMessage (msg_out=0x7fffffa8ff00, > hwnd=<optimized out>, first=<optimized out>, last=<optimized out>, > flags=<optimized out>) at ./dlls/win32u/message.c:3242 > #17 <signal handler called> > #18 0x00006ffffe08cd54 in NtUserPeekMessage () from /home/rbernon/Code/build-wine-remote/build64/dlls/win32u/x86_64-windows/win32u.dll > #19 0x00006ffffe113965 in PeekMessageW (flags=1024, last=<optimized > out>, first=<optimized out>, hwnd=<optimized out>, > msg_out=0x7fffffa8ff00) at ./dlls/user32/message.c:762 > #20 PeekMessageA (msg=0x7fffffa8ff00, hwnd=<optimized out>, > first=<optimized out>, last=<optimized out>, flags=1) at ./dlls/user32/message.c:772 > ``` > This happens randomly, perhaps more frequently since > 2b32c2859166e5542012b517cdef4699d8bb322c, but `update_window_state` > could already be called before in other circumstances, and it should not > cause a deadlock. > More specifically, I don't think we should try to acquire `user_lock` > with `display_lock` held, only the other way around. If I remember correctly, it's for other threads other than the explorer's main thread to see the new display mode immediately. Without it, a rather large delay is causing tests to fail. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5060#note_85456

1 0

[PATCH 0/2] MR6685: win32u: Fixes for arc drawing.
by Elizabeth Figura (＠zfigura) 18 Oct '24

18 Oct '24

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

4 4

Re: [PATCH v12 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

Do you recall why b3eb55227aef198a637f80a2fa0bce74aa0a7190 is actually required? Can't we just wait until the RRNotify events are received and processed from whichever thread listens to them? Fwiw it is causing some rare deadlocks with this kind of pattern: 1) thread A holds `display_lock` and wants `user_lock`: ``` #4 0x00007f3f11236940 in user_lock () at ./dlls/win32u/sysparams.c:295 #5 0x00007f3f11246551 in get_user_handle_ptr (type=1, handle=0x10020) at ./dlls/win32u/window.c:90 #6 get_win_ptr (hwnd=0x10020) at ./dlls/win32u/window.c:249 #7 0x00007f3f11246e2b in get_window_thread (hwnd=0x10020, process=0x0) at ./dlls/win32u/window.c:320 #8 0x00007f3f1124ce8d in NtUserCallHwndParam (hwnd=hwnd@entry=0x10020, param=param@entry=0, code=code@entry=16) at ./dlls/win32u/window.c:5892 #9 0x00007f3f10c6803f in NtUserGetWindowThread (process=0x0, hwnd=0x10020) at ./include/ntuser.h:1431 #10 xrandr14_device_change_handler (hwnd=0x10020, event=<optimized out>) at ./dlls/winex11.drv/xrandr.c:1221 #11 0x00007f3f10c3535f in call_event_handler (display=display@entry=0x55558c2bdcd0, event=event@entry=0x7ffffe0f9a80) at ./dlls/winex11.drv/event.c:460 #12 0x00007f3f10c37e27 in process_events (display=<optimized out>, filter=filter@entry=0x7f3f10c65c30 <filter_rrnotify_event>, arg=<optimized out>) at ./dlls/winex11.drv/event.c:518 #13 0x00007f3f10c68f4f in process_rrnotify_events () at ./dlls/winex11.drv/xrandr.c:1270 #14 xrandr14_get_id (device_name=<optimized out>, is_primary=<optimized out>, id=0x7ffffe0f9c98) at ./dlls/winex11.drv/xrandr.c:1288 #15 0x00007f3f10c33fe7 in X11DRV_UpdateDisplayDevices (device_manager=0x7f3f1129f700 <device_manager>, param=0x7ffffe0fa680) at ./dlls/winex11.drv/display.c:453 #16 0x00007f3f11236ba8 in update_display_devices (ctx=0x7ffffe0fa680) at ./dlls/win32u/sysparams.c:2027 #17 update_display_cache (force=force@entry=1) at ./dlls/win32u/sysparams.c:2072 #18 0x00007f3f11238e5f in display_mode_changed (broadcast=1) at ./dlls/win32u/sysparams.c:3473 #19 0x00007f3f11239cd2 in apply_display_settings (target=target@entry=0x0, devmode=devmode@entry=0x0, hwnd=hwnd@entry=0x0, flags=flags@entry=0, lparam=lparam@entry=0x0) at ./dlls/win32u/sysparams.c:3566 #20 0x00007f3f1123d57d in NtUserChangeDisplaySettings (devname=0x7ffffe2fe600, devmode=0x0, hwnd=0x0, flags=0, lparam=0x0) at ./dlls/win32u/sysparams.c:3583 #21 <signal handler called> #22 0x00006ffffe08bd74 in NtUserChangeDisplaySettings () from /home/rbernon/Code/build-wine-remote/build64/dlls/win32u/x86_64-windows/win32u.dll #23 0x00006ffffe0dfdc3 in ChangeDisplaySettingsExW (devname=devname@entry=0x0, devmode=devmode@entry=0x0, hwnd=hwnd@entry=0x0, flags=flags@entry=0, lparam=lparam@entry=0x0) at ./dlls/user32/sysparams.c:549 #24 0x00006ffffa591779 in wined3d_restore_display_modes (wined3d=0x7ffffe2fec48) at ./dlls/wined3d/directx.c:1636 #25 0x00006ffffa59d54e in wined3d_swapchain_activate (swapchain=0x7fffff26eaa0, activate=0, activate@entry=32767) at ./dlls/wined3d/swapchain.c:1899 ``` 2) thread B holds `user_lock` and wants `display_lock`: ``` #4 0x00007f3f1123adcc in lock_display_devices () at ./dlls/win32u/sysparams.c:2100 #5 get_virtual_screen_rect (dpi=dpi@entry=0, type=<optimized out>) at ./dlls/win32u/sysparams.c:2520 #6 0x00007f3f112439a7 in NtUserCallTwoParam (arg1=arg1@entry=140737480547808, arg2=arg2@entry=0, code=code@entry=10) at ./dlls/win32u/sysparams.c:6758 #7 0x00007f3f10c5a208 in NtUserGetVirtualScreenRect (type=MDT_EFFECTIVE_DPI) at ./include/ntuser.h:1155 #8 X11DRV_ReleaseDC (hwnd=<optimized out>, hdc=0x22010048) at ./dlls/winex11.drv/window.c:2700 #9 0x00007f3f111842bd in release_dce (dce=dce@entry=0x55558c2a97b0) at ./dlls/win32u/dce.c:887 #10 0x00007f3f11184810 in release_dce (dce=0x55558c2a97b0) at ./dlls/win32u/dce.c:1138 #11 0x00007f3f11187118 in invalidate_dce (win=win@entry=0x7f3ec00aa020, old_rect=old_rect@entry=0x7fffff88dfd0) at ./dlls/win32u/dce.c:1201 #12 0x00007f3f1124e25c in apply_window_pos (hwnd=hwnd@entry=0x6004e, insert_after=insert_after@entry=0x0, swp_flags=6207, swp_flags@entry=6175, new_surface=new_surface@entry=0x7f3ec009f210, new_rects=new_rects@entry=0x7fffff88e170, valid_rects=valid_rects@entry=0x7fffff88e150) at ./dlls/win32u/window.c:2084 #13 0x00007f3f112519fa in update_window_state (hwnd=0x6004e) at ./dlls/win32u/window.c:4523 #14 0x00007f3f1120dedd in handle_internal_message (hwnd=<optimized out>, msg=<optimized out>, wparam=0, lparam=<optimized out>) at ./dlls/win32u/message.c:2125 #15 0x00007f3f112122a1 in peek_message (msg=msg@entry=0x7fffff88e9f0, filter=filter@entry=0x7fffff88e9d0) at ./dlls/win32u/message.c:2923 #16 0x00007f3f112138c8 in NtUserPeekMessage (msg_out=0x7fffffa8ff00, hwnd=<optimized out>, first=<optimized out>, last=<optimized out>, flags=<optimized out>) at ./dlls/win32u/message.c:3242 #17 <signal handler called> #18 0x00006ffffe08cd54 in NtUserPeekMessage () from /home/rbernon/Code/build-wine-remote/build64/dlls/win32u/x86_64-windows/win32u.dll #19 0x00006ffffe113965 in PeekMessageW (flags=1024, last=<optimized out>, first=<optimized out>, hwnd=<optimized out>, msg_out=0x7fffffa8ff00) at ./dlls/user32/message.c:762 #20 PeekMessageA (msg=0x7fffffa8ff00, hwnd=<optimized out>, first=<optimized out>, last=<optimized out>, flags=1) at ./dlls/user32/message.c:772 ``` This happens randomly, perhaps more frequently since 2b32c2859166e5542012b517cdef4699d8bb322c, but `update_window_state` could already be called before in other circumstances, and it should not cause a deadlock. More specifically, I don't think we should try to acquire `user_lock` with `display_lock` held, only the other way around. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5060#note_85453

1 0

[PATCH v2 0/6] MR6688: d3dx9: Move targa decoding into d3dx9, part 2.
by Connor McAdams (＠cmcadams) 18 Oct '24

18 Oct '24

These patches finish moving targa file handling into d3dx9. -- v2: d3dx9: Add support for decoding targa files with a color map in d3dx9. d3dx9: Add support for decoding targa files with run length encoding in d3dx9. d3dx9: Add support for decoding targa files with different pixel orders in d3dx9. d3dx9: Add support for loading basic targa images without WIC. d3dx9/tests: Add more tests for loading targa files. https://gitlab.winehq.org/wine/wine/-/merge_requests/6688

4 14

[PATCH 0/1] MR6693: mlang: Only consider true type fonts in map_font().
by Danyil Blyschak (＠blyss) 18 Oct '24

18 Oct '24

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

3 2

[PATCH v2 0/4] MR6695: ntdll/tests: Add reserve object tests.
by Zhiyi Zhang (＠zhiyi) 18 Oct '24

18 Oct '24

Add tests for object type IoCompletionReserve and UserApcReserve. -- v2: ntdll/tests: Add NtAllocateReserveObject() tests. ntdll: Implement NtAllocateReserveObject(). ntdll/tests: Add reserve object tests. gitlab: Update generated files for static analysis. https://gitlab.winehq.org/wine/wine/-/merge_requests/6695

3 6

[PATCH 0/3] MR6695: ntdll/tests: Add reserve object tests.
by Zhiyi Zhang (＠zhiyi) 18 Oct '24

18 Oct '24

Add tests for object type IoCompletionReserve and UserApcReserve. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6695

2 3

[PATCH 0/6] MR6694: user32: Move DND code from winex11 XDND.
by Rémi Bernon (＠rbernon) 18 Oct '24

18 Oct '24

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

2 6

[PATCH v22 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v22: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

3 6

[PATCH v21 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v21: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

3 6

Re: [PATCH v2 0/1] MR6692: ntdll: Add a stub implementation of NtQueryInformationThread(ThreadIdealProcessorEx). - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

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

1 0

Re: [PATCH v2 0/1] MR6691: findstr: Fix codepage passed to WideCharToMultiByte(). - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

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

1 0

Re: [PATCH v2 0/3] MR6689: include: Add IUISettings4/5/6 definition in windows.ui.viewmanagement.idl. - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

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

1 0

Re: [PATCH v4 0/4] MR6658: ddraw: Some fixes for SwapTextureHandles(). - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

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

1 0

Re: [PATCH v4 0/1] MR6661: winegstreamer: Use wmaversion = 4 for MFAudioFormat_WMAudio_Lossless. - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

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

1 0

Re: [PATCH v2 0/5] MR6686: winex11: More XDND code cleanup. - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

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

1 0

Re: [PATCH v3 0/1] MR6674: xml2: Import upstream release 2.12.8. - approved
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

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

1 0

[PATCH v20 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v20: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 5

[PATCH v19 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v19: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 6

[PATCH 0/1] MR6691: findstr: Fix codepage passed to WideCharToMultiByte().
by Hans Leidekker (＠hans) 17 Oct '24

17 Oct '24

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

3 2

[PATCH v18 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v18: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 8

[PATCH v2 0/1] MR6690: sort: New program.
by Hans Leidekker (＠hans) 17 Oct '24

17 Oct '24

-- v2: sort: New program. https://gitlab.winehq.org/wine/wine/-/merge_requests/6690

3 2

[PATCH v17 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v17: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 5

[PATCH 0/1] MR6692: ntdll: Add a stub implementation of NtQueryInformationThread(ThreadIdealProcessorEx).
by Hans Leidekker (＠hans) 17 Oct '24

17 Oct '24

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

2 1

[PATCH v16 0/5] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v16: dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. dlls/winebth.sys: Add a basic unixlib stub using DBus. dlls/winebth.sys: Add base winebth.sys driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 9

[PATCH 0/1] MR6629: winegstreamer: Split large WMA samples.
by Matteo Bruni (＠Mystral) 17 Oct '24

17 Oct '24

Replicate native behavior. This fixes Giana Sister: Twisted Dreams crashing during the intro video. The game expects to be able to fit a few audio samples in a fixed size memory area. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6629

6 18

[PATCH 0/1] MR6513: opengl32: Add WGL_DOUBLE_BUFFER_ARB to the explicit sort list.
by Aida Jonikienė (＠DodoGTA) 17 Oct '24

17 Oct '24

The Legend of Pirates Online expects the formats without WGL_DOUBLE_BUFFER_ARB to be listed first in wglChoosePixelFormatARB() (otherwise it goes into a special wglBindTexImageARB() path which causes blank rendering on both winex11 and winewayland) which was the old winex11 behavior that this change now matches. Fixes: 272c55ac257 ("opengl32: Add default implementation for wglChoosePixelFormatARB.") -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6513

3 4

[PATCH 0/1] MR6690: sort: New program.
by Hans Leidekker (＠hans) 17 Oct '24

17 Oct '24

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

4 3

[PATCH v15 0/9] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v15: dlls/winebth.sys: Update radio PDO properties on receiving PropertiesChanged for an org.bluez.Adapter1 object. dlls/winebth.sys: Remove the corresponding radio PDO on receiving InterfacesRemoved for a org.bluez.Adapter1 object. dlls/winebth.sys: Create new radio PDOs on receiving InterfacesAdded for objects that implement org.bluez.Adapter1. dlls/winebth.sys: Set radio PDO properties from the device's corresponding org.bluez.Adapter1 object properties. dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. dlls/winebth.sys: Add a basic unixlib stub using DBus. dlls/winebth.sys: Add base winebth.sys driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 11

[PATCH 0/3] MR6689: include: Add IUISettings4/5/6 definition in windows.ui.viewmanagement.idl.
by Biswapriyo Nath (＠Biswa96) 17 Oct '24

17 Oct '24

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

2 3

[PATCH v14 0/9] MR6621: winebth.sys part 1: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 17 Oct '24

17 Oct '24

This MR is the first of multiples MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. (Not in this MR, likely in part 2) The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v14: dlls/winebth.sys: Update radio PDO properties on receiving PropertiesChanged for an org.bluez.Adapter1 object. dlls/winebth.sys: Remove the corresponding radio PDO on receiving InterfacesRemoved for a org.bluez.Adapter1 object. dlls/winebth.sys: Create new radio PDOs on receiving InterfacesAdded for objects that implement org.bluez.Adapter1. dlls/winebth.sys: Set radio PDO properties from the device's corresponding org.bluez.Adapter1 object properties. dlls/winebth.sys: Register and enable BTHPORT_DEVICE and BLUETOOTH_RADIO interfaces for radio PDOs. dlls/winebth.sys: Derive a unique hardware ID for radio PDOs from their corresponding BlueZ object path. dlls/winebth.sys: Create radio PDOs from the list of org.bluez.Adapter1 objects on BlueZ. dlls/winebth.sys: Add a basic unixlib stub using DBus. dlls/winebth.sys: Add base winebth.sys driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

4 36

[PATCH 0/6] MR6688: d3dx9: Move targa decoding into d3dx9, part 2.
by Connor McAdams (＠cmcadams) 17 Oct '24

17 Oct '24

These patches finish moving targa file handling into d3dx9. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6688

2 6

[PATCH v3 0/4] MR6658: ddraw: Some fixes for SwapTextureHandles().
by Paul Gofman (＠gofman) 17 Oct '24

17 Oct '24

First of all it fixes a regression introduced by 5a7ff3b45c78784dca0a465d9e21483f72bce6e5 when surface handles were moved to global table but SwapTextureHandles was left behind (https://bugs.winehq.org/show_bug.cgi?id=57300). Then, I am fixing a couple of more issues with this function spotted on the way. I did some initial testing of SwapTextures across devices and that looks messy, device on which the swap is performed influences the outcome in some not immediately obvious way. I omitted the investigation of that because multiple 3d devices in ddraw is already a very exotic use case and I think we are unlikely to meet the usage of SwapTextures across multiple devices. -- v3: ddraw: Update state if d3d_device2_SwapTextureHandles() results in texture change. ddraw: Validate handles in d3d_device2_SwapTextureHandles(). ddraw: Use global handle table in d3d_device2_SwapTextureHandles(). https://gitlab.winehq.org/wine/wine/-/merge_requests/6658

4 7

[PATCH 0/1] MR6666: ntdll: Implement NtWow64QueryInformationProcess64.
by Alex Henrie (＠alexhenrie) 17 Oct '24

17 Oct '24

Needed for GOG Galaxy. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6666

5 5

Re: [PATCH v2 0/1] MR6687: apisetschema: Add api-ms-win-rtcore-ntuser-private-l1-1-1. - closed
by Zhiyi Zhang (＠zhiyi) 17 Oct '24

17 Oct '24

This merge request was closed by Zhiyi Zhang. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6687

1 0

Re: [PATCH v2 0/1] MR6687: apisetschema: Add api-ms-win-rtcore-ntuser-private-l1-1-1.
by Zhiyi Zhang (＠zhiyi) 17 Oct '24

17 Oct '24

On Thu Oct 17 09:32:21 2024 +0000, Alexandre Julliard wrote: > The final version number is supposed to be ignored. Where does this make > a difference? Oh, I see. This is not needed then. Closing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6687#note_85284

1 0

Re: [PATCH v2 0/1] MR6687: apisetschema: Add api-ms-win-rtcore-ntuser-private-l1-1-1.
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

The final version number is supposed to be ignored. Where does this make a difference? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6687#note_85282

1 0

[PATCH 0/5] MR6686: winex11: More XDND code cleanup.
by Rémi Bernon (＠rbernon) 17 Oct '24

17 Oct '24

Last round of cleanup before moving the code to user32. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6686

2 5

[PATCH v2 0/1] MR6674: xml2: Import upstream release 2.12.8.
by Alexandre Julliard (＠julliard) 17 Oct '24

17 Oct '24

-- v2: xml2: Import upstream release 2.12.8. https://gitlab.winehq.org/wine/wine/-/merge_requests/6674

3 2

[PATCH v2 0/4] MR6658: ddraw: Some fixes for SwapTextureHandles().
by Paul Gofman (＠gofman) 17 Oct '24

17 Oct '24

First of all it fixes a regression introduced by 5a7ff3b45c78784dca0a465d9e21483f72bce6e5 when surface handles were moved to global table but SwapTextureHandles was left behind (https://bugs.winehq.org/show_bug.cgi?id=57300). Then, I am fixing a couple of more issues with this function spotted on the way. I did some initial testing of SwapTextures across devices and that looks messy, device on which the swap is performed influences the outcome in some not immediately obvious way. I omitted the investigation of that because multiple 3d devices in ddraw is already a very exotic use case and I think we are unlikely to meet the usage of SwapTextures across multiple devices. -- v2: ddraw: Update state if d3d_device2_SwapTextureHandles() results in texture change. ddraw: Validate handles in d3d_device2_SwapTextureHandles(). ddraw: Use global handle table in d3d_device2_SwapTextureHandles(). ddraw/tests: Fix texture interface IID in test_multiple_devices() for ddraw1. https://gitlab.winehq.org/wine/wine/-/merge_requests/6658

3 6

[PATCH 0/4] MR6658: ddraw: Some fixes for SwapTextureHandles().
by Paul Gofman (＠gofman) 17 Oct '24

17 Oct '24

First of all it fixes a regression introduced by 5a7ff3b45c78784dca0a465d9e21483f72bce6e5 when surface handles were moved to global table but SwapTextureHandles was left behind (https://bugs.winehq.org/show_bug.cgi?id=57300). Then, I am fixing a couple of more issues with this function spotted on the way. I did some initial testing of SwapTextures across devices and that looks messy, device on which the swap is performed influences the outcome in some not immediately obvious way. I omitted the investigation of that because multiple 3d devices in ddraw is already a very exotic use case and I think we are unlikely to meet the usage of SwapTextures across multiple devices. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6658

4 8

Re: [PATCH v3 0/7] MR6672: winetest: Implement JUnit report output mode. - approved
by Alexandre Julliard (＠julliard) 16 Oct '24

16 Oct '24

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

1 0

Re: [PATCH v3 0/3] MR6673: d3dx9: Move targa decoding into d3dx9, part 1. - approved
by Alexandre Julliard (＠julliard) 16 Oct '24

16 Oct '24

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

1 0

2025

2024

2023

2022

wine-gitlab