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
