On 30/03/17 14:41, Gerd Hoffmann wrote: > Hi, > >> Excellent! I can help out with converting and/or testing the SPARC >> devices (cg3/tcx) if required. > > Sure, test results and patches are very welcome.
I've spent a bit of time over the weekend attempting to convert the SPARC CG3/TCX framebuffers over to use your new code and pushed the result to my github branch here: https://github.com/mcayland/qemu/commits/vga-fixes-sparc. Feel free to steal/test/borrow as required. The two main things I've discovered to date are: 1) Problems with asserts() in cpu_physical_memory_snapshot_get_dirty() Using your current git branch, I get an assert() using VGA under qemu-system-ppc on startup unless I change the first assert to "assert(start >= snap->start)". I'm also not convinced by the second assert "assert(start + length < snap->end)" either. In the example CG3/TCX conversions I ended up having to subtract 1 from the size of the region passed to memory_region_snapshot_get_dirty() in order to avoid it firing when accessing the last scanline which seems wrong. I didn't explicitly add a patch to change this to "<=" in my git patchset just in case it broke further assumptions in the bitmap code relating to the end address. 2) Redraw issues with CG3/TCX after conversion Despite the conversion from your patches looking reasonably straightforward, I still see problems with areas of the screen not updating after conversion. I can easily reproduce these locally as follows: ./qemu-system-sparc -vga cg3 -prom-env 'auto-boot?=false' ./qemu-system-sparc -vga tcx -g 1024x768x8 -prom-env 'auto-boot?=false' ./qemu-system-sparc -vga tcx -g 1024x768x24 -prom-env 'auto-boot?=false' You can trigger extra screen updates by typing "show-devs" into OpenBIOS which will cause a lot of screen activity as it writes the device tree out to the framebuffer. I'm wondering if maybe this is related to the difference in sizes between DIRTY_MEMORY_BLOCK_SIZE and TARGET_PAGE_BITS for qemu-system-sparc? Finally on a slightly unrelated note, the TCX driver still has old code for 8 and 16 bpp surfaces in QEMU. Am I right in understanding that all surfaces in QEMU are now 32-bit and the 8/16 bpp code can be removed? ATB, Mark.
