[...] >> >> (1) When we added VirtioGpuDxe to the ArmVirtPkg platforms, the only >> reason I didn't propose removing QemuVideoDxe from the same platforms >> was that QemuVideoDxe was usable on QEMU/TCG, and I figured it wouldn't >> hurt to keep it. >> >> Other than that, I see zero point in using this driver on ARM. (And, >> apparently, it does hurt to keep it.) >> >> Can we please consider simply removing this driver from the ArmVirtPkg >> platforms? (And then some now-conditional compilation could be >> simplified in the driver too!) >> > > It is actually quite useful in TCG mode, and the fact that QEMU > currently allows unaligned accesses to device memory is not something > we should be relying upon. >
Actually, I managed to confuse myself here. The only thing lacking when running with virtio-gpu rather than VGA is efifb support, due to the fact that the framebuffer is no longer directly addressable. efifb is a useful hack on bare metal systems that lack a real framebuffer driver, but it is hardly something to care deeply about on VMs. So I am going to change my mind, and agree with Laszlo: let's remove QemuVideoDxe from ArmVirtQemu; the longer we wait, the more difficult it becomes, and only TCG users that rely on a GOP protocol being exposed with direct framebuffer access are going to be affected in the first place (if any such use cases exist) Laszlo: any ideas or suggestions you may want to share before I start working on this? -- Ard. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
