From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by mx.groups.io with SMTP id smtpd.web10.19823.1618433255501219706 for ; Wed, 14 Apr 2021 13:47:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tALtVlDU; spf=pass (domain: gmail.com, ip: 209.85.208.44, mailfrom: harlydavidsen@gmail.com) Received: by mail-ed1-f44.google.com with SMTP id ba6so25329739edb.1 for ; Wed, 14 Apr 2021 13:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UtnvkX2pTDjBvjRs2oenfMtFBh4s/N+tC+Zm8et8zTY=; b=tALtVlDUomRl38Fb5mT+l7o0LFaBD53ZTV470d4hwv40hCHdE+bMUG3ECl92bpIZLC Cu5fFupa379/KIGa88oQtYIGCGwIfrosB/TMs4pxpH5UWePmcqqEiTFAGFivRDqxrXSD 8P5JHNqv8lreBEDraHKfkbK+V9B710NwLhVhAFSD0bXuwE5/6/s9LfsTKJiKe/idBxyj 9Vqg3SZUwbFLe1b/RZ9ErSViZHzAvWaHGNjhqOuamgkYcXDSYAj0MF0H8d/Gh8oHBX1+ 5nbvNPQaZ9jVzG4koDqQD4nR6XEYuSgVS+IYo/gJuczi9oPtNYZ2JPGHNb2SM7w0DjnZ YQKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UtnvkX2pTDjBvjRs2oenfMtFBh4s/N+tC+Zm8et8zTY=; b=DBC0dKtUW9wO5Xl+dh3jAgjoCOXnc5NEEo6DiakBgatCVoSvV9w5/jkC8rKm01RbXG t924ouF5n0paMMZKkuCGdoR+V4H1ucwuCV+HSyVXcHI/+bCrRrx67WCrR2kxFIaKReQe erjQOJfmaWg10mVwFg2ffyL2II1FNry/YTs0LGC29R/h55s7nRwYu3AeHJAsS+EAQekE hNnaN//pm3mV6yibnEOir+JbGEKeK4FQPkZb9H+UMziEBFd8lSX4U+kMXQ24TkEl7jio GrkkrXw0JgrpiUqpq3KIRKkUUE3VyIxduL2K/HLjGzxmwIBE15HBXNU7BOr0MgXzEWDN rAkg== X-Gm-Message-State: AOAM531hlVAG79NQ+cb7pYKfI2uD9Slz+Rx7DKex+zJBz2sfzCrZUIMy 8WzBB1iw7vn+krA/YOBEdcc9wXTecIWKoleAjwg= X-Google-Smtp-Source: ABdhPJwb5kGCO7U7X+BbH+rdcukiSc9v/Myzt9xor7O3HIHWqoBSlLC6CTppqckwvxXw4NNN/iGwKdxGB+hevRS39JM= X-Received: by 2002:a05:6402:3511:: with SMTP id b17mr129822edd.98.1618433253766; Wed, 14 Apr 2021 13:47:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab4:9a0a:0:0:0:0:0 with HTTP; Wed, 14 Apr 2021 13:47:33 -0700 (PDT) In-Reply-To: References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> From: "Ethin Probst" Date: Wed, 14 Apr 2021 15:47:33 -0500 Message-ID: Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: Andrew Fish Cc: edk2-devel-groups-io , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 perspectiv= es. > It is easy enough to think about the producer part of it as you are thin= king > 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 EF= I > 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 fam= ous > Mac startup sound). We are also would like to have the option of enablin= g > 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=E2=80=99t consider the size of software, but this is not = true for > firmware. Firmware generally lives in NOR FLASH that is considered expen= sive > (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 ca= n 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 ha= s 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 ta= sk > at hand. I=E2=80=99m not too caught up on the names but in general I thi= nk 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 this AP= I. For > example you don=E2=80=99t 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. > =09b) async in EFI usually means you return a pointer to an EFI_EVENT th= at > gets signaled on completion. > 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be stop= ped. > 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=E2=80=99t 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 th= e > user may want 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 API on top and likely a PCI I/O on th= e > 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 t= o > think about this is a disk. A lot of disk adapters just produce a raw Bl= ock > 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 jus= t > produces the generic AUDIO API, while an HDA audio driver also has to > abstract some of the complexity of its hardware implementation and stand= ard. > > > 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 i= t in > terms of the minute you have to implement to make it function. Think wha= t > 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 m= ix > 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=E2=80=99t go off an implement a lot of code jus= t 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 m= ost > sense for the job at hand. > > Thanks, > > Andrew Fish > >> On Apr 13, 2021, at 6:20 PM, Ethin Probst >> 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 >> > > 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 > >>> wrote: >>>> >>>> >>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst >>>>> wrote: >>>>> >>>>> Would it be possible for us to conduct discussion on the UEFI talkbo= x? >>>>> I don't mind using email, but things could definitely get moving >>>>> quicker over there (though its not a requirement obviously). >>>>> >>>> >>>> Sure, don=E2=80=99t think I=E2=80=99ve really used that but as long a= s 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 Protoco= ls >>>> to >>>> do work, and the Stop() undoes the Start(). >>>> >>>> Mike Kinney started this back in the day and it describes how to writ= e >>>> UEFI >>>> drivers: >>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Wri= ter%27s-Guide >>>> >>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Proto= col/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 availab= le >>>>> 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 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 >>>>> >> >>>>> wrote: >>>>>> Leif, >>>>>> >>>>>> Since I have put some brain cells around this area in the past I ca= n >>>>>> be >>>>>> the >>>>>> backup and help out too. >>>>>> >>>>>> I=E2=80=99d also point out if you are having issues building or hav= e 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 looking >>>>>> for >>>>>> answer to their questions so one person asking can help out a lot o= f >>>>>> other >>>>>> people. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Andrew Fish >>>>>> >>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm >>>>>> > 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 >>>>>> >>>>>>> >>>>>>> >>= > >>>>>>> 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 majorit= y >>>>>>> (if not all) of UEFI protocols are. >>>>>>> >>>>>>> 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 first= =E2=80=9D 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 we= ll >>>>>>>> as >>>>>>>> the developers of the virtio-sound device model in QEMU. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Laszlo >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Nate >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From: * >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>> on >>>>>>>>> behalf >>>>>>>>> of "Andrew Fish via groups.io >>>>>>>>> > >>>>>>>> >>>>>>>>> >>" >>>>>>>>> >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> *Reply-To: *"devel@edk2.groups.io >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>" >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>, >>>>>>>>> "afish@apple.com >>>>>>>> > >>>>>>>> >>>>>>>>> >>" >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM >>>>>>>>> *To: *edk2-devel-groups-io >>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>, >>>>>>>>> "harlydavidsen@gmail.com >>>>>>>>> = > >>>>>>>>> >>>>>>>>> >>>>>>>> >>" >>>>>>>>> >>>>>>>>> = > >>>>>>>>> >>>>>>>>> >>>>>>>> >>> >>>>>>>>> *Cc: *Rafael Rodrigues Machado >>>>>>>> >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>> >>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst >>>>>>>>> >>>>>>>>> = > >>>>>>>>> >>>>>>>>> = >> >>>>>>>>> >>>>>>>>> = > >>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >>>>>>>>> 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=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 UEFI Spec (I can help with that >>>>>>>>> part) >>>>>>>>> and >>>>>>>>> that would mean we put the Protocol definition in >>>>>>>>> MdePkg/Include/Protocol, but we don=E2=80=99t want to do that be= fore 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 to th= e UEFI >>>>>>>>> Forum >>>>>>>>> for >>>>>>>>> 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 wh= y not >>>>>>>>> start >>>>>>>>> out >>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also a= dd >>>>>>>>> a >>>>>>>>> test application looks like you can just use the root [2] of OVM= F >>>>>>>>> for >>>>>>>>> that. That way the project is not blocked. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> We can have a conversation on the mailing list about better plac= es >>>>>>>>> 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 >>>>>>>>> =3D UEFI_APPLICATION >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Andrew Fish >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/30/21, Ethin Probst via groups.io >>>>>>>>> > >>>>>>>>> >>>>>>>> >> >>>>>>>>> >>>>>>>> > >>>>>>>>> >>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>>> >> >>>>>>>>> =3Dgmail.com@group= s.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 a= s >>>>>>>>> a >>>>>>>>> side >>>>>>>>> project and, though learning from other code examples from >>>>>>>>> OSes >>>>>>>>> is >>>>>>>>> fun, I have to say that learning from the firmware code li= ke >>>>>>>>> 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 virtI= O >>>>>>>>> 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 yo= u >>>>>>>>> wonderful >>>>>>>>> people! >>>>>>>>> >>>>>>>>> On 3/30/21, Rafael Rodrigues Machado >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>> >>>>>>>>> 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_Accessibilit= y >>>>>>>>> >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Rafael >>>>>>>>> >>>>>>>>> Em seg, 29 de mar de 2021 20:24, Ethin Probst >>>>>>>>> >>>>>>>>> = > >>>>>>>>> >>>>>>>>> >>>>>>>> >>> >>>>>>>>> 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 an= d >>>>>>>>> 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 >>> >>> >>>=20 >>> >>> >>> >> >> >> -- >> Signed, >> Ethin D. Probst > > --=20 Signed, Ethin D. Probst