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

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

[Peter Maydell]

Hi; I was doing a bit of cleanup of one or two of the older
display devices based on a note in BiteSizedTasks about removing
dead code that tries to support bit depths other than 32 for the
console display surface.

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" ?).

Is it still possible that surface_bits_per_pixel() could return 0
here, either transiently during system initialization or more
generally, eg for '-display none' ? Or is the 'case 0' code also
entirely dead ?

thanks
-- PMM

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

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

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

Quick follow-up check: this is always RGB, ie is_surface_bgr()
will always return false, right ?

thanks
-- PMM

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

[Gerd Hoffmann]

On Fri, Feb 12, 2021 at 06:38:16PM +0000, Peter Maydell wrote:
> On Thu, 11 Feb 2021 at 10:12, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> >   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.
> 
> Quick follow-up check: this is always RGB, ie is_surface_bgr()
> will always return false, right ?

Yes, always rgb (in host native byte order).

take care,
  Gerd