- wine-gitlab - winehq.org

[PATCH 0/2] MR6324: gdiplus/metafile: Fix ellipse record size if compressed.
by Akihiro Sagawa (＠sgwaki) 20 Aug '24

20 Aug '24

See FillPie implementation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57083 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6324

3 3

[PATCH 0/2] MR6317: comctl32: handle large tooltip icons
by Cherser-s (＠Cherser-s) 20 Aug '24

20 Aug '24

Added 32x32 icons for TTI_INFO_LARGE, TTI_WARNING_LARGE and TTI_ERROR_LARGE. User-defined icons passed through TTM_SETTITLE message are still drawn as 16x16 icons. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6317

4 5

[PATCH v13 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v13: plugplay: Broadcast PnP events on a dedicated thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 6

[PATCH v3 0/4] MR6304: comctl32/edit: Fix incorrect size for format rect when it is smaller than text.
by Jacob Czekalla (＠JacobCzekalla) 20 Aug '24

20 Aug '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56873 -- v3: comctl32/edit: Fix incorrect size for format rect when it is smaller than text. https://gitlab.winehq.org/wine/wine/-/merge_requests/6304

3 5

[PATCH 0/16] MR6323: Draft: winewayland: Support GL/VK rendering in child windows (alt).
by Rémi Bernon (＠rbernon) 20 Aug '24

20 Aug '24

-- 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/6323

1 0

[PATCH v12 0/3] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v12: plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. include/wine: Add header dbt.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 5

[PATCH v11 0/3] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v11: plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. include/wine: Add header dbt.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

2 3

[PATCH v10 0/3] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v10: plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

2 3

[PATCH v21 0/2] MR5909: comctl32/tests: Add LVM_GETNEXTITEM test.
by Ilia Docin (＠IDocin) 20 Aug '24

20 Aug '24

-- v21: comctl32/listview: Do not return items count on getting next item for last one. comctl32/tests: Add LVM_GETNEXTITEM test. https://gitlab.winehq.org/wine/wine/-/merge_requests/5909

3 5

[PATCH v9 0/3] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v9: plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. include/wine: Add header dbt.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 4

[PATCH v2 0/3] MR6079: shell32: Strip trailing spaces from lpFile in SHELL_execute.
by Louis Lenders (＠xe) 20 Aug '24

20 Aug '24

Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=56940 -- v2: kernel32: Fake success in PowerClearRequest. kernel32: Fake success in PowerSetRequest. kernel32: Fake success in PowerCreateRequest. https://gitlab.winehq.org/wine/wine/-/merge_requests/6079

4 5

[PATCH v8 0/3] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v8: plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 4

[PATCH v16 0/1] MR6075: Add chevron visibility test to check the case of restoring band width to ideal value
by Ilia Docin (＠IDocin) 20 Aug '24

20 Aug '24

I prepared fix https://gitlab.winehq.org/wine/wine/-/commit/b45ad56, that I didn't provide test for, but now I find a way to check it. -- v16: comctl32/tests: Add rebar chevron visibility test. https://gitlab.winehq.org/wine/wine/-/merge_requests/6075

4 4

Re: [PATCH v20 0/2] MR5909: comctl32/tests: Add LVM_GETNEXTITEM test.
by Zhiyi Zhang (＠zhiyi) 20 Aug '24

20 Aug '24

Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/listview.c: > test_LVM_GETCOUNTPERPAGE(); > test_item_state_change(); > test_LVM_SETBKIMAGE(FALSE); > test_custom_sort(); Looks good to me. Let's call test_LVM_GETNEXTITEM() here as well for testing comctl32 v5. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5909#note_79245

1 0

[PATCH 0/1] MR6320: odbccp32: SQLConfigDataSourceW fallback to ConfigDSN when ConfigDSNW cannot be found
by Alistair Leslie-Hughes (＠alesliehughes) 20 Aug '24

20 Aug '24

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

4 3

[PATCH v7 0/3] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v7: plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 4

[PATCH v2 0/4] MR6304: comctl32/edit: Fix incorrect size for format rect when it is smaller than text.
by Jacob Czekalla (＠JacobCzekalla) 20 Aug '24

20 Aug '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56873 -- v2: comctl32/edit: Fix incorrect size for format rect when it is smaller than text. comctl32/tests: Add test for edit control format rect size. user32/edit: Fix incorrect size for format rect when it is smaller than text. user32/tests: Add test for edit control format rect size. https://gitlab.winehq.org/wine/wine/-/merge_requests/6304

4 6

[PATCH v14 0/2] MR6218: comctl32/treeview: Allow treeview parent to deny treeview expansion.
by Jacob Czekalla (＠JacobCzekalla) 20 Aug '24

20 Aug '24

When the listview expands or collapses an item it notifies the parent using the TVN_ITEMEXPANDING message. The parent can return true on this message and it prevents the treeview from expanding or collapsing the item. WINE does not let you deny TVN_ITEMEXPANDING by returning true. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53727 -- v14: comctl32/treeview: Allow treeview parent to deny treeview expansion. comctl32/tests: Add test to check if treeview expansion can be denied. https://gitlab.winehq.org/wine/wine/-/merge_requests/6218

4 4

[PATCH v6 0/3] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v6: plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 5

[PATCH v5 0/3] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 20 Aug '24

20 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v5: plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. include/wine: Add header dbt.h. include/wine/plugplay: Separate device broadcast event types into their own structs. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 5

[PATCH 0/3] MR6321: ODBC fixes
by Hans Leidekker (＠hans) 20 Aug '24

20 Aug '24

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

2 3

[PATCH 0/6] MR6307: Draft: wine: Use atomic locks insted pthread_mutex v2.
by Grigory Vasilyev (＠h0tc0d3) 20 Aug '24

20 Aug '24

I'm not sure about the need for this solution, so it's a **DRAFT**. For me it is an academic interest to check whether atomic locks will give advantages over pthread_mutex in games. Need to think about tests that can actually be measured. Before build need define `USE_AFL`. ```bash export CFLAGS="${CFLAGS} -DUSE_AFL" ``` Old: https://gitlab.winehq.org/wine/wine/-/merge_requests/6031 v2 Changes: - Implemented different types of mutexes, and converted the code to use gcc extensions instead of C11. - Added tests and implemented as a separate library for testing. For tests, need to disable cpufreq scheduler and any power management, otherwise the tests will be unstable. https://github.com/h0tc0d3/afl - Depending on the processor, a regular mutex can be slightly faster or slightly slower. The recursive mutex used in ntdll is more than 2 times faster, and slightly faster with a simple lock-unlock. TODO: - Condvar and RWlocks. With condvar there is a problem of preemption of lower priority threads by a higher priority thread. PI mutex allows to avoid this and takes into account the order, but works much slower. It is not yet entirely clear which condvar is better to use in wine. https://sourceware.org/bugzilla/show_bug.cgi?id=11588 https://static.lwn.net/images/conf/rtlws11/papers/proc/p10.pd - Try to speed up windows synchronization primitives. At this point, I don't quite understand how this works and why the ntsync implementation uses server and vanilla wine doesn't. I would appreciate any help if it would be possible to improve the performance of synchronization primitives by implementing atomic structures. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6307

4 9

[PATCH 0/6] MR6319: winemac: Use window rects to convert window to visible rects.
by Rémi Bernon (＠rbernon) 20 Aug '24

20 Aug '24

Doing this before https://gitlab.winehq.org/wine/wine/-/merge_requests/6310 as there's other gdi_driver.h changes pending. Will do something similar to winex11 after https://gitlab.winehq.org/wine/wine/-/merge_requests/6286 is merged to avoid conflicts. The idea is that once we've computed the visible rect, we can compute visible <-> window rect conversions by using the current offsets only. If the decorations need to be changed, and different window/visible offsets, they will only be changed when window position is updated. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6319

4 8

[PATCH v2 0/1] MR6262: odbc32: SQLSetEnvAttr isnt supported in ODBC v2.0 drvers
by Alistair Leslie-Hughes (＠alesliehughes) 20 Aug '24

20 Aug '24

When using a ODBC v2 driver, the function SQLSetEnvAttr might not be available. -- v2: odbc32: SQLSetEnvAttr isnt supported in ODBC v2.0 https://gitlab.winehq.org/wine/wine/-/merge_requests/6262

4 5

[PATCH v3 0/3] MR6286: win32u: Support setting host IME composition window position for ImmSetCompositionWindow().
by Zhiyi Zhang (＠zhiyi) 20 Aug '24

20 Aug '24

Based on the wine-staging patch winex11-CandidateWindowPos from Felix Yan with works from Muneyuki Noguchi and Sebastian Lackner. -- v3: win32u: Set host IME composition window position in NtUserShowCaret(). win32u: Set host IME composition window position in set_caret_pos(). win32u: Support setting host IME composition window position for ImmSetCompositionWindow(). https://gitlab.winehq.org/wine/wine/-/merge_requests/6286

4 5

2025

2024

2023

2022

wine-gitlab