Re: [Qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legacy vga

[Gerd Hoffmann]

  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