From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B6D0E1A1E2D for ; Mon, 5 Sep 2016 05:56:42 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D580D4E4D0; Mon, 5 Sep 2016 12:56:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-76.phx2.redhat.com [10.3.116.76]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u85CudFT023266; Mon, 5 Sep 2016 08:56:40 -0400 To: Alexander Graf , edk2-devel-01 References: <20160819124932.29711-1-lersek@redhat.com> <57CD6463.90903@suse.de> Cc: Jordan Justen , Ard Biesheuvel , Shannon Zhao , Christoffer Dall , Leif Lindholm From: Laszlo Ersek Message-ID: Date: Mon, 5 Sep 2016 14:56:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57CD6463.90903@suse.de> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 05 Sep 2016 12:56:41 +0000 (UTC) Subject: Re: [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 12:56:42 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/05/16 14:26, Alexander Graf wrote: > On 09/02/2016 12:02 AM, Laszlo Ersek wrote: >> On 08/19/16 14:49, Laszlo Ersek wrote: >> >>> - Also tested loading and launching Linux from GRUB. Here the results >>> differ of course: x86_64 Fedora 24 drives virtio-gpu-pci with its >>> native driver without problems, whereas AARCH64 Fedora 23 doesn't >>> even >>> look for virtio-gpu-pci, apparently. >> Update: >> >> Once booted from GRUB -- on top of OVMF / ArmVirtQemu respectively --, >> both x86_64 and aarch64 Fedora *24* guests work well with >> virtio-gpu-pci, as far as the character console (tty1, "virtiodrmfb") is >> concerned. > > Hooray :). > > Unfortunately grub2 has no idea what PixelBltOnly is, it only knows the > traditional ones. For me grub2 seems to work without any issues -- it only uses the Simple Text Out protocol for displaying text (not graphics). The text gets turned into graphics by edk2's GraphicsConsoleDxe, and that one knows how to handle PixelBltOnly. > So to make it work with graphics, I had to explicitly > set it to the correct mode - see the patch below. That is not the correct mode at all; PixelBlueGreenRedReserved8BitPerColor means that the framebuffer is accessible directly, and the pixels are represented in the framebuffer as BGRX8 UINT32 elements. Whereas, virtio-gpu-pci has no framebuffer at all. PixelBltOnly means that the client can only display graphics on the device by explicitly calling the EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() method. > > Is PixelBltOnly properly defined? Yes, it is. > If so, someone should probably write > up a patch for grub2 to teach it about it ;). Actually, I'm surprised the patch you pasted below works at all. If it does (i.e., you get pictures displayed by grub2) after applying the patch, that means grub2 already uses Blt() only, and no direct framebuffer access -- which is great (*). In that case, it should only be modified not to croak on PixelBltOnly. (*) Hmmm, from a 5-second grep, I found "grub-core/video/efi_gop.c", and it does call Blt() in the grub_video_gop_swap_buffers() function. I have no idea what the "grub_video_adapter.swap_buffers" member function is for -- double buffering perhaps? If grub2 draws only into its own memory buffers, and then sends them to the display with Blt(), that should be okay. As long as the array format matches the Blt() specification, that is. Thanks Laszlo > > > Alex > > diff --git a/OvmfPkg/VirtioGpuDxe/Gop.c b/OvmfPkg/VirtioGpuDxe/Gop.c > index c6ff9ed..57bfd32 100644 > --- a/OvmfPkg/VirtioGpuDxe/Gop.c > +++ b/OvmfPkg/VirtioGpuDxe/Gop.c > @@ -215,7 +215,7 @@ GopQueryMode ( > > GopModeInfo->HorizontalResolution = mGopResolutions[ModeNumber].Width; > GopModeInfo->VerticalResolution = mGopResolutions[ModeNumber].Height; > - GopModeInfo->PixelFormat = PixelBltOnly; > + GopModeInfo->PixelFormat = > PixelBlueGreenRedReserved8BitPerColor; > GopModeInfo->PixelsPerScanLine = mGopResolutions[ModeNumber].Width; > > *SizeOfInfo = sizeof *GopModeInfo; > @@ -263,7 +263,7 @@ GopSetMode ( > VgpuGop->GopMode.Info = &VgpuGop->GopModeInfo; > VgpuGop->GopMode.SizeOfInfo = sizeof VgpuGop->GopModeInfo; > > - VgpuGop->GopModeInfo.PixelFormat = PixelBltOnly; > + VgpuGop->GopModeInfo.PixelFormat = > PixelBlueGreenRedReserved8BitPerColor; > > // > // This is the first time we create a host side resource. >