From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web11.12662.1617718590568969345 for ; Tue, 06 Apr 2021 07:16:30 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QT5cBtKm; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617718589; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MjOX0mX95Gq+gsd/Ej9q5S6F84tv2H8litfVRYuarR4=; b=QT5cBtKmLT2r7lAKFrOlSwCp7JkesFd/smxmpYlXuFcD4nMbHIz5c1WS1Bi2dtn86tMK6R FE2pTwZyvTOSh+vEobkcJa3K9byFHKOFBmTl9WjfKWuurO5OVEFnLkZ4PahtEz+Bo4aTX5 Tpa9PX+ihpkKy5AsqEliD/QzC9rk/XI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-221-exAiA5CjNsyRbdMqZ2oBPw-1; Tue, 06 Apr 2021 10:16:25 -0400 X-MC-Unique: exAiA5CjNsyRbdMqZ2oBPw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5B1B55B37B; Tue, 6 Apr 2021 14:16:24 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-134.ams2.redhat.com [10.36.115.134]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7373050A98; Tue, 6 Apr 2021 14:16:17 +0000 (UTC) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: devel@edk2.groups.io, nathaniel.l.desimone@intel.com, "afish@apple.com" , "harlydavidsen@gmail.com" Cc: Rafael Rodrigues Machado , Ethin Probst , Gerd Hoffmann References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> From: "Laszlo Ersek" Message-ID: <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> Date: Tue, 6 Apr 2021 16:16:16 +0200 MIME-Version: 1.0 In-Reply-To: <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: * 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’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 > > > >   > >