From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.apple.com [17.179.253.43]) by mx.groups.io with SMTP id smtpd.web11.2853.1618462744146629926 for ; Wed, 14 Apr 2021 21:59:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=jaF9ayZU; spf=pass (domain: apple.com, ip: 17.179.253.43, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 13F4rSG7017163; Wed, 14 Apr 2021 21:59:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=SVCEAT9uvAlHWzmxZ7HqCIOKenPNrQ1LuwKTy0p01B8=; b=jaF9ayZUB/9i/re+Qbe+oqgKd0E7a1FULU6esklsZ9eIXHgO5G1CHitsVJfC1pB5SmJ9 WPcZwuCFHc4XA2i0aWBpD+0oPA3yaRZ9TlTSDuVUW9n3s3VwDJO0rcgMOFslEbrcLFMh cLc3DXK0OZh6dtcQ+xcm1yW5MkbEW0gJopLK4DMBkwaEkzCjrsiJesK6OsM29JUtOLj3 CcPPUhHMxrs//bscoMGVefWV1rtikii205ppPpaHjcci3avNY1MgNiqi6yK8i225fdc0 bLhv8Ua55kDVwKOHfm5e/G+Xk+rrVzsU3ZjPllzjOE9eSCG7ZZFpy4jzQGGN2AZMJQi5 kQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 37u7v3253k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 14 Apr 2021 21:59:03 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QRL00HBE9U69FH0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 14 Apr 2021 21:58:54 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QRL0070096DHG00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 14 Apr 2021 21:58:54 -0700 (PDT) X-Va-A: X-Va-T-CD: b2a6e213b1e93bac3561a11ee6934d40 X-Va-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-Va-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-Va-CD: 0 X-Va-ID: 7af2782d-4306-4532-bf66-4b7d76d86d51 X-V-A: X-V-T-CD: b2a6e213b1e93bac3561a11ee6934d40 X-V-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-V-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-V-CD: 0 X-V-ID: e9bd92a4-21a2-4c02-bb76-e2d22a33a037 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-15_02:2021-04-15,2021-04-15 signatures=0 Received: from [17.235.1.165] (unknown [17.235.1.165]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QRL00NAL9U3QF00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 14 Apr 2021 21:58:53 -0700 (PDT) From: "Andrew Fish" Message-id: <4AEC1784-99AF-47EF-B7DD-77F91EA3D7E9@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) Date: Wed, 14 Apr 2021 21:58:51 -0700 In-reply-to: Cc: Mike Kinney , "devel@edk2.groups.io" , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann To: Ethin Probst References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-15_01:2021-04-15,2021-04-15 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_E4C8A50D-012C-4481-A599-3FF781D9C523" --Apple-Mail=_E4C8A50D-012C-4481-A599-3FF781D9C523 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 14, 2021, at 9:01 PM, Ethin Probst wrot= e: >=20 > Hi Mike and Andrew, >=20 > Thanks for your responses. I'm looking at the VirtIO block device now > but will certainly have a look at the others as well. We'll also need > to define a completely new protocol for audio, as well, as no existing > protocol will fit the bill. The generic protocol proposed by Andrew > might work, though I was thinking of a couple modifications: primarily > that the audio interface will most likely be asynchronous in nature. > Every audio library I've looked at out there that's open-source is > fully asynchronous, as are operating-system level APIs. For example, > the Microsoft Windows WASAPI audio API requires the application that > uses the audio engine to poll a particular variable that's updated as > the audio stream progresses, as demonstrated here > (https://docs.microsoft.com/en-us/windows/win32/coreaudio/rendering-a-st= ream ). > Obviously, I'm not going to make the code as complicated as the code > shown in the aforementioned example, since this is UEFI and not an > operating system, and making it too complicated would make it > difficult to use and understand, something that I'd like to avoid. > Therefore, for protocol design, would this be satisfactory? Not all of > it needs to be finished for GSoC; I can implement stubs for those that > I don't have time to implement, but I'd like to discuss the protocol > before I start working on a driver for it. I have a (incomplete) > outline of a (hopefully) good protocol at > https://gist.github.com/ethindp/56066e0561b901c1e276e82ff469436d . I'd > appreciate your thoughts on it. >=20 I=E2=80=99d drop the Audio Input part of it. I don=E2=80=99t see a lot of = use recording audio when you boot the system, and it is going to be a mess = dealing with built in microphones etc. vs. input jacks etc. If we wanted to= do input we could define a 2nd protocol that lives on the same handle for = that.=20 The EFI APIs don=E2=80=99t generally have enumeration members so I=E2=80= =99d drop that part too. The driver is going to get started on a PCI devic= e and that is how the device is going to be selection. So we should have a = VirtIO Audio driver, a USB Audio driver, and an HDA Audio driver, not one d= river that does everything. If there are common operations then=20 I really think we need the volume and mute members. I did a prototype for = the emulator a few years back and it looked like [1] as a simple abstract f= or HDA Audo to the system. I assume we could make this generic.=20 The firmware really just wants to play the sound for the canned resource. = The calling code is not some GUI app the user can configure. So I=E2=80=99m= not sure of the value of having to pass in sampleRate, sampleCout, and sam= pleFormat. I think my proposal basically assumed PCM 16 via a WAVE file or = some such. So basically the calling code just has to grab a source and pass= it to the Audio protocol. That is how our GUIs work the artwork is in some= encoding we can decode and that gets converted to something we can draw to= the raw frame buffer.=20 [1] My prototype from a while while back.=20 /** @file Abstraction for audio modeled on the High Definition Audio Specification= .=20 This API is targeted at "Code First" with the UEFI Forum. Thus the plan = is=20 to potential make this a standard in the future and definition will then= move to the MdePkg, and EFI_GUID will likely change.=20 Copyright (c) 2018-2019 Rafael Machado Copyright (c) 2019, Apple Inc. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent **/ #ifndef __HDA_AUDIO_H__ #define __HDA_AUDIO_H__ /// /// Global ID for the HDA Audio Protocol /// // 61EE0891-E13E-11E9-A1C7-823F7D860801 #define CODE_FIRST_HDA_AUDIO_PROTOCOL_GUID \ { \ 0x61EE0891, 0xE13E, 0x11E9, { 0xA1, 0xC7, 0x82, 0x3F, 0x7D, 0x86, 0x08= , 0x01 } \ } typedef struct _CODE_FIRST_HDA_AUDIO_PROTOCOL CODE_FIRST_HDA_AUDIO_PROTOC= OL; typedef INT32 HDA_GAIN; /** The struct of Audio Token. **/ typedef struct { /// /// Event will be signaled when the read audo has been played. /// If only synchronous playback is supported the Event must still get s= ignaled.=20 /// EFI_EVENT Event; /// /// Defines whether or not the signaled event encountered an error. /// EFI_STATUS TransactionStatus; } CODE_FIRST_HDA_AUDIO_TOKEN; /** Play synchronous or asynchronous audio. If Token is passed in the audio = is played asynchronously, if Token is NULL then this call blocks until the Audio i= s complete.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @param[in, out] Token A pointer to the token associated with the = transaction. If NULL this functions blocks until audio p= lay back is complete. @param[in] Buffer PCM encoded buffer of the audio to play.=20 @param[in ] BufferSize The size of Buffer in bytes. @retval EFI_SUCCESS The audio started playing.=20 @retval EFI_UNSUPPORTED Buffer is not a supported format. @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This, IN OUT CODE_FIRST_HDA_AUDIO_TOKEN *Token, OPTIONAL IN UINT8 *Buffer, IN UINT64 BufferSize ); /** Stop playing asynchronous audio.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @param[in, out] Token A pointer to the token associated with the = transaction. @retval EFI_SUCCESS Audio stopped playing.=20 @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_STOP_STREAM)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This, IN CODE_FIRST_HDA_AUDIO_TOKEN *Token ); /** Return the current volume for audio played by this protocol.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @param[out] Gain A pointer to the value returned between 0 a= nd 100.=20 @retval EFI_SUCCESS Gain was returned.=20 @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_GET_VOLUME)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This, IN OUT HDA_GAIN *Gain ); /** Set the current volume for audio played by this protocol. The result of calling this function while audio is playing asynchronousl= y is undefined.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @param[in] Gain A value between 0 and 100 to set the volume= .=20 @retval EFI_SUCCESS Gain was updated.=20 @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_SET_VOLUME)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This, IN OUT HDA_GAIN Gain ); /** Increment the volume in an implementation defined quanta. The value of t= he Gain can never be over 100. The final successful call will round the volume increase to= 100. If this function is called an the Gain is already set to 100 EFI_NO_MAPPING must= be returned.=20 The result of calling this function while audio is playing asynchronousl= y is undefined.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @retval EFI_SUCCESS Gain was incremented.=20 @retval EFI_NO_MAPPING Gasin was not updated since it was already= set to 100. @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_UP)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This ); /** Decrement the volume in an implementation defined quanta. The value of t= he Gain can never be under 0. The final successful call will round the volume decrease to = 0. If this function is called an the Gain is already set to 0 EFI_NO_MAPPING must b= e returned.=20 The result of calling this function while audio is playing asynchronousl= y is undefined.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @retval EFI_SUCCESS Gain was decremented.=20 @retval EFI_NO_MAPPING Gain was not updated since it was already = set to 0. @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_DOWN)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This ); /** Mute audio output, but retain the current Gain (volume Level). The result of calling this function while audio is playing asynchronousl= y is undefined.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @retval EFI_SUCCESS Audio was muted.=20 @retval EFI_ALREADY_STARTED Audio is already muted.=20 @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_MUTE)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This ); /** Unmute audio output, but retain the current Gain (volume Level). The result of calling this function while audio is playing asynchronousl= y is undefined.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @retval EFI_SUCCESS Audio was muted.=20 @retval EFI_ALREADY_STARTED Audio is already unmuted.=20 @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_UNMUTE)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This ); /** Reset the audio hardware.=20 The result of calling this function while audio is playing asynchronousl= y is undefined.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @retval EFI_SUCCESS Audio was muted.=20 @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_RESET)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This ); #define HDA_AUDIO_VERSION 0x00010000 /// /// The CODE_FIRST_HDA_AUDIO_PROTOCOL provides an abstraction for an Audio= device that /// can play PCM files.=20 /// There is one CODE_FIRST_HDA_AUDIO_PROTOCOL instance for each Audio Har= dware device. /// struct _CODE_FIRST_HDA_AUDIO_PROTOCOL { UINT64 Version; CODE_FIRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM PlayStream; CODE_FIRST_HDA_AUDIO_PROTOCOL_STOP_STREAM StopStream; CODE_FIRST_HDA_AUDIO_PROTOCOL_GET_VOLUME GetVolume; CODE_FIRST_HDA_AUDIO_PROTOCOL_SET_VOLUME SetVolume; CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_UP VolumeUp; CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_DOWN VolumeDown;=20 CODE_FIRST_HDA_AUDIO_PROTOCOL_MUTE Mute; CODE_FIRST_HDA_AUDIO_PROTOCOL_UNMUTE UnMute; CODE_FIRST_HDA_AUDIO_PROTOCOL_RESET Reset; }; extern EFI_GUID gBz2387HdaAudioProtocolGuid; #endif Thanks, Andrew Fish > On 4/14/21, Andrew Fish > wrote= : >>=20 >>=20 >>> On Apr 14, 2021, at 3:30 PM, Kinney, Michael D >>> wrote: >>>=20 >>> Hi Ethin, >>>=20 >>> Most UEFI Drivers do use polling. >>>=20 >>> If it is a blocking I/O operation the UEFI Driver waits for completion= . >>> Typically by polling a status register until the I/O is complete and t= hen >>> return status. >>>=20 >>> If it is a non-blocking I/O Operation, then the UEFI Driver can create= a >>> timer event to periodically check the completion status. >>>=20 >>> Non-blocking APIs may also use an event to know when the I/O operation= is >>> completed and this can be used with the CheckEvent() service to poll f= or >>> event completion. >>>=20 >>> These concepts are discussed in the UEFI Driver Writer's Guide. >>>=20 >>> https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk= 2-UefiDriverWritersGuide-draft.pdf >>> > >>>=20 >>> Specifically for audio. If there is an audio playback buffer that wil= l >>> take some time to send, >>> the Audio Protocol would likely define a non-blocking interface to sta= rt >>> playback. You may need >>> an event that is signaled when more audio data is needed or when the >>> playback is complete. You >>> will need to think about the consumer of the Audio Protocol and how it >>> will interact with the >>> Audio Protocol and if the consumer also needs to do other activities w= hile >>> audio is playing or >>> if it is ok for the consumer to wait until the audio playback is >>> completed. >>>=20 >>=20 >> Mike, >>=20 >> It is likely we want async and synchronous playback. If you are playing= a >> boot bong you don=E2=80=99t want to block on its completion. If you are= doing a GUI >> UI you don=E2=80=99t want to block on playback and then do a bunch of G= UI math etc. >>=20 >>=20 >> Ethin, >>=20 >> I=E2=80=99d take a look at some example drivers like VirtioBlkDxe[1]. I= t also looks >> like there is already a VirtioLib[2] to help with house keeping. I did = a >> quick skim and I don=E2=80=99t see a VirtIo device with an Event driven= API. It >> looks like VirtioNetDxe[3] does have the concept of a callback to poll = [4], >> so you might be able to leverage that concept into a timer event to che= ck >> for completion. >>=20 >> I=E2=80=99d not get hung up on the asynchronous part of the API. It mig= ht make sense >> to implement the synchronous version of the API in the driver 1st and f= ake >> the async for your 1st pass. >>=20 >> If you look at other UEFI Async APIs they generally pass around a Token >> (usually an Event to signal on completion, and an EFI_STATUS)[5]. Thus >> faking the Async means making it look like the event fired before your = API >> returned. Assuming that *Token is an argument to the protocol you do th= is to >> fake the Async transaction=E2=80=A6. >>=20 >> If (Token !=3D NULL) { >> Token->TransactionStatus =3D Status; >> gBS->SignalEvent (Token->Event); >> } >>=20 >> This just make it look to the caller like the transaction completed by = the >> time you returned to the caller. So from a caller perspective that is a >> valid way the API could work. The other upside to this is you can make = a >> UEFI Shell App to test the protocol and also add a path to test the asy= nc >> API, even if for the 1st pass implementation that is faked out. >>=20 >> [1] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioBlkDxe >> [2] >> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/VirtioLib= /VirtioLib.c >> [3] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioNetDxe >> [4] >> https://github.com/tianocore/edk2/blob/master/OvmfPkg/VirtioNetDxe/Even= ts.c#L32 >> [5] >> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/B= lockIo2.h#L41 >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> Mike >>>=20 >>>> -----Original Message----- >>>> From: devel@edk2.groups.io > >>>> >> On Behalf Of Ethin >>>> Probst >>>> Sent: Wednesday, April 14, 2021 1:48 PM >>>> To: Andrew Fish >> >>>> Cc: edk2-devel-groups-io >>>> >>; Leif Li= ndholm >>>> >>; Laszlo Ersek = >>>> >>; >>>> Desimone, Nathaniel L >>>> >>; Rafael Rodrigues Machado >>>> >>>> >>; Gerd >>>> Hoffmann >> >>>> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) >>>>=20 >>>> These are some pretty good suggestions; however, while reading throug= h >>>> the VirtIO specification again yesterday, I (re)-discovered that >>>> VirtIO devices are usually interrupt based. In particular, a VirtIO >>>> PCI/PCIe device defines the common, notifications, ISR status, >>>> device-specific configuration, PCI configuration access, shared memor= y >>>> region, and vendor-specific data capability structures in PCI >>>> configuration space. It doesn't look like the EFI_CREATE_EVENT or >>>> EFI_CREATE_EVENT_EX function works via interrupts, from what I can >>>> tell. I'm not sure but it doesn't seem like there's a way I can poll >>>> the device, though I might be missing something. >>>> The idea for the generic protocol is good. The interrupt issue might >>>> be a problem though and I'm not sure how to actually solve that. >>>>=20 >>>> On 4/13/21, Andrew Fish > wr= ote: >>>>> Ethin, >>>>>=20 >>>>> In terms of defining the protocol stack it is good to start with the >>>>> producers and consumers and think about the problem from both >>>>> perspectives. >>>>> It is easy enough to think about the producer part of it as you are >>>>> thinking >>>>> about writing the driver. The driver is going to consume things like= the >>>>> PCI >>>>> I/O Protocol. >>>>>=20 >>>>> The consumer of the sound Protocol is going to most likely be generi= c >>>>> EFI >>>>> platform code, and possibly an OS loader. In the boot process Audio = has >>>>> traditionally be used for error codes, sign of life (for example the >>>>> famous >>>>> Mac startup sound). We are also would like to have the option of >>>>> enabling >>>>> better accessibility features, especially for people how are visuall= y >>>>> impaired. These days a lot of software engineers think of disk space= as >>>>> free >>>>> and really don=E2=80=99t consider the size of software, but this is = not true >>>>> for >>>>> firmware. Firmware generally lives in NOR FLASH that is considered >>>>> expensive >>>>> (it is more expensive than NAND, but at the same time more reliable)= so >>>>> firmware implementations are constrained by the size of the code tha= t >>>>> can be >>>>> carried, and the size of assets/resources that can be used for user >>>>> interfaces. The OS loader is some what less constrained, but it stil= l >>>>> has to >>>>> share the EFI System Partition on the disk with potentially other OS >>>>> loaders. >>>>>=20 >>>>> So the consumer wants a protocol that is unleveled and focused on th= e >>>>> task >>>>> at hand. I=E2=80=99m not too caught up on the names but in general I= think >>>>> things >>>>> you want are (How many knobs we need is probably better answered by = an >>>>> audiophile, and that is not me): >>>>> 1) CompatibleBuffer() - Does driver support this buffer format. >>>>> 2) PlayBuffer() - Play the sound >>>>> =09a) We probably want a synchronous and asynchronous version of thi= s API. >>>>> For >>>>> example you don=E2=80=99t want to slow down the boot to wait for a b= oot beep to >>>>> complete, and you may chose to implement an API that waits for the s= ound >>>>> to >>>>> complete (and do some GUI work in parallel) vs. blocking on the soun= d. >>>>> =09b) async in EFI usually means you return a pointer to an EFI_EVEN= T >>>>> that >>>>> gets signaled on completion. >>>>> 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be >>>>> stopped. >>>>> Think error exit. >>>>> 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (try= ing >>>>> to >>>>> avoid db as that gets into capability and math that is likely best >>>>> abstracted by the driver)? >>>>> 4) Mute()/UnMute() - Mute and volume are often independent features = in a >>>>> UI >>>>> keeping them separate in API makes it easier to implement things. >>>>> 5) PlayTone() - Maybe for error sounds that don=E2=80=99t require ca= nned sound >>>>> files. Maybe TimeOn, TimeOff, Frequency, and how many times to repea= t. >>>>> 6) Do we need tuning values or Tone settings? >>>>>=20 >>>>> At some point we might consider defining nvram variable for the defa= ult >>>>> state of some of the tunable, especially mute and volume. For exampl= e >>>>> the >>>>> user may want to turn off all volume on the system so it would be ni= ce >>>>> if >>>>> the OS can set the EFI volume and mute. In the short run we can prob= ably >>>>> use >>>>> PCD values to set the default values. >>>>>=20 >>>>> So I think we have a generic AUDIO API on top and likely a PCI I/O o= n >>>>> the >>>>> bottom. If we need more protocols to manage hardware devices then th= ose >>>>> protocols can be defined in the context of that hardware. So for exa= mple >>>>> we >>>>> would probably end up with an HDA_CODEC protocol. I think the best w= ay >>>>> to >>>>> think about this is a disk. A lot of disk adapters just produce a ra= w >>>>> Block >>>>> I/O protocol, but for a more common bus like ATA or SCSI you might = have >>>>> an >>>>> extra driver in place to make the common bits common code. I think s= ome >>>>> of >>>>> the same layers may be in place here. So likely VirtIo is simple and >>>>> just >>>>> produces the generic AUDIO API, while an HDA audio driver also has t= o >>>>> abstract some of the complexity of its hardware implementation and >>>>> standard. >>>>>=20 >>>>>=20 >>>>> In terms of picking the set of APIs and tunables it is probably good= to >>>>> start with VirtIo and USB and see what set make sense and what you c= ould >>>>> and >>>>> could not implement. HDA Audio is so complex you might want to look = at >>>>> it in >>>>> terms of the minute you have to implement to make it function. Think >>>>> what >>>>> assumptions are you forced to make to implement. >>>>>=20 >>>>> This is a vey 10,000 foot view to start with. I think you will need = to >>>>> mix >>>>> this in the the reality of how it works in the real world to figure = out >>>>> the >>>>> right abstraction, but then again that is the beauty of having an >>>>> implementation. Likely also get some feedback from audiophiles. >>>>>=20 >>>>> Oh and make sure you don=E2=80=99t go off an implement a lot of code= just >>>>> because we >>>>> chose the wrong complexity or abstraction point. This is the one tim= e we >>>>> get >>>>> to change the public APIs so lets feel free to adjust them to make t= he >>>>> most >>>>> sense for the job at hand. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Andrew Fish >>>>>=20 >>>>>> On Apr 13, 2021, at 6:20 PM, Ethin Probst > >>>>>> wrote: >>>>>>=20 >>>>>> Okay, so looking at the EDK2 driver developers guide, here are my >>>>>> thoughts: >>>>>>=20 >>>>>> - Each audio driver will be a bus driver, even if it doesn't contro= l >>>>>> buses in the traditional sense. >>>>>> - I think the initialization sequence should be different: there >>>>>> should be an AudioDxe, but it should contain three separate bus >>>>>> drivers for each kind of audio device supported. >>>>>> - For the VirtIO audio device driver, it'll most likely consume the >>>>>> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL a= nd >>>>>> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an >>>>>> ordinary UEFI device driver. >>>>>> - The HDA audio device driver will consume the PCI I/O protocol and >>>>>> will produce different device handles per HDA controller found. I'd >>>>>> produce a handle per codec, but that seems overkill. Each handle wi= ll >>>>>> be attached to both an audio stream protocol and a controller >>>>>> management protocol. The audio stream protocol will manage the >>>>>> creation, control, and deletion of audio streams as well as the >>>>>> processing of audio data. The controller management protocol is >>>>>> responsible for allowing applications or other drivers to manage th= e >>>>>> HDA controller itself. >>>>>>=20 >>>>>> I haven't planned for the USB audio device driver yet, but these ar= e >>>>>> my thoughts so far. What do you guys think? Am I over-complicating >>>>>> this setup? How can it be improved upon? >>>>>>=20 >>>>>> On 4/13/21, Ethin Probst via groups.io > >>>>>> >>>>>> >> wrote: >>>>>>> Hi Andrew, >>>>>>>=20 >>>>>>> The developer guide for EDK2 drivers is a godsend. Thank you very >>>>>>> much, and thank you, Mike, for your excellent work on the guide! I >>>>>>> may >>>>>>> just ahve to do my building on Linux and not Windows -- unless the >>>>>>> Bug >>>>>>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, a= t >>>>>>> any rate, since Windows hosts do not support VirtIO emulation and = I >>>>>>> can't seem to find any way of emulating them in a guest machine wi= th >>>>>>> Windows as a host. >>>>>>>=20 >>>>>>> On 4/13/21, Andrew Fish = >> >>>>>>> wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst > >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Would it be possible for us to conduct discussion on the UEFI >>>>>>>>> talkbox? >>>>>>>>> I don't mind using email, but things could definitely get moving >>>>>>>>> quicker over there (though its not a requirement obviously). >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Sure, don=E2=80=99t think I=E2=80=99ve really used that but as lo= ng as I get pointed >>>>>>>> int >>>>>>>> he >>>>>>>> right direction I can make it work. >>>>>>>>=20 >>>>>>>> For a device driver the general UEFI model is for the Entry point= of >>>>>>>> the >>>>>>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported= () >>>>>>>> function >>>>>>>> matches on the PCI devices. The Start() function installs the >>>>>>>> Protocols >>>>>>>> to >>>>>>>> do work, and the Stop() undoes the Start(). >>>>>>>>=20 >>>>>>>> Mike Kinney started this back in the day and it describes how to >>>>>>>> write >>>>>>>> UEFI >>>>>>>> drivers: >>>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver= -Writer%27s-Guide >>>>>>>>=20 >>>>>>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/P= rotocol/DriverBinding.h#L157 >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Andrew Fish >>>>>>>>=20 >>>>>>>>> Here's how I generally envision the driver functioning: >>>>>>>>>=20 >>>>>>>>> 1. Firmware/platform code calls InitaudioOutput() or something l= ike >>>>>>>>> it. This function scans the PCIe bus and scans for one of the >>>>>>>>> following: >>>>>>>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device >>>>>>>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: >>>>>>>>> for >>>>>>>>> USB audio interface (I'm only thinking of targeting XHCI and USB= 4, >>>>>>>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out o= f >>>>>>>>> my >>>>>>>>> hands. If so, it will make things easier. >>>>>>>>> - For USB audio devices I'm not quite sure what to look for; I'm >>>>>>>>> definitely unused to USB. >>>>>>>>> 2. If any of the above cases are found, appropriate driver >>>>>>>>> initialization occurs. Since for the time being I am solely >>>>>>>>> focusing >>>>>>>>> on VirtIO sound devices, the VirtIO general initialization seque= nce >>>>>>>>> will occur as outlined in sec. 3 of the VirtIO specification >>>>>>>>> available >>>>>>>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html = >>>>>>>>> >>>>>>>>> >>. >>>>>>>>> As for actual protocol exposure that would be spec-worthy, for >>>>>>>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. >>>>>>>>> VirtIO >>>>>>>>> is rather simple: there's a buffer for sending and receiving aud= io >>>>>>>>> data in PCM streams. So for that we could expose a Reset(), >>>>>>>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(), >>>>>>>>> Prepare(), Release(), Start(), and Stop() function for the >>>>>>>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG, >>>>>>>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG, >>>>>>>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE, >>>>>>>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and >>>>>>>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things = are >>>>>>>>> a >>>>>>>>> lot more complex, so I'm not sure how that should work. >>>>>>>>> For VirtIO -- which is what I'll focus on for now -- everything = is >>>>>>>>> described, in excellent detail, in sec. 5.14 of the above-linked >>>>>>>>> document. What are your guys's thoughts thus far and how should >>>>>>>>> everything be mapped to UEFI interfaces? >>>>>>>>>=20 >>>>>>>>> On 4/13/21, Andrew Fish > >>>>>>>>> >>> >>>>>>>>> wrote: >>>>>>>>>> Leif, >>>>>>>>>>=20 >>>>>>>>>> Since I have put some brain cells around this area in the past = I >>>>>>>>>> can >>>>>>>>>> be >>>>>>>>>> the >>>>>>>>>> backup and help out too. >>>>>>>>>>=20 >>>>>>>>>> I=E2=80=99d also point out if you are having issues building or= have >>>>>>>>>> general >>>>>>>>>> questions on how things work it is fine to use the mailing list= . >>>>>>>>>> I=E2=80=99ve >>>>>>>>>> got >>>>>>>>>> a >>>>>>>>>> lot of feedback that folks read or search the mailing list look= ing >>>>>>>>>> for >>>>>>>>>> answer to their questions so one person asking can help out a l= ot >>>>>>>>>> of >>>>>>>>>> other >>>>>>>>>> people. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>>=20 >>>>>>>>>> Andrew Fish >>>>>>>>>>=20 >>>>>>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm >>>>>>>>>>> >> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi all, especially Ethin. >>>>>>>>>>>=20 >>>>>>>>>>> Apologies for radio silence - last week I was off on holiday, = and >>>>>>>>>>> before >>>>>>>>>>> that ... let's just say corporate acquisitions generate some >>>>>>>>>>> distractions. >>>>>>>>>>> Anyway, I'm back, and since I'm down as the mentor for this ta= sk, >>>>>>>>>>> feel >>>>>>>>>>> free to spam me with any remaining/new questions. >>>>>>>>>>>=20 >>>>>>>>>>> / >>>>>>>>>>> Leif >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>> >>>>>>>>>>> wrote: >>>>>>>>>>> I'll attach the bug for the build tools to the BZ shortly. >>>>>>>>>>> Laszlo, thanks for that. I don't know their email addresses >>>>>>>>>>> though. >>>>>>>>>>> And yes, I was going to make it device independent, as the >>>>>>>>>>> majority >>>>>>>>>>> (if not all) of UEFI protocols are. >>>>>>>>>>>=20 >>>>>>>>>>> On 4/6/21, Laszlo Ersek >>>>>>>>>>> > >>>>>>>>>>> >> >>>>>>>>>>> > >>>>>>>>>>> >>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote: >>>>>>>>>>>>> Another option is to put the protocol definition in >>>>>>>>>>>>> MdeModulePkg >>>>>>>>>>>>> and >>>>>>>>>>>>> mark it with the EDKII_ prefix. For my last =E2=80=9Ccode fi= rst=E2=80=9D UEFI >>>>>>>>>>>>> spec >>>>>>>>>>>>> contribution I did this with the PPI that added up getting >>>>>>>>>>>>> added. >>>>>>>>>>>>=20 >>>>>>>>>>>> The new audio protocol should be generic, only its >>>>>>>>>>>> implementation >>>>>>>>>>>> in >>>>>>>>>>>> question should be virtio specific. >>>>>>>>>>>>=20 >>>>>>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, a= s >>>>>>>>>>>> well >>>>>>>>>>>> as >>>>>>>>>>>> the developers of the virtio-sound device model in QEMU. >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks >>>>>>>>>>>> Laszlo >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Nate >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *From: * = > >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io >> >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io > >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io >>>> >>>>>>>>>>>>> on >>>>>>>>>>>>> behalf >>>>>>>>>>>>> of "Andrew Fish via groups.io > >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>" >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> *Reply-To: *"devel@edk2.groups.io > >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io >> >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io > >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io >>>" >>>>>>>>>>>>> > >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io >> >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io > >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io >>>>, >>>>>>>>>>>>> "afish@apple.com > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>" >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM >>>>>>>>>>>>> *To: *edk2-devel-groups-io >>>>>>>>>>>>> > >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io >> >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io > >>>>>>>>>>>>> <= mailto:devel@edk2.groups.io >>>>, >>>>>>>>>>>>> "harlydavidsen@gmail.com > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>>" >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> *Cc: *Rafael Rodrigues Machado >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I'm wondering where exactly I should add the VirtIO sound >>>>>>>>>>>>> protocol. >>>>>>>>>>>>> I >>>>>>>>>>>>> just familiarized myself with the build system and am about = to >>>>>>>>>>>>> test >>>>>>>>>>>>> it >>>>>>>>>>>>> by building OVMF if possible, but I'm wondering where I shou= ld >>>>>>>>>>>>> actually put the protocol and all that stuff. Maybe there's >>>>>>>>>>>>> documentation I've missed as well. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Ethin, >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> For the driver I=E2=80=99d match the patter of OVMF [1] and = use >>>>>>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other >>>>>>>>>>>>> drivers >>>>>>>>>>>>> as >>>>>>>>>>>>> a >>>>>>>>>>>>> template. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The protocol is more of a public thing. I think eventually w= e >>>>>>>>>>>>> would >>>>>>>>>>>>> like >>>>>>>>>>>>> to publish the protocol in the UEFI Spec (I can help with th= at >>>>>>>>>>>>> part) >>>>>>>>>>>>> and >>>>>>>>>>>>> that would mean we put the Protocol definition in >>>>>>>>>>>>> MdePkg/Include/Protocol, but we don=E2=80=99t want to do tha= t before it >>>>>>>>>>>>> is >>>>>>>>>>>>> standardized as that causes compatibility issues. So this is= a >>>>>>>>>>>>> =E2=80=9Ccode >>>>>>>>>>>>> first project=E2=80=9D (code prototype and then contribute t= o the UEFI >>>>>>>>>>>>> Forum >>>>>>>>>>>>> for >>>>>>>>>>>>> inclusion in the specification) so we need to follow some co= de >>>>>>>>>>>>> first >>>>>>>>>>>>> rules that I don=E2=80=99t remember of the top of my head? S= o why not >>>>>>>>>>>>> start >>>>>>>>>>>>> out >>>>>>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can al= so >>>>>>>>>>>>> add >>>>>>>>>>>>> a >>>>>>>>>>>>> test application looks like you can just use the root [2] of >>>>>>>>>>>>> OVMF >>>>>>>>>>>>> for >>>>>>>>>>>>> that. That way the project is not blocked. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We can have a conversation on the mailing list about better >>>>>>>>>>>>> places >>>>>>>>>>>>> to >>>>>>>>>>>>> put stuff, and it should be easy enough to move stuff around= if >>>>>>>>>>>>> everything else is working. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [1] find OvmfPkg -iname '*Virtio*.inf' >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -= - >>>>>>>>>>>>> *.inf >>>>>>>>>>>>> | >>>>>>>>>>>>> grep MODULE_TYPE >>>>>>>>>>>>>=20 >>>>>>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13: MODULE_TYPE >>>>>>>>>>>>> =3D UEFI_APPLICATION >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Andrew Fish >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 3/30/21, Ethin Probst via groups.io <= http://groups.io/ > >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>>>>>>>>>>> =3Dgmail.com@groups.io >>>>>>>>>>>>> > >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I agree. Plus, it gives me a chance to finally learn the >>>>>>>>>>>>> EDK2 >>>>>>>>>>>>> build >>>>>>>>>>>>> system and how it works! I've been working on a hobby OS >>>>>>>>>>>>> as >>>>>>>>>>>>> a >>>>>>>>>>>>> side >>>>>>>>>>>>> project and, though learning from other code examples fr= om >>>>>>>>>>>>> OSes >>>>>>>>>>>>> is >>>>>>>>>>>>> fun, I have to say that learning from the firmware code >>>>>>>>>>>>> like >>>>>>>>>>>>> from >>>>>>>>>>>>> SeaBIOS has been some of the most enlightening and >>>>>>>>>>>>> interesting >>>>>>>>>>>>> times >>>>>>>>>>>>> thus far. >>>>>>>>>>>>> Thanks for the link to your code, Rafael; once I get >>>>>>>>>>>>> virtIO >>>>>>>>>>>>> support >>>>>>>>>>>>> in, I can work on HDA support, though I might tackle USB >>>>>>>>>>>>> support >>>>>>>>>>>>> second and HDA third. We'll see, but VirtIO definitely i= s >>>>>>>>>>>>> coming >>>>>>>>>>>>> first. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> As I said before, I look forward to working with all of >>>>>>>>>>>>> you >>>>>>>>>>>>> wonderful >>>>>>>>>>>>> people! >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 3/30/21, Rafael Rodrigues Machado >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This would be amazing so people can continue my work >>>>>>>>>>>>> related >>>>>>>>>>>>> to >>>>>>>>>>>>> accessibility at BIOS. Something desired by the blin= d >>>>>>>>>>>>> people >>>>>>>>>>>>> since the >>>>>>>>>>>>> 90's >>>>>>>>>>>>> Just for reference, this is what I have done: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessib= ility >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >= > >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >= >> >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Rafael >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Em seg, 29 de mar de 2021 20:24, Ethin Probst >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> escreveu: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hello everyone, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This is the first time I've ever contributed to >>>>>>>>>>>>> EDK2. >>>>>>>>>>>>> As >>>>>>>>>>>>> part of GSoC >>>>>>>>>>>>> 2021, I have submitted a proposal to implement a >>>>>>>>>>>>> UEFI >>>>>>>>>>>>> audio output >>>>>>>>>>>>> protocol that will utilize the VirtIO sound >>>>>>>>>>>>> driver. >>>>>>>>>>>>> I've >>>>>>>>>>>>> already >>>>>>>>>>>>> submitted a draft proposal, and apologize if I'v= e >>>>>>>>>>>>> done >>>>>>>>>>>>> things out of >>>>>>>>>>>>> order. This is my first time doing GSoC 2021, an= d >>>>>>>>>>>>> contributing to EDK2 >>>>>>>>>>>>> felt like a really fun thing to do! >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I look forward to working with you guys on this >>>>>>>>>>>>> and >>>>>>>>>>>>> any >>>>>>>>>>>>> future projects! >>>>>>>>>>>>> :-) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Signed, >>>>>>>>>>>>> Ethin D. Probst >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Signed, >>>>>>>>>>>>> Ethin D. Probst >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Signed, >>>>>>>>>>>>> Ethin D. Probst >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Signed, >>>>>>>>>>> Ethin D. Probst >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Signed, >>>>>>>>> Ethin D. Probst >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Signed, >>>>>>> Ethin D. Probst >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Signed, >>>>>> Ethin D. Probst >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Signed, >>>> Ethin D. Probst >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >=20 >=20 > --=20 > Signed, > Ethin D. Probst --Apple-Mail=_E4C8A50D-012C-4481-A599-3FF781D9C523 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 14, 2= 021, at 9:01 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:

Hi Mike and Andrew,
Thanks for your responses. I'm l= ooking at the VirtIO block device now
but will certainly have a look at the others as well. We'll = also need
to define a c= ompletely new protocol for audio, as well, as no existing
protocol will fit the bill. The gener= ic protocol proposed by Andrew
might work, though I was thinking of a couple modifications: primar= ily
that the audio inte= rface will most likely be asynchronous in nature.
Every audio library I've looked at out there tha= t's open-source is
ful= ly asynchronous, as are operating-system level APIs. For example,the Microsoft Windows WASAPI aud= io API requires the application that
uses the audio engine to poll a particular variable that's up= dated as
the audio stre= am progresses, as demonstrated here
(https://docs.microsoft.com/en-us/windows/win32/coreaudio/rendering-a= -stream).
Ob= viously, I'm not going to make the code as complicated as the codeshown in the aforementioned exa= mple, since this is UEFI and not an
operating system, and making it too complicated would make it=
difficult to use and u= nderstand, something that I'd like to avoid.
Therefore, for protocol design, would this be satisfa= ctory? Not all of
it = needs to be finished for GSoC; I can implement stubs for those that<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">I don't have time to implement= , but I'd like to discuss the protocol
before I start working on a driver for it. I have a (incomp= lete)
outline of a (hop= efully) good protocol at
https://gist.github.com/ethindp/= 56066e0561b901c1e276e82ff469436d. I'd
appreciate your thoughts on it.


I=E2=80=99d drop the Audio Inp= ut part of it. I don=E2=80=99t see a lot of use recording audio when you bo= ot the system, and it is going to be a mess dealing with built in microphon= es etc. vs. input jacks etc. If we wanted to do input we could define a 2nd= protocol that lives on the same handle for that. 

The EFI APIs don=E2=80=99t generally have enumeration mem= bers so I=E2=80=99d drop that part too. The driver is going to get started = on a PCI device and that is how the device is going to be selection. So we = should have a VirtIO Audio driver, a USB Audio driver, and an HDA Audio dri= ver, not one driver that does everything. If there are common operations th= en 

I really think we need the vol= ume and mute members. I did a prototype for the emulator a few years back a= nd it looked like [1] as a simple abstract for HDA Audo to the system. I as= sume we could make this generic. 

= The firmware really just wants to play the sound for the canned resource. T= he calling code is not some GUI app the user can configure. So I=E2=80=99m = not sure of the value of having to pass in sampleRate, sampleCout, and samp= leFormat. I think my proposal basically assumed PCM 16 via a WAVE file or s= ome such. So basically the calling code just has to grab a source and pass = it to the Audio protocol. That is how our GUIs work the artwork is in some = encoding we can decode and that gets converted to something we can draw to = the raw frame buffer. 


 [1] My prototype from a while while back. 

/** @file
  Abstraction for audio modeled on the High Definitio= n Audio Specification. 

  This API is targeted at "Code = First" with the UEFI Forum. Thus the plan is 
=   to potential make this a standard in the future and defini= tion will then move
  to the MdePkg,= and EFI_GUID will likely change. 

  Copyright (c) = 2018-2019 Rafael Machado <rafaelrodrigues.machado@gmail.com>
  Copyright (c) 2019, Apple Inc. All rights reserve= d.<BR>
=   SPDX-License-Identifi= er: BSD-2-Clause-Patent

**/

<= span style=3D"font-style: normal;" class=3D"">#ifndef __HDA_AUDIO_H__
#define __HDA_AUDIO_H__

///
/// Global ID for the HDA Audio Protocol
///

// 61EE0891-E13E-11E9-A1C7-823F7D8608= 01
#define CODE_FIRST_HDA_AUDIO_PROTOCOL_= GUID \
  { \
    0x61EE0891, 0xE13E, 0x11E9, { 0xA1, 0xC7, 0x82, 0x= 3F, 0x7D, 0x86, 0x08, 0x01 } \
  }

typedef struct _CODE_FIRST_HDA_AUDIO_PROTOCOL  CODE_FIRST_HDA_= AUDIO_PROTOCOL;


typedef INT32   HDA_GAIN;


/**
  The struct of= Audio Token.
**/
typedef struct {

  ///
  /// Event will be signaled when the read audo has been played= .
  /// If only synchronous playbac= k is supported the Event must still get signaled. 
=
  ///
  EFI_EVEN= T               Event;

  /= //
  /// Defines whether or not the = signaled event encountered an error.
&nbs= p; ///
  EFI_STATUS     &n= bsp;        TransactionStatus;
= } CODE_FIRST_HDA_AUDIO_TOKEN;



/**
  Play synchronous or asy= nchronous audio. If Token is passed in the audio is played
  asynchronously, if Token is NULL then this call bl= ocks until the Audio is complete. 

  @param[in] &nb= sp;    This         A pointer to the CODE_FIR= ST_HDA_AUDIO_PROTOCOL instance.
  @p= aram[in, out] Token        A pointer to the token assoc= iated with the transaction.
   =                     &nbs= p;      If NULL this functions blocks until audio play back = is complete.
=   @param[in]   &nb= sp;  Buffer       PCM encoded buffer of the audio to pl= ay. 
  @param[in ]    = ; BufferSize   The size of Buffer in bytes.

  @retval EF= I_SUCCESS           The audio started playing.&nbs= p;
  @retval EFI_UNSUPPORTED   =     Buffer is not a supported format.
  @retval EFI_OUT_OF_RESOURCES  The request could not be c= ompleted due to a lack of resources.
&nbs= p; @retval EFI_INVALID_PARAMETER One or more parameters are invalid.=

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_H= DA_AUDIO_PROTOCOL_PLAY_STREAM)(
  IN=     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This,
  IN OUT CODE_FIRST_HDA_AUDIO_TOKEN     &n= bsp;*Token,     OPTIONAL
 = IN     UINT8               &n= bsp;           *Buffer,
  IN     UINT64           &= nbsp;              BufferSize
  );


/**
  Stop playing= asynchronous audio. 

  @param[in]      = This         A pointer to the CODE_FIRST_HDA_AUDIO_PROT= OCOL instance.
  @param[in, out] Tok= en        A pointer to the token associated with the tr= ansaction.

<= /div>
  @retval EFI_SUCCESS         =   Audio stopped playing. 
 = ; @retval EFI_OUT_OF_RESOURCES  The request could not be completed due= to a lack of resources.
  @retval E= FI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_= STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROT= OCOL_STOP_STREAM)(
  IN   &nbs= p; CODE_FIRST_HDA_AUDIO_PROTOCOL   *This,
  IN     CODE_FIRST_HDA_AUDIO_TOKEN     &nb= sp;*Token
  );


/**
  Return the current volume for audio played by this protocol. <= /span>

  @param[in]      This      =   A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
  @param[out]     Gain    =     A pointer to the value returned between 0 and 100. 

  @retval EFI_SUCCESS           Gain w= as returned. 
  @retval EFI_OU= T_OF_RESOURCES  The request could not be completed due to a lack of re= sources.
  @retval EFI_INVALID_PARAM= ETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_GET_VOL= UME)(
  IN     CODE_FIRST_= HDA_AUDIO_PROTOCOL  *This,
  IN= OUT HDA_GAIN                  = ;     *Gain
  );


/**
  Set the current volume for audio played by this pro= tocol.
  
  The result of calling this function while audio is play= ing asynchronously is undefined. 

  @param[in] &nb= sp;    This         A pointer to the CODE_FIR= ST_HDA_AUDIO_PROTOCOL instance.
  @p= aram[in]      Gain         A value betwe= en 0 and 100 to set the volume. 
=   @retval EFI_SUCCESS &= nbsp;         Gain was updated. 
  @retval EFI_OUT_OF_RESOURCES  The request coul= d not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are inva= lid.

<= div>**/
typedef=
EFI_STATUS
(EFIAPI *= CODE_FIRST_HDA_AUDIO_PROTOCOL_SET_VOLUME)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL    *This,=
  IN OUT HDA_GAIN     &= nbsp;                   Gain
  );


/**
  I= ncrement the volume in an implementation defined quanta. The value of the G= ain can never
  be over 100. The fin= al successful call will round the volume increase to 100. If this
  function is called an the Gain is already s= et to 100 EFI_NO_MAPPING must be returned. 
  
  The result of= calling this function while audio is playing asynchronously is undefined.&= nbsp;

=
  @param[in]      This     &nb= sp;   A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.<= /font>

  @retval EFI_SUCCESS           Gain was in= cremented. 
  @retval EFI_NO= _MAPPING        Gasin was not updated since it was alre= ady set to 100.
  @retval EFI_OUT_OF= _RESOURCES  The request could not be completed due to a lack of resour= ces.
  @retval EFI_INVALID_PARAMETER= One or more parameters are invalid.

<= span style=3D"font-style: normal;" class=3D"">**/
<= font face=3D"Andale Mono" class=3D"">typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_UP)(<= /span>
  IN     CODE_FIRST_HDA= _AUDIO_PROTOCOL   *This
  );


