On 19 May 2016 at 13:04, Laszlo Ersek <ler...@redhat.com> wrote: > On 05/19/16 12:22, Ard Biesheuvel wrote: >> On 19 May 2016 at 12:04, Laszlo Ersek <ler...@redhat.com> wrote: > >>> On the other hand... the virtio-gpu device would require a GOP that is >>> Blt()-only. That is, no direct framebuffer access. I very much hope this >>> is not a problem for the edk2 code. I don't know if bootloaders like >>> grub2 will be able to deal with it. (But, at least grub2 can be patched. >>> Not sure about Windows-on-aarch64.) For runtime OSes (on aarch64), we >>> expect that they ship a native virtio-gpu driver by default. >>> >> >> I suppose this blt-only issue goes away as well once we fix the KVM >> host cached mappings issue? > > No; as far as I recall the info I got from Gerd (I haven't wanted to > look at the spec in detail yet), lack of a direct-access framebuffer is > a design principle for virtio-gpu. It's all about transfering 2D (and > later 3D) operations. >
OK, fair enough > If the KVM host cached mappings issue is fixed, we can simply use QXL / > stdvga (with the framebuffer). > I see the use of GOP under the OS and efifb merely as stopgap solutions, so I won't complain if we get something better in return. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
