Hi, > > Maybe we should for now just scratch the idea of an virtio-ramfb device. > > Linux doesn't need it, and windows wouldn't use the virtio part of it so > > a standalone ramfb device would work equally well. > > If that works for you, it works for me best!
Ok, pushed updated branches. qemu (including seabios + ovmf blobs): https://git.kraxel.org/cgit/qemu/log/?h=sirius/ramfb edk2: https://github.com/kraxel/edk2/commits/ramfb seabios: https://git.kraxel.org/cgit/seabios/log/?h=bochs What is in there? qemu: -device ramfb standalone ramfb device -device virtio-ramfb kept for now for testing, as discussed above no plans to merge this one for now. -device vfio-pci-ramfb boot display for vgpu devices. bochs-display got a vgabios. seabios: support for bochs-display + rmafb added. For both of them vga text mode (at vgabios call level) is emulated by seabios inside the guest. edk2: QemuRamfbDxe driver, x86 wireup, incomplete arm wireup. Notes on QemuRamfbDxe: QemuRamfbDxe registers as VenHw device with a fresh generated uuid. The uuid should probably go to some header file, suggestions where to place it best? QemuRamfbDxe registers a acpi devpath node for the gop protocol. It's appended to the VenHw path, but looks like that isn't enough to create it as child node of the VenHw device (according to devtree outout). Suggestions how to fix that? Still this is good enough for consplitter to accept the device. The device path is added to the gPlatformConsole list, so consplitter will pick up the ramfb device even though it isn't a pci display device. The firmware display will show up on ramfb in addition to other display devices (if any). Is that approach ok? If so I'll do that for armvirt too. thanks and happy playing, Gerd
