Hi
On Fri, Jun 17, 2022 at 1:56 PM Gerd Hoffmann <kra...@redhat.com> wrote:
>
> 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 ...
Oh ok, it might be worth adding a comment to clarify that. By
reverting, we are going back to the situation where
qemu_console_resize() will create a needless surface when rendering
with GL. As I tried to explain in the commit message, it will need
more changes to prevent that. I can take a look later.
