[edk2-devel] VirtIO Sound Driver (GSoC 2021)

Michael D Kinney michael.d.kinney at intel.com
Wed Apr 14 22:30:55 UTC 2021 

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 periodically check the completion status.  

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 for event completion.

These concepts are discussed in the UEFI Driver Writer's Guide.

https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf

Specifically for audio.  If there is an audio playback buffer that will take some time to send,
the Audio Protocol 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.  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 while audio is playing or
if it is ok for the consumer to wait until the audio playback is completed.

Mike

> -----Original Message-----
> From: devel at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Ethin Probst
> Sent: Wednesday, April 14, 2021 1:48 PM
> To: Andrew Fish <afish at apple.com>
> Cc: edk2-devel-groups-io <devel at edk2.groups.io>; Leif Lindholm <leif at nuviainc.com>; Laszlo Ersek <lersek at redhat.com>;
> Desimone, Nathaniel L <nathaniel.l.desimone at intel.com>; Rafael Rodrigues Machado <rafaelrodrigues.machado at gmail.com>; Gerd
> Hoffmann <kraxel at redhat.com>
> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
> 
> These are some pretty good suggestions; however, while reading through
> 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 memory
> 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.
> 
> On 4/13/21, Andrew Fish <afish at 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 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.
> >
> > The consumer of the sound Protocol is going to most likely be generic 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 visually
> > impaired. These days a lot of software engineers think of disk space as free
> > and really don’t 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 that 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 still has to
> > share the EFI System Partition on the disk with potentially other OS
> > loaders.
> >
> > So the consumer wants a protocol that is unleveled and focused on the task
> > at hand. I’m 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
> > 	a) We probably want a synchronous and asynchronous version of this API. For
> > example you don’t want to slow down the boot to wait for a boot beep to
> > complete, and you may chose to implement an API that waits for the sound to
> > complete (and do some GUI work in parallel) vs. blocking on the sound.
> > 	b) async in EFI usually 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
> > 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’t require canned sound
> > 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 variable for the default
> > state of some of the tunable, especially mute and volume. For example the
> > user may want to turn off all volume on the system so it would be nice if
> > 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 API 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 example we
> > would probably end up with an HDA_CODEC protocol. I think the best way to
> > think about this is 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 you might have an
> > extra driver in place to make the common bits common code. I think some 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 to
> > abstract some of the complexity of its hardware implementation and standard.
> >
> >
> > 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 could 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.
> >
> > 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.
> >
> > Oh and make sure you don’t go off an implement a lot of code just because we
> > chose the wrong complexity or abstraction point. This is the 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 at 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 it 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 and
> >> 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 will
> >> 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 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-complicating
> >> this setup? How can it be improved upon?
> >>
> >> On 4/13/21, Ethin Probst via groups.io <http://groups.io/>
> >> <harlydavidsen=gmail.com at groups.io
> >> <mailto:harlydavidsen=gmail.com at groups.io>> wrote:
> >>> Hi Andrew,
> >>>
> >>> 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, at
> >>> 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 with
> >>> Windows as a host.
> >>>
> >>> On 4/13/21, Andrew Fish <afish at apple.com <mailto:afish at apple.com>>
> >>> wrote:
> >>>>
> >>>>
> >>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> 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).
> >>>>>
> >>>>
> >>>> Sure, don’t think I’ve really used that but as long as I get pointed
> >>>> int
> >>>> he
> >>>> right 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_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().
> >>>>
> >>>> 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
> >>>>
> >>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Andrew Fish
> >>>>
> >>>>> 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: 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 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
> >>>>> 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 sequence
> >>>>> 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
> >>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
> >>>>> <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 audio
> >>>>> 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?
> >>>>>
> >>>>> On 4/13/21, Andrew Fish <afish at apple.com <mailto:afish at apple.com>
> >>>>> <mailto:afish at apple.com <mailto:afish at apple.com>>>
> >>>>> 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’d 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’ve
> >>>>>> got
> >>>>>> a
> >>>>>> lot of feedback that folks read or search the mailing list looking
> >>>>>> for
> >>>>>> answer to their questions so one person asking can help out a lot of
> >>>>>> other
> >>>>>> people.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Andrew Fish
> >>>>>>
> >>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif at nuviainc.com
> >>>>>>> <mailto:leif at nuviainc.com>> wrote:
> >>>>>>>
> >>>>>>> Hi all, especially Ethin.
> >>>>>>>
> >>>>>>> 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 task,
> >>>>>>> feel
> >>>>>>> free to spam me with any remaining/new questions.
> >>>>>>>
> >>>>>>> /
> >>>>>>>   Leif
> >>>>>>>
> >>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen at gmail.com
> >>>>>>> <mailto:harlydavidsen at gmail.com>
> >>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> On 4/6/21, Laszlo Ersek <lersek at redhat.com <mailto:lersek at redhat.com>
> >>>>>>> <mailto:lersek at redhat.com <mailto:lersek at redhat.com>>
> >>>>>>> <mailto:lersek at redhat.com <mailto:lersek at redhat.com>
> >>>>>>> <mailto:lersek at redhat.com <mailto:lersek at redhat.com>>>>
> >>>>>>> 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 “code first” UEFI spec
> >>>>>>>>> contribution I did this with the PPI that added up getting added.
> >>>>>>>>
> >>>>>>>> The new audio protocol should be generic, only its implementation
> >>>>>>>> in
> >>>>>>>> question should be virtio specific.
> >>>>>>>>
> >>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as well
> >>>>>>>> as
> >>>>>>>> the developers of the virtio-sound device model in QEMU.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Laszlo
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Nate
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> *From: *<devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>>>> on
> >>>>>>>>> behalf
> >>>>>>>>> of "Andrew Fish via groups.io <http://groups.io/>
> >>>>>>>>> <http://groups.io/ <http://groups.io/>> <http://groups.io/
> >>>>>>>>> <http://groups.io/>
> >>>>>>>>> <http://groups.io/ <http://groups.io/>>>"
> >>>>>>>>> <afish=apple.com at groups.io <mailto:afish=apple.com at groups.io>
> >>>>>>>>> <mailto:afish=apple.com at groups.io
> >>>>>>>>> <mailto:afish=apple.com at groups.io>>
> >>>>>>>>> <mailto:apple.com at groups.io <mailto:apple.com at groups.io>
> >>>>>>>>> <mailto:apple.com at groups.io <mailto:apple.com at groups.io>>>>
> >>>>>>>>> *Reply-To: *"devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>>>"
> >>>>>>>>> <devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>>>>,
> >>>>>>>>> "afish at apple.com <mailto:afish at apple.com> <mailto:afish at apple.com
> >>>>>>>>> <mailto:afish at apple.com>> <mailto:afish at apple.com
> >>>>>>>>> <mailto:afish at apple.com>
> >>>>>>>>> <mailto:afish at apple.com <mailto:afish at apple.com>>>"
> >>>>>>>>> <afish at apple.com <mailto:afish at apple.com> <mailto:afish at apple.com
> >>>>>>>>> <mailto:afish at apple.com>>
> >>>>>>>>> <mailto:afish at apple.com <mailto:afish at apple.com>
> >>>>>>>>> <mailto:afish at apple.com <mailto:afish at apple.com>>>>
> >>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
> >>>>>>>>> *To: *edk2-devel-groups-io <devel at edk2.groups.io
> >>>>>>>>> <mailto:devel at edk2.groups.io>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> >>>>>>>>> <mailto:devel at edk2.groups.io <mailto:devel at edk2.groups.io>>>>,
> >>>>>>>>> "harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com
> >>>>>>>>> <mailto:harlydavidsen at gmail.com>>>"
> >>>>>>>>> <harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com
> >>>>>>>>> <mailto:harlydavidsen at gmail.com>>>>
> >>>>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>>>>
> >>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   On Mar 30, 2021, at 5:01 PM, Ethin Probst
> >>>>>>>>> <harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>>>
> >>>>>>>>>   <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com
> >>>>>>>>> <mailto:harlydavidsen at gmail.com>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   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 should
> >>>>>>>>>   actually put the protocol and all that stuff. Maybe there's
> >>>>>>>>>   documentation I've missed as well.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Ethin,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> For the driver I’d 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 UEFI Spec (I can help with that
> >>>>>>>>> part)
> >>>>>>>>> and
> >>>>>>>>> that would mean we put the Protocol definition in
> >>>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it is
> >>>>>>>>> standardized as that causes compatibility issues. So this is a
> >>>>>>>>> “code
> >>>>>>>>> first project” (code prototype and then contribute to the UEFI
> >>>>>>>>> Forum
> >>>>>>>>> for
> >>>>>>>>> inclusion in the specification) so we need to follow some code
> >>>>>>>>> first
> >>>>>>>>> rules that I don’t remember of the top of my head? So why not
> >>>>>>>>> start
> >>>>>>>>> out
> >>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add
> >>>>>>>>> a
> >>>>>>>>> test application looks like you can just use the root [2] of OVMF
> >>>>>>>>> for
> >>>>>>>>> that. That way the project is not blocked.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION --
> >>>>>>>>> *.inf
> >>>>>>>>> |
> >>>>>>>>> grep MODULE_TYPE
> >>>>>>>>>
> >>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
> >>>>>>>>>   = 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/ <http://groups.io/>
> >>>>>>>>> <http://groups.io/ <http://groups.io/>>>>
> >>>>>>>>>   <harlydavidsen=gmail.com at groups.io
> >>>>>>>>> <mailto:harlydavidsen=gmail.com at groups.io>
> >>>>>>>>> <mailto:harlydavidsen=gmail.com at groups.io
> >>>>>>>>> <mailto:harlydavidsen=gmail.com at groups.io>>
> >>>>>>>>> <mailto:gmail.com at groups.io <mailto:gmail.com at groups.io>
> >>>>>>>>> <mailto:gmail.com at groups.io <mailto:gmail.com at groups.io>>>
> >>>>>>>>>   <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com at groups.io
> >>>>>>>>> <mailto:gmail.com at groups.io>
> >>>>>>>>> <mailto:gmail.com at groups.io <mailto:gmail.com at groups.io>>
> >>>>>>>>> <mailto:gmail.com at groups.io <mailto:gmail.com at groups.io>
> >>>>>>>>> <mailto:gmail.com at groups.io <mailto:gmail.com at 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 working on a hobby OS as
> >>>>>>>>> a
> >>>>>>>>> side
> >>>>>>>>>       project and, though learning from other code examples from
> >>>>>>>>> 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 is
> >>>>>>>>> coming
> >>>>>>>>>       first.
> >>>>>>>>>
> >>>>>>>>>       As I said before, I look forward to working with all of you
> >>>>>>>>>       wonderful
> >>>>>>>>>       people!
> >>>>>>>>>
> >>>>>>>>>       On 3/30/21, Rafael Rodrigues Machado
> >>>>>>>>>       <rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>>>
> >>>>>>>>>       <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado at gmail.com>>>>>
> >>>>>>>>>       wrote:
> >>>>>>>>>
> >>>>>>>>>           This would be amazing so people can continue my work
> >>>>>>>>> related
> >>>>>>>>> to
> >>>>>>>>>           accessibility at BIOS. Something desired by the blind
> >>>>>>>>> people
> >>>>>>>>>           since the
> >>>>>>>>>           90's
> >>>>>>>>>           Just for reference, this is what I have done:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>
> >>>>>>>>>
> >>>>>>>>>           Thanks
> >>>>>>>>>           Rafael
> >>>>>>>>>
> >>>>>>>>>           Em seg, 29 de mar de 2021 20:24, Ethin Probst
> >>>>>>>>>           <harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com <mailto:harlydavidsen at gmail.com>
> >>>>>>>>> <mailto:harlydavidsen at gmail.com
> >>>>>>>>> <mailto:harlydavidsen at gmail.com>>>>
> >>>>>>>>>           escreveu:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>               Hello everyone,
> >>>>>>>>>
> >>>>>>>>>               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've
> >>>>>>>>> done
> >>>>>>>>>               things out of
> >>>>>>>>>               order. This is my first time doing GSoC 2021, and
> >>>>>>>>>               contributing to EDK2
> >>>>>>>>>               felt like a really fun thing to do!
> >>>>>>>>>
> >>>>>>>>>               I look forward to working with you guys on this and
> >>>>>>>>> any
> >>>>>>>>>               future projects!
> >>>>>>>>>               :-)
> >>>>>>>>>
> >>>>>>>>>               --
> >>>>>>>>>               Signed,
> >>>>>>>>>               Ethin D. Probst
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       --
> >>>>>>>>>       Signed,
> >>>>>>>>>       Ethin D. Probst
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   --
> >>>>>>>>>   Signed,
> >>>>>>>>>   Ethin D. Probst
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Signed,
> >>>>>>> Ethin D. Probst
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Signed,
> >>>>> Ethin D. Probst
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Signed,
> >>> Ethin D. Probst
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Signed,
> >> Ethin D. Probst
> >
> >
> 
> 
> --
> Signed,
> Ethin D. Probst
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74104): https://edk2.groups.io/g/devel/message/74104
Mute This Topic: https://groups.io/mt/81710286/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

More information about the edk2-devel-archive mailing list