The sequence of events is:
1. The port calls the miniport with a null buffer and expects the miniport
to indicate the size of the output buffer necessary to hold the name.
2. The client application allocates sufficient memory.
3. The port calls the miniport with the buffer of sufficient size and
expects the miniport to full the buffer with the name.
In particular:
If
IoGetCurrentIrpStackLocation(pIrp)->Parameters.DeviceIoControl.OutputBufferLength
is 0, set pIrp->IoStatus.Information to (number of characters in the name + 1)
* sizeof(WCHAR) where the +1 is for the terminating null WCHAR. Return
STATUS_BUFFER_OVERFLOW.
If the output buffer length is greater than 0 but too small to hold the name,
return STATUS_BUFFER_TOO_SMALL.
Otherwise, copy the name (including the terminating null) to Data and return
STATUS_SUCCESS.
I have created an issue in GitHub for the lack of a sample implementation of
IPinName: https://github.com/microsoft/Windows-driver-samples/issues/455
From: Eugene Muzychenko<mailto:reg.wad@xxxxxxxxxxxxxx>
Sent: Thursday, December 26, 2019 2:27 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [EXTERNAL] [wdmaudiodev] How IPinName::GetPinName should be
implemented?
Both current and old "descriptions" of IPinName::GetPinName are
definitely uninformative:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Fddi%2Fportcls%2Fnf-portcls-ipinname-getpinname&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C179785b58f3e4e039bd008d789ee2e53%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637129528391786692&sdata=Yz%2FY1qMkw%2FP45fZUE6qfJpxQQ%2Bpz38u4dwQeMiyzIOI%3D&reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechnet.microsoft.com%2Fpt-br%2Fff536840%2528v%3Dvs.71%2529.aspx%3Ff%3D255%26MSPPError%3D-2147217396&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C179785b58f3e4e039bd008d789ee2e53%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637129528391796689&sdata=wtscFlq5ym8k8UcHJxqmDQ53YI7NLlc0v7Uhg2J4ePw%3D&reserved=0
There are no examples in WDK sources too.
It is completely unclear what the "Specifies a pointer to the buffer
that holds the data for the GetPinName method" exactly means.
In some cases, value of Data is zero. How to handle this properly?
If the method simply writes a null-terminated pin name string to the
buffer pointed by Data argument, PortCls does not copy it to the
client's output buffer unless the method sets the length of the string
to the Irp->IoStatus.Information. Should the method set this field?
And should it analyze/set other IRP fields?
So where to find a detailed information about GetPinName
implementation to avoid reverse-engineering of portcls.sys and
hdaudio.sys?
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wdmaudiodev.com%2F&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C179785b58f3e4e039bd008d789ee2e53%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637129528391796689&sdata=aPg4BfJaC5mQOUx1NN%2Bs04h7f9KwUebUZc3cAUFClls%3D&reserved=0
