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

[Gerd Hoffmann]

  Hi,

> > 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?
> 
> (1) Under "OvmfPkg/Include/Guid/". The file "VirtioMmioTransport.h" is a
> minimal example.

Ok.

> (4) Once you add the venhw GUID as a standalone header file (see (1)),
> you won't need to duplicate the constants between patches. In
> "gQemuRamfbDevicePath", you'll be able to use the EFI_GUID structure
> initializer macro from the header file.

Sure.

> (5) Does it work if you replace ACPI_ADR_DISPLAY_TYPE_VGA with
> ACPI_ADR_DISPLAY_TYPE_EXTERNAL_DIGITAL? QemuVideoDxe uses the former,
> but VirtioGpuDxe uses the latter. Windows has some really obscure
> requirements dependent on "ACPI display type", if I remember correctly,
> and "external" looked the most robust when I last checked.

I'll try.

> > 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?
> 
> Absolutely, that's what we want.

Cool.

> > If so I'll do that for armvirt too.
> 
> (6) No extra steps should be necessary for ArmVirtPkg; in the

> Therefore, the second call will simply pick up the devpath from the new
> child (GOP) handle automatically, and add it to both ConOut and ErrOut.
> 
> Does it not work for you?

Didn't test arm at all yet, wanted to get x86 into shape first.  I'll
have a look as soon as I've fixed all the things listed above on x86.

thanks,
  Gerd