On 06/13/18 14:29, Gerd Hoffmann wrote: > The boot framebuffer is expected to be configured by the firmware, so it > uses fw_cfg as interface. Initialization goes as follows: > > (1) Check whenever etc/ramfb is present. > (2) Allocate framebuffer from RAM. > (3) Fill struct RAMFBCfg, write it to etc/ramfb. > > Done. You can write stuff to the framebuffer now, and it should appear > automagically on the screen. > > Note that this isn't very efficient because it does a full display > update on each refresh. No dirty tracking. Dirty tracking would have > to be active for the whole ram slot, so that wouldn't be very efficient > either. For a boot display which is active for a short time only this > isn't a big deal. As permanent guest display something better should be > used (if possible). > > This is the ramfb core code. Some windup is needed for display devices > which want have a ramfb boot display. > > Signed-off-by: Gerd Hoffmann <[email protected]> > --- > include/hw/display/ramfb.h | 9 +++++ > hw/display/ramfb.c | 95 > ++++++++++++++++++++++++++++++++++++++++++++++ > hw/display/Makefile.objs | 2 + > 3 files changed, 106 insertions(+) > create mode 100644 include/hw/display/ramfb.h > create mode 100644 hw/display/ramfb.c
I tested this on KVM, built from Gerd's sirius/ramfb branch @ 778450b87275. Works fine with Gerd's corresponding edk2 QemuRamfbDxe driver (already merged): [edk2] [PATCH v3 0/4] Add QemuRamfbDxe driver http://mid.mail-archive.com/[email protected] It also works fine with Ard's efifb patches: [PATCH 0/2] efi: add support for cacheable efifb mappings http://mid.mail-archive.com/[email protected] So, for this patch (not the series): Tested-by: Laszlo Ersek <[email protected]> Thanks! Laszlo
