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 <af...@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 <harlydavid...@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....@groups.io >> <mailto:harlydavidsen=gmail....@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 <af...@apple.com <mailto:af...@apple.com>> >>> wrote: >>>> >>>> >>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavid...@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 <af...@apple.com <mailto:af...@apple.com> >>>>> <mailto:af...@apple.com <mailto:af...@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 <l...@nuviainc.com >>>>>>> <mailto:l...@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 <harlydavid...@gmail.com >>>>>>> <mailto:harlydavid...@gmail.com> >>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@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 <ler...@redhat.com <mailto:ler...@redhat.com> >>>>>>> <mailto:ler...@redhat.com <mailto:ler...@redhat.com>> >>>>>>> <mailto:ler...@redhat.com <mailto:ler...@redhat.com> >>>>>>> <mailto:ler...@redhat.com <mailto:ler...@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....@groups.io <mailto:afish=apple....@groups.io> >>>>>>>>> <mailto:afish=apple....@groups.io >>>>>>>>> <mailto:afish=apple....@groups.io>> >>>>>>>>> <mailto:apple....@groups.io <mailto:apple....@groups.io> >>>>>>>>> <mailto:apple....@groups.io <mailto:apple....@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>>>>, >>>>>>>>> "af...@apple.com <mailto:af...@apple.com> <mailto:af...@apple.com >>>>>>>>> <mailto:af...@apple.com>> <mailto:af...@apple.com >>>>>>>>> <mailto:af...@apple.com> >>>>>>>>> <mailto:af...@apple.com <mailto:af...@apple.com>>>" >>>>>>>>> <af...@apple.com <mailto:af...@apple.com> <mailto:af...@apple.com >>>>>>>>> <mailto:af...@apple.com>> >>>>>>>>> <mailto:af...@apple.com <mailto:af...@apple.com> >>>>>>>>> <mailto:af...@apple.com <mailto:af...@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>>>>, >>>>>>>>> "harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com>> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com >>>>>>>>> <mailto:harlydavid...@gmail.com>>>" >>>>>>>>> <harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com>> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com >>>>>>>>> <mailto:harlydavid...@gmail.com>>>> >>>>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com>> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com>>>> >>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst >>>>>>>>> <harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com>> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com>>> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com>> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com >>>>>>>>> <mailto:harlydavid...@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....@groups.io >>>>>>>>> <mailto:harlydavidsen=gmail....@groups.io> >>>>>>>>> <mailto:harlydavidsen=gmail....@groups.io >>>>>>>>> <mailto:harlydavidsen=gmail....@groups.io>> >>>>>>>>> <mailto:gmail....@groups.io <mailto:gmail....@groups.io> >>>>>>>>> <mailto:gmail....@groups.io <mailto:gmail....@groups.io>>> >>>>>>>>> <mailto:harlydavidsen <mailto:harlydavidsen>=gmail....@groups.io >>>>>>>>> <mailto:gmail....@groups.io> >>>>>>>>> <mailto:gmail....@groups.io <mailto:gmail....@groups.io>> >>>>>>>>> <mailto:gmail....@groups.io <mailto:gmail....@groups.io> >>>>>>>>> <mailto:gmail....@groups.io <mailto:gmail....@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.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com>> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com>>> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com>> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com> >>>>>>>>> <mailto:rafaelrodrigues.mach...@gmail.com >>>>>>>>> <mailto:rafaelrodrigues.mach...@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 >>>>>>>>> <harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com>> >>>>>>>>> <mailto:harlydavid...@gmail.com <mailto:harlydavid...@gmail.com> >>>>>>>>> <mailto:harlydavid...@gmail.com >>>>>>>>> <mailto:harlydavid...@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 (#74103): https://edk2.groups.io/g/devel/message/74103 Mute This Topic: https://groups.io/mt/81710286/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
