Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

[Gerd Hoffmann]

  Hi Dave,

Triggered by the framebuffer endian issues we have with stdvga I've
started to check where we stand with virtio-gpu and whenever we have to
fix something in the virtio protocol before setting in stone with the
upstream merge.

Fixed the protocol.  Basically s/uint32_t/__le32/g.  No changes on
x86_64 obviously.

Fixed the kernel driver to byteswap values when needed.  See
https://www.kraxel.org/cgit/linux/log/?h=virtio-gpu-rebase

Result is bigendian guest on little endian host boots fine (without
virgl).  Colors are wrong though.  Other way around still needs a bunch
of fixes in qemu so virtio-gpu works correctly on bigendian hosts.  To
be done.

So, on the color issue:  How are these defined exactly?

> +    VIRTIO_GPU_FORMAT_B8G8R8A8_UNORM  = 1,
> +    VIRTIO_GPU_FORMAT_B8G8R8X8_UNORM  = 2,
> +    VIRTIO_GPU_FORMAT_A8R8G8B8_UNORM  = 3,
> +    VIRTIO_GPU_FORMAT_X8R8G8B8_UNORM  = 4,

Looking at the code it seems the name defines the byte ordering in
memory, i.e. "B8G8R8A8" means blue first, then red, then green, then
alpha.  Or DRM_FORMAT_ARGB8888 on little endian / DRM_FORMAT_BGRX8888 on
big endian.  Correct?  Easy fix in the guest driver then ...

> +    VIRTIO_GPU_FORMAT_B5G5R5A1_UNORM  = 5,
> +    VIRTIO_GPU_FORMAT_B5G6R5_UNORM    = 7,

Do we really wanna go down this route?  I'm inclined to just zap 16bpp
support.

> +    VIRTIO_GPU_FORMAT_R8_UNORM        = 64,

What is this btw?  Looks like gray or alpha, but why "R8" not "G8" or
"A8" then?  Why the gap in the enumeration?

With the formats being clarified fixed we are settled for 2d mode I
think.

What about 3d mode?  We are passing blobs between virglrenderer and
guest driver:  capabilities and gallium 3d command stream.  What happens
to them in case host and guest endianness don't match?  I think at least
the capabilities have 32bit values which need to be swapped.  Dunno
about the gallium commands ...

cheers,
  Gerd