- wine-gitlab - winehq.org

[PATCH 0/3] MR6337: mfplat: Test and implement MFCreateLegacyMediaBufferOnMFMediaBuffer.
by Rémi Bernon (＠rbernon) 22 Aug '24

22 Aug '24

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

3 4

[PATCH 0/1] MR6338: ntoskrnl: Implement IoGetDevicePropertyData().
by Vibhav Pant (＠vibhavp) 22 Aug '24

22 Aug '24

IoGetDevicePropertyData is used to implement the `IOCTL_BTH_GET_DEVICE_INFO` Bluetooth IOCTL to fetch cached information for remote devices, without having to access the device extension pointer (which is arguably racy and more fragile). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6338

4 3

[PATCH v7 0/3] MR5585: mmdevapi: Implement AudioClockAdjustment_SetSampleRate.
by Arek Hiler (＠ivyl) 22 Aug '24

22 Aug '24

This is based on work done by Andrew Eikum. It has been in some form in Proton for the last 4 years. If server's sampling rate is not 48kHz **DOOM Eternal** will try to set it 48kHz for the streams using the implemented interface. There's a whole class of audio devices that use 44.1kHz sampling rate and at least PulseAudio / PipeWire tends to inherit the value from the hardware to avoid resampling. The value can also be overridden by the user via the audio server's config files. In such cases, if the interface is not present or stubbed, this results in **audio underruns and noticeable crackling**. It's easy to test with pipewire-pulse: ``` $ cat /etc/pipewire/pipewire.conf.d/sample-rate.conf context.properties = { default.clock.rate = 41100 } ``` With PulseAudio this should be doable via setting `default-sample-rate = 41100` in `/etc/pulse/daemon.conf`. -- v7: winepulse.drv: Implement set_sample_rate. mmdevapi: Add stub IAudioClockAdjustment implementation. mmdevapi/tests: Add more IAudioClock tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/5585

4 4

[PATCH 0/1] MR6336: ucrtbase: Export powf on i386
by Martin Storsjö (＠mstorsjo) 22 Aug '24

22 Aug '24

The fact that this function was excluded on i386 seems to have been a mistake since the initial version where ucrtbase was added, in 599d92a26822244b9703734a6a8972a0009cdf09; many float math functions (with an -f) suffix is unavailable in ucrtbase.dll on i386, but powf does seem to have existed in all versions of the DLL that I can find. Signed-off-by: Martin Storsjö <martin(a)martin.st> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6336

3 2

[PATCH 0/3] MR6333: odbccp32 valid dsn
by Alistair Leslie-Hughes (＠alesliehughes) 22 Aug '24

22 Aug '24

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

4 6

[PATCH 0/2] MR6335: winsock: Support IPV4 UDP broadcast on connected socket without SO_BROADCAST.
by Paul Gofman (＠gofman) 22 Aug '24

22 Aug '24

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

4 6

[PATCH v3 0/6] MR6332: win32u: Move visible rect computation out of the drivers.
by Rémi Bernon (＠rbernon) 22 Aug '24

22 Aug '24

Using a new GetWindowStyleMasks driver entry to get the style masks to be used to mask out non-client decorations which are hidden by the host decorations. This is done after WindowPosChanging, as winex11 needs to update its managed flag before computing the visible rect, this means that the visible rect might change between WindowPosChanging and WindowPosChanged. It should hopefully be fine. -- v3: win32u: Move the "Decorated" driver registry option out of the drivers. win32u: Move visible rect computation out of the drivers. winemac: Return a macdrv_window_features from get_cocoa_window_features. winex11: Use the driver rects to convert from host visible to window rect. winex11: Keep a window_rects struct in the driver window data. win32u: Keep SetIMECompositionWindowPos with other IME entries. https://gitlab.winehq.org/wine/wine/-/merge_requests/6332

3 8

[PATCH 0/1] MR6334: winevulkan: Fix pointer arithmetic in debug utils callback marshalling.
by Elizabeth Figura (＠zfigura) 21 Aug '24

21 Aug '24

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

2 1

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

21 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…. -- v27: plugplay: Broadcast PnP events on a dedicated thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 4

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

21 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…. -- v24: plugplay: Broadcast PnP events on a dedicated thread. 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 6

2025

2024

2023

2022

wine-gitlab