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

["Ethin Probst" <harlydavidsen@gmail.com>]

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@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@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@groups.io
>> <mailto:harlydavidsen=gmail.com@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@apple.com <mailto:afish@apple.com>>
>>> wrote:
>>>>
>>>>
>>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@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@apple.com <mailto:afish@apple.com>
>>>>> <mailto:afish@apple.com <mailto:afish@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@nuviainc.com
>>>>>>> <mailto:leif@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@gmail.com
>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@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@redhat.com <mailto:lersek@redhat.com>
>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@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@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 "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@groups.io <mailto:afish=apple.com@groups.io>
>>>>>>>>> <mailto:afish=apple.com@groups.io
>>>>>>>>> <mailto:afish=apple.com@groups.io>>
>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>
>>>>>>>>> <mailto:apple.com@groups.io <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 <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>>>>,
>>>>>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
>>>>>>>>> <mailto:afish@apple.com>> <mailto:afish@apple.com
>>>>>>>>> <mailto:afish@apple.com>
>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>"
>>>>>>>>> <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
>>>>>>>>> <mailto:afish@apple.com>>
>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>>
>>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>>>>> *To: *edk2-devel-groups-io <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>>>>,
>>>>>>>>> "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>>>"
>>>>>>>>> <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>>>>
>>>>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.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 Probst
>>>>>>>>> <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>>>
>>>>>>>>>   <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>>>>>
>>>>>>>>> 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@groups.io
>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>>
>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>
>>>>>>>>>   <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
>>>>>>>>> <mailto:gmail.com@groups.io>
>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>> <mailto:gmail.com@groups.io <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 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@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>       <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@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@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>>>>
>>>>>>>>>           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