On Wed, Feb 09, 2022 at 05:54:56PM +0200, Gabriel Ivăncescu wrote:
On 09/02/2022 16:19, Nikolay Sivov wrote:
On 2/9/22 17:10, Gabriel Ivăncescu wrote:
+static HRESULT get_device_path(struct get_device_info_params
Does this belong to winepulse or mmdevapi? Could it be shared, and not depend on the backend? Also, could this use some setupapi API instead of constructing device paths?
Unfortunately I don't know almost anything about mmdevapi, I did work on rebasing the patchset in staging though so at least I'm familiar with it on the winepulse side. winealsa.drv seems to have similar logic though, so you might be right, this could be made more generic for sure.
I'm not sure what's the best way to do that. This function returns a VARIANT, but for this specific prop key, it needs to return a structure of sorts. It needs info about:
- Bus type (PCI, USB)
- Vendor ID
- Product ID
- Device ID
What do you suggest to return? Something custom?
BTW am I correct to assume that this function (GetPropValue) is only called by mmdevapi and thus is internal/its signature can be changed? Or is it possible for an app to call it? Because if the latter I'm afraid I can't see a way out.
For the alsa driver I've added a get_prop_value syscall which handles everything in the unixlib - see the attached patch. Obviously if mmdevapi wants to short-circuit some of these props, it can do so.
I'm trying to keep the syscall interface as similar as possible between the drivers (I'm hoping at some point we could have a single PE-side, not four).
Huw.