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

[Gerd Hoffmann]

  Hi,

> 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.

HTH,
  Gerd