> 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’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 > > 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 > >> 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 >>> >>> 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 and any future projects! >>>> :-) >>>> >>>> -- >>>> Signed, >>>> Ethin D. Probst >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> -- >> Signed, >> Ethin D. Probst >> >> >> >> >> >> > > > -- > Signed, > Ethin D. Probst > > >