[PATCH 3/5] winepulse.drv: Implement GetPropValue.

[Huw Davies]

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:
> 
> 1) Bus type (PCI, USB)
> 2) Vendor ID
> 3) Product ID
> 4) 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0045-winealsa-Move-get_prop_value-to-the-unixlib.patch
Type: text/x-diff
Size: 16787 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220209/722575e3/attachment-0001.patch>