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
