Re: can surface_bits_per_pixel() for the console surface ever return anything other than 32 ?

[Peter Maydell]

On Thu, 11 Feb 2021 at 10:12, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > I notice that as well as handling surface_bits_per_pixel()
> > possibly returning 8, 15, 16, 24, these devices also seem to
> > check for the possibility it returns 0 (presumably meaning
> > "no surface" or "no surface yet" ?).
>
> Depends a bit on how the surface is created.
>
> When using host memory as backing storage (typical workflow is
> qemu_console_resize() + qemu_console_surface() calls) bits per pixel is
> 32 no matter what (format is PIXMAN_x8r8g8b8 to be exact).  I think this
> is true for most if not all arm display devices.
>
> Depth 15+15+24 can happen when the display device uses
> qemu_create_displaysurface_from().  That is typically the case when
> using guest-accessible memory (vga vram for example) as backing storage
> for the surface.  Which implies there is no need for the display device
> to update the surface in the first place because the guest can render
> directly to the surface then.
>
> "no surface" can only happen when the display device explicitly calls
> dpy_gfx_replace_surface(con, NULL).  virtio-gpu does that in case the
> guest disables the output for example.

Thanks. It sounds like for the displays I'm interested in
I can just assume the surface is always 32 bits with no
exceptions (and it's easy enough to grep for whether the
device is making one of the function calls you list).

-- PMM