On Tue, 2014-06-17 at 13:57 +0200, Gerd Hoffmann wrote: > Ok, it is supposed to work this way: > > The virtual graphics card creates a DisplaySurface, which is a pixman > image under the hood. There are basically two ways to do that: > > (1) Use qemu_create_displaysurface(). Allocates host memory. > Returns 32bpp framebuffer in host byte order. virtual graphics > card is supposed to convert the guests framebuffer into that > format. > (2) Use qemu_create_displaysurface_from(). DisplaySurface (and pixman > image) is backed by guest display memory then. pixman format > obviously must match the guests framebuffer format. > > The ui (gtk / sdl / vnc / screendump via monitor) is supposed to deal > with whatever it gets. Typically the ui checks whenever it can use the > format directly, and if not it converts using pixman (see gd_switch in > ui/gtk.c for example). vnc and screendump use pixman too. sdl feeds > SDL_CreateRGBSurfaceFrom with the shifts of the pixelformat instead.
Allright, I'll play with this, it makes sense to get rid of most of the conversion functions if we know the surface will always be 32-bit indeed. I think we can work step by step: - Remove all the non-32bpp targets from vga_template - Add the 32-bit target only version of my byteswap This gives us something that works quickly. We also need to focus on how to trigger the endian mode etc... Then we can - Look into doing at least some of the conversions in pixman Which would be a subsequent optimization. Any objection ? I'll spend some time in the next few days getting myself a bit more familiar with that pixman stuff (I need to fix the ppc vector stuff for LE in there anyway) and come up with patches. Another step I hinted to earlier is how we do the actual endian transition. My idea is to add a new register to the BOCHS DISPI VBE list and bump the PCI revision ID to advertise its existence. Additionally, I wouldn't mind of we did a quick "trick" equivalent (but cleaner) to what I did in my patch which is when the pseries guest calls the hypervisor call to change the interrupt endian mode, we notify VGA and switch its endian mode, so we work "by default" with kernels not updated to know about that register. But this is open for debate. It's somewhat "acceptable" in the context of our hypercall being a "paravirtualized" interface, so it can be argued that the hypercall poking at the VGA chip is equivalent to some FW doing so :-) Cheers, Ben.
