On Fri Dec 5 15:28:21 2025 +0000, Connor McAdams wrote:
Yes, whatever we come up with will need to be something that uses information accessible from other places, i.e in `winepulse.drv`. I haven't looked too deeply into these patches, but the information acquired through udev here seems to be fine for that use case. The MacOS case I did not track down, but I _think_ there might be a way to get the underlying USB device from a USB audio device there as well. I didn't know about the mmdevapi side. My main concern about the current implementation of container_id is that it is not consistent. It changes with each Wine launch, so apps that use it as an unique device id, wouldn't recognize it. Which would lead to various other issues, such as not loading previously saved device configurations (button mappings, axis settings, FFB settings), etc.
I think that until the mmdevapi part is ready, something like these suggested changes would be sufficient. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9687#note_124978