[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Corrupted display changing screen colour depth in qemu-system-ppc/Ma
From: |
Gerd Hoffmann |
Subject: |
Re: Corrupted display changing screen colour depth in qemu-system-ppc/MacOS |
Date: |
Fri, 17 Jun 2022 11:55:58 +0200 |
Hi,
> > Can you try ditch the QEMU_ALLOCATED_FLAG check added by the commit?
>
> Commit cb8962c146 drops the QEMU_ALLOCATED_FLAG check: if I add it back in
> with the following diff on top then everything works again:
Ah, the other way around.
> diff --git a/ui/console.c b/ui/console.c
> index 365a2c14b8..decae4287f 100644
> --- a/ui/console.c
> +++ b/ui/console.c
> @@ -2400,11 +2400,12 @@ static void vc_chr_open(Chardev *chr,
>
> void qemu_console_resize(QemuConsole *s, int width, int height)
> {
> - DisplaySurface *surface;
> + DisplaySurface *surface = qemu_console_surface(s);
>
> assert(s->console_type == GRAPHIC_CONSOLE);
>
> - if (qemu_console_get_width(s, -1) == width &&
> + if (surface && (surface->flags & QEMU_ALLOCATED_FLAG) &&
> + qemu_console_get_width(s, -1) == width &&
> qemu_console_get_height(s, -1) == height) {
> return;
> }
>
> > Which depth changes triggers this? Going from direct color to a
> > paletted mode?
>
> A quick test suggests anything that isn't 32-bit colour is affected.
Hmm, I think the commit should simply be reverted.
Short-cutting the qemu_console_resize() call is only valid in case the
current surface was created by qemu_console_resize() too. When it is
something else -- typically a surface backed by vga vram -- it's not.
Looking at the QEMU_ALLOCATED_FLAG checks exactly that ...
take care,
Gerd