Hi,
Resuming an old discussion ...
> > From
> > the guests point of view there is no difference between
> >
> > (a) qemu -device virtio-ramfb, and
> > (b) qemu -device virtio-gpu-pci -device ramfb-testdev
> >
> > On the host side the difference is that (a) is a single QemuConsole
> > which shows virtio-gpu-pci once activated and ramfb otherwise, and
> > (b) is two QemuConsoles, so you can see both virtio-gpu-pci and ramfb
> > side-by-side, for debugging purposes.
>
> Exactly this "multiple frontends, single backend" connection is the
> problem. In UEFI, it is possible to establish a priority order between
> drivers that are all capable of binding the same controller ("handle"),
> but especially with ramfb + another (PCI) video frontend, it's the
> "handles" that are different. The "priority mechanism" would have no
> idea that the drivers cannot peacefully coexist, i.e. it's clueless
> about the (host side only) competition.
Well, virtio-vga and qxl-vga are very simliar. They both are two-in-one
devices, with legacy vga frontend and native (qxl/virtio) frontend
sharing a single backend. When the guest initialized the native
frontend the backend switches over from vga to native.
> This is a problem because you display something on the one device, and
> the screen still shows the other, and users complain.
In ovmf the console splitter handles this reasonable well, firmware and
bootloader simply show up on all outputs. Got the ramfb driver to the
point where it joins the party properly.
The early boot phase (efifb active for linux) is more problematic. Only
one of the GOPs is used, and it seems whatever GOP was registered first
gets used. Try boot a fedora live iso with (a) "-device VGA -device
secondary-vga" and (b) "-device secondary-vga -device VGA". efifb shows
up on the first device (probably because it also is first in pci scan
order). fbcon shows up on the VGA device. So for (b) the boot output
switches the display when bochs-drm.ko loads.
> To my understanding, in Linux, special cross-driver hacks exist for
> this. For example, you boot with efifb (which is not a PCI device), and
> once an actual PCI display driver is configured, it is considered
> superior, and it supplants efifb.
Linux does two things here.
First it checks ressource ranges, and if there is a conflict the
firmware framebuffer (efifb in ovmf case, but vesafb and others on !x86
platforms are handled simliar) the firmware framebuffer driver is
unregistered, only the native framebuffer driver remains active.
Second one device is picked as "primary". Basically linux tries to
figure which device was activated by the firmware, to prefer that for
fbcon. This is what makes linux switch over in case (b) above, because
linux prefers VGA display devices here (-device secondary-vga is
PCI_CLASS_DISPLAY_OTHER).
The logic to pick the "primary" display is arch-specific.
> On a tangent: on the host side, we already have to entirely separate I/O
> consoles: some kind of graphics + emulated keyboard, plus serial. Those
> are always displayed in parallel -- not in two GUI toolkit windows, mind
> you, but it's never the case that one permanently "hides" the other.
Well, try "View / Detach tab" in the gtk ui in case you want them side
by side in two windows. SDL2 uses one window per console too.
> If this was the case with ramfb + something else (i.e., writing to ramfb
> wouldn't be possible to "read back" for the other firmware driver, from
> the PCI framebuffer, and one could switch back and forth between ramfb
> display and PCI display on their desktop), then it would be OK for both
> firmware drivers to bind. Point is, the two back-ends need not occupy
> double the screen real estate; it would suffice if one didn't hide the
> other permanently, and users could switch at will.
I think it makes sense for the *-ramfb devices behave simliar to the
existing *-vga devices, which are *not* user-switchable between
frontends.
Given ovmf has virtio-gpu drivers I'm not sure we need virtio-ramfb at
all.
> I could imagine an OvmfPkg-specific PCI capability that said, "all PCI
> drivers in OvmfPkg that could otherwise drive this device, ignore it --
> another (platform) driver in OvmfPkg will pick it up instead".
pci capability for ramfb could be useful (also for linux). I'll keep it
in mind for now.
cheers,
Gerd
