From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by mx.groups.io with SMTP id smtpd.web11.449.1617722257218918052 for ; Tue, 06 Apr 2021 08:17:37 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=e0/C4qKn; spf=pass (domain: gmail.com, ip: 209.85.208.47, mailfrom: harlydavidsen@gmail.com) Received: by mail-ed1-f47.google.com with SMTP id ba6so9516635edb.1 for ; Tue, 06 Apr 2021 08:17:37 -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=V5mKtLtFpx56sePWIsPfmwMfi8fjyJOUQgqRItIfyx4=; b=e0/C4qKnHbE2RtkG6D1w34ekpZM55kjFBCsIcKla6aMbcMfigQFFe9vPKWbz+8ceLe vB8D0G/06jrujdcZ/CTPU/MCP3IexsTS/1sSaArSBU6A0EsuTc3ceF+lzvPd+9jn0vSk NJjPLkHrudkmNAuMA/65urU2XDlf+By/rQoPOoEIjnWqomt7BcSnr4ZLkEt0MjxtBkkV S2Hlty7ndkBGOdPzG8LYspNh1XSsPM1hFUaUng4bmLOCeAEVAs0BtLK5HGztbR5N96/9 ZADooTZ5YEkbl6xr2yGqvWc5ZQ7MDkQoRX7cNckpoqM3AdcoJue8sRPCQ8cGO4dh0+T/ htRw== 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=V5mKtLtFpx56sePWIsPfmwMfi8fjyJOUQgqRItIfyx4=; b=MWhLTz4D8JWEpKLBWE3mGfE4Ol6GnppOKgu8oXmlKtEdAaIQrEOKsJp+fjNA8Yzppb pM01xZVUj4PTFcvfdHqX2x+fS4jV6MnnDXTr95ou8YiooDmDOJ8TmsS6ncUPt8l3WD72 YDbpZx79YOCr/GKcxxBfCbpa5e4xwUMeAAY+FtSbV+yWidDipkeqdKBbz64i3sd8mOYs ktqtu8xmRjDt9//KdBoreHKiDF0CMgTDnFbiekrH8OWJCJXOUetHnlBNW3LQoPfo0Gk1 Tt+CKAgR3lFCcaF6FXkMicyOiMwRYy6MZl3ebmCuvdYs6xMsSPPahP2rVmUq0EWfsiDg V9dA== X-Gm-Message-State: AOAM533vrQlJ97ZSH4qz/3HsPL2uF0evaZand6UMzprhzmXdKDe1z77w LM0cdRAf0In91nqHuhVXPUynVVDa5B+Iv5SsLaY= X-Google-Smtp-Source: ABdhPJzUhqS52kFOVn/iK9VcoZzk0JNT2+iQCclh3P22e+/++ZnpbyuH4Jg5LUU/BL/b8vj6qw0+xPYkry4aMagWYEw= X-Received: by 2002:a05:6402:3511:: with SMTP id b17mr18177526edd.98.1617722255691; Tue, 06 Apr 2021 08:17:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:458d:0:0:0:0:0 with HTTP; Tue, 6 Apr 2021 08:17:35 -0700 (PDT) In-Reply-To: <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> From: "Ethin Probst" Date: Tue, 6 Apr 2021 10:17:35 -0500 Message-ID: Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: Laszlo Ersek Cc: devel@edk2.groups.io, nathaniel.l.desimone@intel.com, "afish@apple.com" , Rafael Rodrigues Machado , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 well 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 lik= e >> to publish the protocol in the UEFI Spec (I can help with that part) an= d >> that would mean we put the Protocol definition in >> MdePkg/Include/Protocol, but we don=E2=80=99t want to do that before 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 the 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 why not s= tart 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]=C2=A0find OvmfPkg=C2=A0 -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]=C2=A0/Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.in= f | >> grep MODULE_TYPE >> >> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:=C2=A0 MODULE_TYPE >> =C2=A0 =C2=A0 =3D UEFI_APPLICATION >> >> >> >> Thanks, >> >> >> >> Andrew Fish >> >> >> >> >> >> >> On 3/30/21, Ethin Probst via=C2=A0groups.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 fr= om >> 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 suppor= t >> second and HDA third. We'll see, but VirtIO definitely is comin= g >> 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 relate= d >> to >> accessibility at BIOS. Something desired by the blind peopl= e >> 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. A= s >> part of GSoC >> 2021, I have submitted a proposal to implement a UEFI >> audio output >> protocol that will utilize the VirtIO sound driver. I'v= e >> 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 >> >> >> >> >> >>=20 > > --=20 Signed, Ethin D. Probst