On 10/1/26 16:31, Thomas Zimmermann wrote: > Hi > > Am 01.10.26 um 12:46 schrieb Dmitry Osipenko: >> On 9/30/26 18:03, Thomas Zimmermann wrote: >>> Hi >>> >>> Am 30.09.26 um 15:27 schrieb Dorinda Bassey: >>>> Add DRM_FORMAT_HOST_ARGB8888 to the list of supported formats for >>>> virtio-gpu primary planes. Without this, glmark2-drm fails at >>>> startup because it selects ARGB visual configs by default, which >>>> don't match the XRGB-only plane capabilities. This causes >>>> drmModeSetCrtc to fail with EINVAL. >>> But does the host also support ARGB on the primary plane? We usually >>> don't export formats that are not available in (virtual) hardware. >>> >>> Best regards >>> Thomas >>> >>>> The virtio_gpu_translate_format() function already handles >>>> ARGB8888 translation to VIRTIO_GPU_FORMAT_B8G8R8A8_UNORM, >>>> so this just exposes the existing capability to userspace. >>>> >>>> Signed-off-by: Dorinda Bassey <[email protected]> >>>> --- >>>> drivers/gpu/drm/virtio/virtgpu_plane.c | 1 + >>>> 1 file changed, 1 insertion(+) >> For primary plane, alpha channel often doesn't matter as primary has >> fixed z=0 order and a usual alpha blending mode would account only >> overlay's alpha channel. Many real hw drivers expose alpha-channel >> formats for primary plane for compatibility with userspace, even though >> for them the alpha has no meaning for the primary plane. > > We decidedly do not offer formats that are not native to the hardware; > except for adding XRGB888. > > >> >> QEMU is most popular VMM using virtio-gpu, but there are others. For a >> stricter compatibility we can translate B8G8R8A8 to X8R8G8B8 for the >> primary plane in the driver code, but I assume in practice it's very >> unlike this will be necessary and we can always do it later on if will >> be needed. > > No in-kernel format conversion please; again except for adding XRGB8888.
Chances are low this may ever become necessary. Confirm glmark2-drm now works with this change. Applied to misc-next -- Best regards, Dmitry
