August 2024 - Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/1] MR4483: nsiproxy.sys: Reduce scope of a variable in process_monitor_event - closed
by Huw Davies (＠huw) Aug. 25, 2024

Aug. 25, 2024

This merge request was closed by Huw Davies. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4483

1 0

[PATCH 0/1] MR6306: msxml3: Fix compilation errors with Clang 18.
by Grigory Vasilyev (＠h0tc0d3) Aug. 24, 2024

Aug. 24, 2024

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

4 7

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

Aug. 24, 2024

On Sat Aug 24 19:23:49 2024 +0000, Vibhav Pant wrote: > Hm, the `BroadcastSystemMessage` calls wouldn't work since the > \`DBT_BROADCAST_DEVICEINTERFACE\` struct needs to be first constructed. > That being said, I have tried to added code that does that to 1/4. 1/4 > also shouldn't have any `DBT_DEVTYP_HANDLE` related code anymore, let me > know if that works. 1/4 also merges the old 1/4 commit, and has been split into 2 commits - for introducing `new_event` and friends. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_79915

1 0

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

Aug. 24, 2024

On Sat Aug 24 19:22:08 2024 +0000, Elizabeth Figura wrote: > Patch 1/4 still needs to be merged into 2/4. > The BroadcastSystemMessage() calls seem to have been inadvertently > removed in 2/4, and the split isn't quite complete—it still introduces > DBT_DEVTYP_HANDLE support in plugplay_send_event(). Ideally separating > the new_event() helper would also be a separate commit, so that you're > not moving code and changing it at the same time. Hm, the `BroadcastSystemMessage` calls wouldn't work since the \`DBT_BROADCAST_DEVICEINTERFACE\` struct needs to be first constructed. That being said, I have tried to added code that does that to 1/4. 1/4 also shouldn't have any `DBT_DEVTYP_HANDLE` related code anymore, let me know if that works. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_79913

1 0

[PATCH v2 0/2] MR5234: win32u: Add registry keys for changing media center/tablet status.
by Aida Jonikienė Aug. 24, 2024

Aug. 24, 2024

This is a heavily simplified version of Michael Müller's staging patch (the staging version got broken by the PE/Unix split) I rebased that staging patch but I thought it was too big for what it does (so I did this instead) As for automatically changing the status, SM_MEDIACENTER would require Windows version checks (which are never used in Wine) and SM_TABLETPC would likely require touchscreen/tablet detection (rbernon is working on some touch stuff so that could be useful) -- v2: win32u: Enable the media center metric by default. win32u: Add registry key for changing tablet status. https://gitlab.winehq.org/wine/wine/-/merge_requests/5234

1 3

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

Aug. 24, 2024

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…. -- v30: plugplay: Add support for DBT_DEVTYP_HANDLE device notifications. plugplay: Broadcast PnP events on a dedicated thread. plugplay: Separate deep-copying the received event into new_event. plugplay: Separate device broadcast event types into their own structs. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 5

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

Aug. 24, 2024

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…. -- v31: plugplay: Add support for DBT_DEVTYP_HANDLE device notifications. plugplay: Broadcast PnP events on a dedicated thread. plugplay: Separate deep-copying the received event into new_event. plugplay: Separate device broadcast event types into their own structs. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

2 4

[PATCH v2 0/1] MR6348: ntdll: Match the new ARM64 KiUserExceptionDispatcher stack layout.
by Billy Laws (＠bylaws) Aug. 24, 2024

Aug. 24, 2024

This is used starting from around build 27686. -- v2: ntdll: Match the new ARM64 KiUserExceptionDispatcher stack layout. https://gitlab.winehq.org/wine/wine/-/merge_requests/6348

2 2

[PATCH v3 0/2] MR6225: Populate ARM64 ID register registry keys using the SMBIOS.
by Billy Laws (＠bylaws) Aug. 24, 2024

Aug. 24, 2024

Takes advantage of linux's ID register emulation. The msr instruction is manually assembled to support older compilers and those that disallow reading e.g. SVE ID registers if unsupported by the target, even though they RAZ if unsupported. This defines a wine-specific SMBIOS table format ontop of the standard additional processor information block to pass ID registers to wineboot. The index of each table within the SMBIOS directly maps to the core it corresponds to and registers are passed using their numerical IDs to match Windows' registry format and avoid needing to map between names and IDs on both ends (the unix side needs to manually encode the msr's anyway). Question: would it be reasonable to add a wine/smbios.h header? I'm unsure if the duplication here is for a good reason. -- v3: wineboot: Populate ARM64 ID register registry keys using SMBIOS info. ntdll: Populate the SMBIOS with ARM64 ID register values. https://gitlab.winehq.org/wine/wine/-/merge_requests/6225

2 2

[PATCH 0/1] MR6348: ntdll: Match the new ARM64 KiUserExceptionDispatcher stack layout.
by Billy Laws (＠bylaws) Aug. 24, 2024

Aug. 24, 2024

This is used starting from around build 27686. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6348

3 2