> the test would hang on wine before the implementation is in place.
Thanks! I missed that the current test cannot verify the Windows behaviour before the commit that introduces the Wine implementation.
> the CloseHandle before the WaitForSingleObject is a workaround to get the thread to exit
I'm afraid that closing a handle in use is racy by nature; it's effectively pulling the rug out from underneath. A better approach would be to use `CancelIoEx` on the `OVERLAPPED` structure, or `NtCancelIoFileEx` on the `IO_STATUS_BLOCK` structure to cancel the pending operation.
>
> moving the CloseHandle was meant to show that workaround is no longer needed and that it now performs like windows
>
> i can remove that if preferred
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/47#note_3873
Some games with support for the haptic feedback and speaker features of the Sony DualSense controller select the controller's audio output by filtering on the ContainerId IMMDevice property to find one that matches the controller's HID's. This MR, together with !359, adds support for exposing such a ContainerId to applications.
I marked this MR as a draft because I understand that the way the ���guid��� is generated is far from ideal. Furthermore, I will need to map from sysfs to container Id in other components as well (`winebus` for the HID device, and possibly `winealsa` and other audio drivers), so moving that part elsewhere would make sense. However, I think I will need help with those tasks.
--
v3: winepulse: Add support for containerId property from sysfs path
winepulse: Store PulseAudio device's sysfs path when available
https://gitlab.winehq.org/wine/wine/-/merge_requests/360
Some games with support for the haptic feedback and speaker features of the Sony DualSense controller select the controller's audio output by filtering on the ContainerId IMMDevice property to find one that matches the controller's HID's. This MR allows this information to be accessible from the IMMDevice's property store when the audio driver provides it (none for now, but I intend to add that feature to `winepulse.drv` and maybe `winealsa.drv`)
This is made specific to containerId rather than supporting VT_CLSID on every property because Wine currently stores VT_BLOBs directly in the registry value, which does not allow us to safely disambiguate between VT_CLSID and VT_BLOB values when reading from registry.
--
v4: mmdevapi: Invalidate ContainerID of unavailable audio devices
mmdevapi: copy ContainerID from audio driver if available
mmdevapi: decode ContainerId property to CLSID in MMDevice_GetPropValue
mmdevapi: support VT_CLSID for containerId property in MMDevice_SetPropValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/359