On 01/24/12 01:23, Kevin O'Connor wrote:
On Mon, Jan 23, 2012 at 12:30:29PM +0100, Gerd
This patch series prepares vgabios for being used as qemu vga bios.
Are you thinking of driving an effort to replace the default vga bios
in qemu? (Assistance would be helpful here.)
I'd love to do that. A vga bios largely written in C is much easier to
handle, also the lgpl vgabios upstream is very non-responsitive.
As for current state in comparison to the existing
LGPL vgabios, the
only thing I'm aware of is the Cirrus support still lacks a few vbe
calls (calls 05/06/07/10) and BochsVGA has similar vbe calls lacking
(calls 04/05/06/07/0a) and BochsVGA has a 32bit mode interface not
implemented. The remaining calls look pretty straight forward, but
the 32bit interface would require some build magic.
Testing is going to be the real challenge. I don't even know what (if
anything) actually uses some of the obscure vgabios calls.
Agree. Didn't test vbe at all yet. vesafb can use these calls, but
doesn't by default. In 8bit modes (pretty out of fashion these days)
they are used to set the palette registers, but vesafb happily falls
back to direct vga port access in case they are not available. vesafb
can also pan the display for faster scrolling, which uses these calls
too to set the first scanline to be displayed.
with multiple vga card emulations, so we need multiple
vgabios binaries. All build out of the same source tree, but with
different config options. Thus patch #1 revamps vgabios configuration
to allow building different variants in one go. Patches #2 .. #5 enable
more qemu virtual hardware support on top of that.
Why does QEMU have so many different vgabios blobs? QEMU is actively
peaking into the blob and updating the PCI ids, so it shouldn't
require a different blob for each BochsVGA variant.
Hmm, need to check. The lgpl vgabios looked up the card by pci id, so
the pci id is encoded in more places than just the rom header, thus the
patching approach doesn't fly. The seabios version uses the bdf passed
in from seabios instead if I read the code correctly, so the patching
should actually work.
That would then
leave just two blobs - Cirrus and Bochs. I do wonder if it would be
simpler to just run the build twice (updating .config between builds).
Another way would be runtime detection, so we could have a single bios
binary with both cirrus and bochs support.