/**<= /div>
  Decrement the volume in an implementation define= d quanta. The value of the Gain can never
  be under 0. The final successful call will round the volume decreas= e to 0. If this
  function is called= an the Gain is already set to 0 EFI_NO_MAPPING must be returned. 
  
  The result of calling this function while audio is playing asynch= ronously is undefined. 

  @param[in]      = ;This         A pointer to the CODE_FIRST_HDA_AUDIO_PRO= TOCOL instance.

  @retval EFI_SUCCESS       &n= bsp;   Gain was decremented. 
  @retval EFI_NO_MAPPING        Gain was not upda= ted since it was already set to 0.
 = @retval EFI_OUT_OF_RESOURCES  The request could not be completed due = to a lack of resources.
  @retval EF= I_INVALID_PARAMETER One or more parameters are invalid.
=

**/=
typedef
EFI_S= TATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTO= COL_VOLUME_DOWN)(
  IN   &nbs= p; CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
  );


/**
  Mute audio output, but = retain the current Gain (volume Level).
    
  The result of= calling this function while audio is playing asynchronously is undefined.&= nbsp;

=
  @param[in]      This     &nb= sp;   A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.<= /font>

  @retval EFI_SUCCESS           Audio was m= uted. 
<= span style=3D"font-style: normal;" class=3D"">  @retval EFI_ALREADY_ST= ARTED   Audio is already muted. 
  @retval EFI_OUT_OF_RESOURCES  The request could not be comple= ted due to a lack of resources.
  @r= etval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_H= DA_AUDIO_PROTOCOL_MUTE)(
  IN  =   CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
=   );

/**
  U= nmute audio output, but retain the current Gain (volume Level).
    
  The result of calling this function while audio is playing asynchr= onously is undefined. 

  @param[in]      = This         A pointer to the CODE_FIRST_HDA_AUDIO_PROT= OCOL instance.

  @retval EFI_SUCCESS       &nb= sp;   Audio was muted. 
  = @retval EFI_ALREADY_STARTED   Audio is already unmuted. 
  @retval EFI_OUT_OF_RESOURCES  The req= uest could not be completed due to a lack of resources.
=
  @retval EFI_INVALID_PARAMETER One or more parameters = are invalid.
=
**/
typedef<= /font>
EFI_STATUS
(EF= IAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_UNMUTE)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
  );


