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 B35EE1A1DF3 for ; Mon, 5 Sep 2016 06:17:36 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 1CBCE81239; Mon, 5 Sep 2016 13:17:36 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-76.phx2.redhat.com [10.3.116.76]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u85DHXEN016963; Mon, 5 Sep 2016 09:17:34 -0400 To: Alexander Graf , edk2-devel-01 References: <20160819124932.29711-1-lersek@redhat.com> <57CD6463.90903@suse.de> <57CD6C25.7000406@suse.de> Cc: Jordan Justen , Ard Biesheuvel , Shannon Zhao , Christoffer Dall , Leif Lindholm From: Laszlo Ersek Message-ID: <51d27b02-85dc-44cf-db27-a97727224486@redhat.com> Date: Mon, 5 Sep 2016 15:17:33 +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: <57CD6C25.7000406@suse.de> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 05 Sep 2016 13:17:36 +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 13:17:36 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/05/16 14:59, Alexander Graf wrote: > On 09/05/2016 02:56 PM, Laszlo Ersek wrote: >> 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. > > Yes, that's what it does :). > >> (*) 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. > > Exactly. grub2 only uses blt operations. The thing I wasn't sure about > was whether PixelBltOnly is defined as "Please blt me in BGRx888 > format". If that's what it's defined as, we can simply add it to the > existing BGR888 handing case in grub2 and get fancy graphical output for > free. I think that's the case. Please see the discussion in "11.9.1 Blt Buffer" in the UEFI 2.6 spec, and also typedef struct { UINT8 Blue; UINT8 Green; UINT8 Red; UINT8 Reserved; } EFI_GRAPHICS_OUTPUT_BLT_PIXEL; under the EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() description (= same section of the spec). The spec can be downloaded from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf (If the direct link doesn't work, the landing page (?) is .) Thanks Laszlo