/**
  R= eset the audio hardware. 
  &nb= sp; 
  The result of calling th= is function while audio is playing asynchronously is undefined. 

  @param[in]      This       &nbs= p; A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.

 = @retval EFI_SUCCESS           Audio was muted.&nb= sp;
  @retval EFI_OUT_OF_RESOURCES &= nbsp;The request could not be completed due to a lack of resources.<= /font>
  @retval EFI_INVALID_PARAMETER One or more= parameters are invalid.

<= /span>
**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_RESET)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL &n= bsp; *This
  );
<= div>

#define HDA_AUDIO_VERSION 0x00010= 000

///
/// The CODE_FIRST_HD= A_AUDIO_PROTOCOL provides an abstraction for an Audio device that
/// can play PCM files. 
<= div>/// There is one CODE_FIRST_HDA_AUDIO_PROTOCOL instance for e= ach Audio Hardware device.
///
struct _CODE_FIRST_HDA_AUDIO_PROTOCOL {
  UINT64           &nb= sp;                     &= nbsp;    Version;
  CODE_F= IRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM   PlayStream;
<= div>  CODE_FIRST_HDA_AUDIO_PROTOCOL_STOP_STREAM   StopS= tream;
  CODE_FIRST_HDA_AUDIO_PROTOC= OL_GET_VOLUME    GetVolume;  
  CODE_FIRST_HDA_AUDIO_PROTOCOL_SET_VOLUME    SetVolu= me;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_= VOLUME_UP     VolumeUp;
  = CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_DOWN   VolumeDown; 
  CODE_FIRST_HDA_AUDIO_PROTOCOL_MUTE   =        Mute;
  C= ODE_FIRST_HDA_AUDIO_PROTOCOL_UNMUTE        UnMute;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_RESET &n= bsp;       Reset;
};

extern EFI_GUID gBz2387HdaAudioProtocolGuid;

#endif<= /font>


=
Thanks,

Andrew Fish
On = 4/14/21, Andrew Fish <afish@apple.com> wrote:=


On Apr 14, 2021,= at 3:30 PM, Kinney, Michael D
<michael.d.kinney@intel.com> wrote:
Hi Ethin,

Most UEFI= Drivers do use polling.

If it is a blocking I= /O operation the UEFI Driver waits for completion.
Typically = by polling a status register until the I/O is complete and then
return status.

If it is a non-blocking I/O = Operation, then the UEFI Driver can create a
timer event to p= eriodically check the completion status.

Non-b= locking APIs may also use an event to know when the I/O operation is
completed and this can be used with the CheckEvent() service to pol= l for
event completion.

These co= ncepts are discussed in the UEFI Driver Writer's Guide.

https://tian= ocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWrite= rsGuide-draft.pdf
<https://tianocore-docs.github.io/edk2-UefiDriverWritersGu= ide/draft/edk2-UefiDriverWritersGuide-draft.pdf>

Specifically for audio.  If there is an audio playback buffe= r that will
take some time to send,
the Audio P= rotocol would likely define a non-blocking interface to start
playback.  You may need
an event that is signaled when = more audio data is needed or when the
playback is complete. &= nbsp;You
will need to think about the consumer of the Audio P= rotocol and how it
will interact with the
Audio= Protocol and if the consumer also needs to do other activities while
audio is playing or
if it is ok for the consumer to = wait until the audio playback is
completed.

Mike,

= It is likely we want async and synchronous playback. If you are playing aboot bong you don=E2=80=99t want to block on its completion. I= f you are doing a GUI
UI you don=E2=80=99t want to block on p= layback and then do a bunch of GUI math etc.

<= br class=3D"">Ethin,

I=E2=80=99d take a look a= t some example drivers like VirtioBlkDxe[1]. It also looks
li= ke there is already a VirtioLib[2] to help with house keeping. I did a
quick skim and I don=E2=80=99t see a VirtIo device with an Event = driven API.  It
looks like VirtioNetDxe[3] does have the= concept of a callback to poll [4],
so you might be able to l= everage that concept into a timer event to check
for completi= on.

I=E2=80=99d not get hung up on the asynchr= onous part of the API. It might make sense
to implement the s= ynchronous version of the API in the driver 1st and fake
the = async for your 1st pass.

If you look at other = UEFI Async APIs they generally pass around a Token
(usually a= n Event to signal on completion, and an EFI_STATUS)[5]. Thus
= faking the Async means making it look like the event fired before your API<= br class=3D"">returned. Assuming that *Token is an argument to the protocol= you do this to
fake the Async transaction=E2=80=A6.

If (Token !=3D NULL) {
 Token->= TransactionStatus =3D Status;
 gBS->SignalEvent (Toke= n->Event);
}

This just make i= t look to the caller like the transaction completed by the
ti= me you returned to the caller. So from a caller perspective that is a
valid way the API could work. The other upside to this is you can = make a
UEFI Shell App to test the protocol and also add a pat= h to test the async
API, even if for the 1st pass implementat= ion that is faked out.

[1] http= s://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioBlkDxe
[2]
https://github.com= /tianocore/edk2/blob/master/OvmfPkg/Library/VirtioLib/VirtioLib.c
[3] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioNe= tDxe
[4]
https://github.com/tianocore/edk2/blob= /master/OvmfPkg/VirtioNetDxe/Events.c#L32
[5]
h= ttps://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/BlockI= o2.h#L41

Thanks,

= Andrew Fish

Mike

-= ----Original Message-----
From: dev= el@edk2.groups.io <= ;mailto:devel@edk2.group= s.io>
<devel@edk2.groups.io = <mailto:devel@= edk2.groups.io>> On Behalf Of Ethin
Probst
Sent: Wednesday, April 14, 2021 1:48 PM
To: Andrew Fis= h <afish@apple.com <mailto:afish@apple.com>>
Cc: = edk2-devel-groups-io <devel@edk2.groups.io
<mailto:devel@edk2.groups.io>>; Leif Lindholm = <leif@nuviainc.com<mailto:lei= f@nuviainc.com>>; Laszlo Ersek <lersek@redhat.com
<mailto:lersek@redhat.com>>;
Desimone, Nathaniel L <nathaniel.l.desimone@intel.com
<mailto:nathaniel= .l.desimone@intel.com>>; Rafael Rodrigues Machado
&= lt;rafaelro= drigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.c= om>>; Gerd
Hoffmann <kraxel@redhat.com <mailt= o:kraxel@redhat.com>>
Subject: Re: [edk2-devel] Vir= tIO Sound Driver (GSoC 2021)

These are some pr= etty good suggestions; however, while reading through
the Vir= tIO specification again yesterday, I (re)-discovered that
Vir= tIO devices are usually interrupt based. In particular, a VirtIO
PCI/PCIe device defines the common, notifications, ISR status,
device-specific configuration, PCI configuration access, shared me= mory
region, and vendor-specific data capability structures i= n PCI
configuration space. It doesn't look like the EFI_CREAT= E_EVENT or
EFI_CREATE_EVENT_EX function works via interrupts,= from what I can
tell. I'm not sure but it doesn't seem like = there's a way I can poll
the device, though I might be missin= g something.
The idea for the generic protocol is good. The i= nterrupt issue might
be a problem though and I'm not sure how= to actually solve that.

On 4/13/21, Andrew Fi= sh <afish@apple.com>= ; wrote:
Ethin,

In terms of defining the protocol stack it is good to= start with the
producers and consumers and think about the p= roblem from both
perspectives.
It is easy enoug= h to think about the producer part of it as you are
thinking<= br class=3D"">about writing the driver. The driver is going to consume thin= gs like the
PCI
I/O Protocol.
The consumer of the sound Protocol is going to most likely be g= eneric
EFI
platform code, and possibly an OS lo= ader. In the boot process Audio has
traditionally be used for= error codes, sign of life (for example the
famous
Mac startup sound). We are also would like to have the option of
enabling
better accessibility features, especially= for people how are visually
impaired. These days a lot of so= ftware engineers think of disk space as
free
an= d really don=E2=80=99t consider the size of software, but this is not true<= br class=3D"">for
firmware. Firmware generally lives in NOR F= LASH that is considered
expensive
(it is more e= xpensive than NAND, but at the same time more reliable) so
fi= rmware implementations are constrained by the size of the code that
can be
carried, and the size of assets/resources that = can be used for user
interfaces. The OS loader is some what l= ess constrained, but it still
has to
share the = EFI System Partition on the disk with potentially other OS
lo= aders.

So the consumer wants a protocol that i= s unleveled and focused on the
task
at hand. I= =E2=80=99m not too caught up on the names but in general I think
things
you want are (How many knobs we need is probabl= y better answered by an
audiophile, and that is not me):
1) CompatibleBuffer() - Does driver support this buffer format.2) PlayBuffer() - Play the sound
a) We probably want a s= ynchronous and asynchronous version of this API.
For
example you don=E2=80=99t want to slow down the boot to wait for a b= oot beep to
complete, and you may chose to implement an API t= hat waits for the sound
to
complete (and do som= e GUI work in parallel) vs. blocking on the sound.
b) async in EFI us= ually means you return a pointer to an EFI_EVENT
that
gets signaled on completion.
3) StopBuffer() - In case= the asynchronous PlayBuffer() needs to be
stopped.
Think error exit.
3) SetVolume()/GetVolume() - Set/Get= Volume in units of 0 - 100 (trying
to
avoid db= as that gets into capability and math that is likely best
ab= stracted by the driver)?
4) Mute()/UnMute() - Mute and volume= are often independent features in a
UI
keeping= them separate in API makes it easier to implement things.
5)= PlayTone() - Maybe for error sounds that don=E2=80=99t require canned soun= d
files. Maybe TimeOn, TimeOff, Frequency, and how many times= to repeat.
6) Do we need tuning values or Tone settings?

At some point we might consider defining nvram va= riable for the default
state of some of the tunable, especial= ly mute and volume. For example
the
user may wa= nt to turn off all volume on the system so it would be nice
i= f
the OS can set the EFI volume and mute. In the short run we= can probably
use
PCD values to set the default= values.

So I think we have a generic AUDIO AP= I on top and likely a PCI I/O on
the
bottom. If= we need more protocols to manage hardware devices then those
protocols can be defined in the context of that hardware. So for examplewe
would probably end up with an HDA_CODEC proto= col. I think the best way
to
think about this i= s a disk. A lot of disk adapters just produce a raw
Block
I/O  protocol, but for a more common bus like ATA or SCSI y= ou might have
an
extra driver in place to make = the common bits common code. I think some
of
th= e same layers may be in place here. So likely VirtIo is simple and
just
produces the generic AUDIO API, while an HDA audi= o driver also has to
abstract some of the complexity of its h= ardware implementation and
standard.


In terms of picking the set of APIs and tunables it i= s probably good to
start with VirtIo and USB and see what set= make sense and what you could
and
could not im= plement. HDA Audio is so complex you might want to look at
it= in
terms of the minute you have to implement to make it func= tion. Think
what
assumptions are you forced to = make to implement.

This is a vey 10,000 foot v= iew to start with. I think you will need to
mix
this in the the reality of how it works in the real world to figure outthe
right abstraction, but then again that is the= beauty of having an
implementation. Likely also get some fee= dback from audiophiles.

Oh and make sure you d= on=E2=80=99t go off an implement a lot of code just
because w= e
chose the wrong complexity or abstraction point. This is th= e one time we
get
to change the public APIs so = lets feel free to adjust them to make the
most
= sense for the job at hand.

Thanks,

Andrew Fish

On Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com= >
wrote:

Okay, so looking at = the EDK2 driver developers guide, here are my
thoughts:

- Each audio driver will be a bus driver, even if i= t doesn't control
buses in the traditional sense.
- I think the initialization sequence should be different: there
should be an AudioDxe, but it should contain three separate bus
drivers for each kind of audio device supported.
- = For the VirtIO audio device driver, it'll most likely consume the
PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL an= d
EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just b= e an
ordinary UEFI device driver.
- The HDA aud= io device driver will consume the PCI I/O protocol and
will p= roduce different device handles per HDA controller found. I'd
produce a handle per codec, but that seems overkill. Each handle will
be attached to both an audio stream protocol and a controller
management protocol. The audio stream protocol will manage thecreation, control, and deletion of audio streams as well as th= e
processing of audio data. The controller management protoco= l is
responsible for allowing applications or other drivers t= o manage the
HDA controller itself.

I haven't planned for the USB audio device driver yet, but these are=
my thoughts so far. What do you guys think? Am I over-compli= cating
this setup? How can it be improved upon?

On 4/13/21, Ethin Probst via groups.io<= span class=3D"Apple-converted-space"> <http://groups.io/>
<harlydavidsen=3Dgmai= l.com@groups.io
<mailto:harlydavidsen=3Dgmail.com@groups.io= >> wrote:
Hi Andre= w,

The developer guide for EDK2 drivers is a g= odsend. Thank you very
much, and thank you, Mike, for your ex= cellent work on the guide! I
may
just ahve to d= o my building on Linux and not Windows -- unless the
Bug
-- bug 3302 -- has been fixed. I'll have to do testing on Linux, = at
any rate, since Windows hosts do not support VirtIO emulat= ion and I
can't seem to find any way of emulating them in a g= uest machine with
Windows as a host.

On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com<= /a>>>
wrote:


On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
wro= te:

Would it be possible for us to conduct dis= cussion on the UEFI
talkbox?
I don't mind using= email, but things could definitely get moving
quicker over t= here (though its not a requirement obviously).


Sure, don=E2=80=99t think I=E2=80=99ve really = used that but as long as I get pointed
int
heright direction I can make it work.

For a device driver the general UEFI model is for the Entry point of
the
driver to publish a EFI_DRIVER_BINDING_PROTOCO= L[1]. The Supported()
function
matches on the P= CI devices. The Start() function installs the
Protocols
to
do work, and the Stop() undoes the Start().

Mike Kinney started this back in the day and it des= cribes how to
write
UEFI
drivers:=
https://github.com/tianocore/= tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
[1]https://github.com/ti= anocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
Thanks,

Andrew Fis= h

Here's = how I generally envision the driver functioning:

1. Firmware/platform code calls InitaudioOutput() or something like
it. This function scans the PCIe bus and scans for one of the
following:
- Vendor ID 0x1AF4, device ID 0x1059: V= irtIO sound device
- PCI class 0x0C, subclass 0x03, program i= nterface 0x30 or 0x40:
for
USB audio interface = (I'm only thinking of targeting XHCI and USB 4,
and not UHCI,= OHCI or EHCI). But maybe EDK2 will take that out of
my
hands. If so, it will make things easier.
- For USB = audio devices I'm not quite sure what to look for; I'm
defini= tely unused to USB.
2. If any of the above cases are found, a= ppropriate driver
initialization occurs. Since for the time b= eing I am solely
focusing
on VirtIO sound devic= es, the VirtIO general initialization sequence
will occur as = outlined in sec. 3 of the VirtIO specification
available
at htt= ps://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
<https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html<= /a>
<https://www.kraxel.org/virtio/virtio-v1.1-cs= 01-sound-v7.html>>.
As for actual protocol exposure= that would be spec-worthy, for
EFI_AUDIO_OUTPUT_PROTOCOL, I'= m not quite sure what to expose.
VirtIO
is rath= er simple: there's a buffer for sending and receiving audio
d= ata in PCM streams. So for that we could expose a Reset(),
Re= mapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
P= repare(), Release(), Start(), and Stop() function for the
cor= responding request types VIRTIO_SND_R_JACK_GET_CONFIG,
VIRTIO= _SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_= PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
VIRTIO_SND_R_PCM_RE= LEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP cont= rol requests. However, for HDA things are
a
lot= more complex, so I'm not sure how that should work.
For Virt= IO -- which is what I'll focus on for now -- everything is
de= scribed, in excellent detail, in sec. 5.14 of the above-linked
document. What are your guys's thoughts thus far and how should
everything be mapped to UEFI interfaces?

On 4/13/21, Andrew Fish <afish@apple.com <= mailto:afish@apple.com>= ;
<mailto:af= ish@apple.com <mailto:afish@apple.com>&g= t;>
wrote:
Leif,

Since I have put some brain cells= around this area in the past I
can
be
the
backup and help out too.

I=E2=80=99d also point out if you are having issues building or have=
general
questions on how things work it is fin= e to use the mailing list.
I=E2=80=99ve
got
a
lot of feedback that folks read or search the ma= iling list looking
for
answer to their question= s so one person asking can help out a lot
of
ot= her
people.

Thanks,

Andrew Fish

On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com
<mailto:leif@nuviainc= .com>> wrote:

Hi all, especially Eth= in.

Apologies for radio silence - last week I = was off on holiday, and
before
that ... let's j= ust say corporate acquisitions generate some
distractions.Anyway, I'm back, and since I'm down as the mentor for this tas= k,
feel
free to spam me with any remaining/new = questions.

/
Leif
=
On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst
&l= t;harlydavidsen@gmail= .com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com><= br class=3D""><mai= lto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>>>= >
wrote:
I'll attach the bug for the build t= ools to the BZ shortly.
Laszlo, thanks for that. I don't know= their email addresses
though.
And yes, I was g= oing to make it device independent, as the
majority
(if not all) of UEFI protocols are.

On = 4/6/21, Laszlo Ersek <le= rsek@redhat.com
<mailto:lersek@redhat.com>
<mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
<mailto:lersek@redhat.com<= span class=3D"Apple-converted-space"> <mailto:lersek@redhat.com>
&= lt;mailto:lersek@redhat.com=  <mailto:lersek@redhat.com>>>>= ;
wrote:
O= n 03/31/21 08:41, Nate DeSimone wrote:
Another option is to put the protocol definition in
MdeModulePkg
and
mark it with the EDKII_= prefix. For my last =E2=80=9Ccode first=E2=80=9D UEFI
speccontribution I did this with the PPI that added up getting
added.

The new audio p= rotocol should be generic, only its
implementation
in
question should be virtio specific.
<= br class=3D"">Please include Gerd Hoffmann (CC'd) in the protocol design, a= s
well
as
the developers of the v= irtio-sound device model in QEMU.

Thanks
Laszlo





Thanks,<= br class=3D"">
Nate



*From: *<devel@edk2.groups.io = <mailto:devel@= edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2= .groups.io <mailto:devel@edk2.groups.io>>>>
on
behalf
of "A= ndrew Fish via groups.io <http://gro= ups.io/>
<= http://groups.io/ <= ;http://groups.io/>> <= ;http://groups.io/
<http://groups.io/><http://groups.io/=  <http://groups.io/>>>"
&= lt;afish=3Dapple.= com@groups.io <mailto:afish=3Dapple= .com@groups.io>
<mailto:afish=3Dapple.com@groups.io
<mailto:afis= h=3Dapple.com@groups.io>>
<mailto:apple.com@groups.io <mailto:apple.com@groups.io>
<mailto:apple.com@groups.io<= span class=3D"Apple-converted-space"> <mailto:apple.com@groups.io>>>>=
*Reply-To: *"devel@edk2.groups.io = <mailto:devel@= edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2= .groups.io <mailto:devel@edk2.groups.io>>>"
<devel@edk2.groups.io&nbs= p;<mailto:deve= l@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2= .groups.io <mailto:devel@edk2.groups.io>>>>,
"afish@apple.com <mailto:afish@apple.com<= /a>>
<mai= lto:afish@apple.com
<mailto:afish@apple.com>> <mailto:afish@apple.com
<mailto:afish@apple.com>
<mailto:afish@ap= ple.com <mailto:afish@apple.com>>&= gt;"
<afish@= apple.com <mailto:afish@apple.com>
<mailto:afish@ap= ple.com
<mailto:afish@apple.com>>
<mailto:afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <m= ailto:afish@apple.com>>>>
*Date: *Tuesday, Ma= rch 30, 2021 at 10:54 PM
*To: *edk2-devel-groups-io <devel@edk2.groups.io
<mailto:dev= el@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2= .groups.io <mailto:devel@edk2.groups.io>>>>,
"harlydavidsen@gmail.com <m= ailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com
<mailto:h= arlydavidsen@gmail.com>>
<mailto:harlydavidsen@gmail.com
<mailto:har= lydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com
= <mailto:harlydavid= sen@gmail.com>>>"
<harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmai= l.com
<mailto:harlydavidsen@gmail.com>>
<mailto:harlydavidsen@gmail.= com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com
<= mailto:harlydavidsen@gmail.com>>>>
*Cc: *Rafa= el Rodrigues Machado
<rafaelrodrigues.machado@gmail.com
<= mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodr= igues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com= >>
<mailto:rafaelrodrigues.machado@gmail.com
<= mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodr= igues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com= >>>>
*Subject: *Re: [edk2-devel] VirtIO Sound= Driver (GSoC 2021)





On Mar 30, 2021, at 5:01 PM, Ethin Pro= bst
<harlydavidsen@gmail.com <mailto:harlyd= avidsen@gmail.com>
<mailto:harlydavidsen@gmail.com
<= ;mailto:harlydavidsen= @gmail.com>>
<mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gm= ail.com>
<mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.= com>>>
<mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail= .com>
<mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>>
<mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com&g= t;
<= mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>>&= gt;>>
wrote:



I'm wondering where exactly I should add the VirtIO sound<= br class=3D"">protocol.
I
just familiarized mys= elf with the build system and am about to
test
= it
by building OVMF if possible, but I'm wondering where I sh= ould
actually put the protocol and all that stuff. Maybe ther= e's
documentation I've missed as well.



Ethin,


For the driver I=E2=80=99d match the patter of = OVMF [1] and use
OvmfPkg/VirtioSoundDxe/. Maybe even use one = of the other
drivers
as
a
template.



The protocol is more of a public thing. I think eventually we
would
like
to publish the protocol in the UEF= I Spec (I can help with that
part)
and
that would mean we put the Protocol definition in
MdeP= kg/Include/Protocol, but we don=E2=80=99t want to do that before it
is
standardized as that causes compatibility issues. S= o this is a
=E2=80=9Ccode
first project=E2=80= =9D (code prototype and then contribute to the UEFI
Forumfor
inclusion in the specification) so we need to= follow some code
first
rules that I don=E2=80= =99t remember of the top of my head? So why not
start
out
the protocol definition OvmfPkg/Include/Protocol.= You can also
add
a
test applicat= ion looks like you can just use the root [2] of
OVMF
for
that. That way the project is not blocked.



We can have a conversat= ion on the mailing list about better
places
to<= br class=3D"">put stuff, and it should be easy enough to move stuff around = if
everything else is working.

<= br class=3D"">
[1] find OvmfPkg  -iname '*Virtio*.inf'
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.i= nf

OvmfPkg/VirtioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice= Lib.inf

OvmfPkg/Library/VirtioLib/VirtioLib.in= f

OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

OvmfPkg/Virtio10Dxe/Virtio10.inf

Ov= mfPkg/VirtioNetDxe/VirtioNet.inf

OvmfPkg/Virti= oRngDxe/VirtioRng.inf



[2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION --
*.inf
|
grep MODULE_TYPE

EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_= TYPE
=3D UEFI_APPLICATION



Thanks,



Andrew Fish





On 3/30/21, Ethin = Probst via groups.io <http://groups.= io/>
<http= ://groups.io/ <http://groups.io/>>
<http://groups.io/ <http://groups.io/> <http://groups.io/
<http://groups.io/>>>
<http://groups.io/ <http://groups.io/> <http://groups.io/
<http://groups.io/>> <http://groups.io/ <= /span><http://groups.io/>= ;
<http://groups.= io/ <http://groups.io/>>>>
<harlydavidsen=3Dgmail.com@groups.io
<mailto:harlydavidsen=3Dg= mail.com@groups.io>
<mailto:harlydavidsen=3Dgmail.com@groups= .io
<mailto:harlydavidsen=3Dgmail.com@groups.io>>
<mailto:gma= il.com@groups.io <= mailto:gmail.com@groups.i= o>
<mailto:gmail.com@groups.io&nbs= p;<mailto:gmail= .com@groups.io>>>
<mailto:harlydavidsen
<mailto:harlydavidsen>=3Dgmail.com@groups.io
<mailto:gmail.com@groups.io>
<mailto:gmail.c= om@groups.io <mailto:gmail.com@groups.io>>
<mailto:gmail.com@groups.io&nbs= p;<mailto:gmail= .com@groups.io>
<mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>>
wrote:
    I agree. Plus, it gives = me a chance to finally learn the
EDK2
build
    system and how it works! I've been worki= ng on a hobby OS
as
a
side
    project and, though learning from other cod= e examples from
OSes
is
 &nb= sp;  fun, I have to say that learning from the firmware code
like
from
    Sea= BIOS has been some of the most enlightening and
interestingtimes
    thus far.
    Thanks for the link to your code, Rafael; on= ce I get
virtIO
support
 &nb= sp;  in, I can work on HDA support, though I might tackle USB
support
    second and HDA thi= rd. We'll see, but VirtIO definitely is
coming
=     first.

  &nb= sp; As I said before, I look forward to working with all of
you
    wonderful
&n= bsp;   people!

  &nbs= p; On 3/30/21, Rafael Rodrigues Machado
  &nbs= p; <rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machad= o@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>
&= lt;mailto:r= afaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@= gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>>
&n= bsp;   <mailto:rafaelrodrigues.machado@gmail.com
&= lt;mailto:r= afaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.mach= ado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>&g= t;
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafael= rodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@g= mail.com
<mailto:rafaelrodrigues.machado@gmail.com>>>= ;>>
    wrote:

        This would be amaz= ing so people can continue my work
related
to        accessibility = at BIOS. Something desired by the blind
people
=         since the
&nb= sp;       90's
  = ;      Just for reference, this is what I hav= e done:


https://g= ithub.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
= <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Acces= sibility>
<https://github.com/RafaelR= Machado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>&= gt;
<https://github.com/RafaelRMachado/Msc_U= efiHda_PreOs_Accessibility
<https://gith= ub.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Acce= ssibility
<https://github.com/RafaelRMac= hado/Msc_UefiHda_PreOs_Accessibility>>>

        Thanks
        Rafael

        Em seg, 29 de mar= de 2021 20:24, Ethin Probst
     &n= bsp;  <h= arlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydav= idsen@gmail.com
<mailto:harlydavidsen@gmail.com>>
&= lt;mailto:harlydavids= en@gmail.com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmai= l.com
<mailto:harlydavidsen@gmail.com>>>>
&nb= sp;       escreveu:


        &nb= sp;   Hello everyone,

 &nb= sp;          This is the = first time I've ever contributed to
EDK2.
As          &nb= sp; part of GSoC
      &nb= sp;     2021, I have submitted a proposal to imple= ment a
UEFI
      = ;      audio output
  = ;          protocol that = will utilize the VirtIO sound
driver.
I've
           = ; already
       &nbs= p;    submitted a draft proposal, and apologize if I've=
done
       = ;     things out of
  &nbs= p;         order. This is my f= irst time doing GSoC 2021, and
     =        contributing to EDK2
            f= elt like a really fun thing to do!

  = ;          I look forward= to working with you guys on this
and
any
           =  future projects!
      &n= bsp;     :-)

 &n= bsp;          --
           &n= bsp;Signed,
        &= nbsp;   Ethin D. Probst









    --
    Signed,
   &nbs= p;Ethin D. Probst







--
Signed,
Ethin D. Probst

<= br class=3D"">



<= /blockquote>



--
Signed,
Ethin D. Probst










--
Signed,
Eth= in D. Probst







--
Signed,
Ethin D. Probst








--
Signed,
Ethin D. Probst




--
Signed,
Ethin D. Probst

<= br class=3D"">




--&n= bsp;
Signed,
Ethin D. Probst

--Apple-Mail=_E4C8A50D-012C-4481-A599-3FF781D9C523--