DRM driver issue with DRM_FORMAT_YVU420 on Raspberry Pi 5

[KonstaT]

Describe the bug

I'm having an issue during video playback with Android on Raspberry Pi 5. This issue is not present on Raspberry Pi 4 with the same graphics components (drm-hwcomposer, minigbm gralloc, mesa vc4 & v3d gallium & broadcom vulkan).

R and B are swapped during video playback i.e. it looks like this.

vs. how it should.

Currently the kernel (https://github.com/raspberry-vanilla/android_kernel_brcm_rpi) is at 6.12.52 but this issue has been present from the start on Pi 5 (i.e. with 6.1 and 6.6 as well).

Current workaround with drm-hwcomposer (https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer) has been to set client (GPU) composition for DRM_FORMAT_YVU420 instead of using device (DRM) composition as it should (https://github.com/raspberry-vanilla/android_external_drm_hwcomposer/blob/android-16.0/backend/BackendRpi5.cpp). This way the colors are displayed correctly during video playback.

drm-hwcomposer maintainers have suggested that this is an issue with the kernel DRM driver (https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/merge_requests/328#note_2790523).

Any idea why this is happening? What is different on Pi 5 compared to Pi 4 in this regard?

drm-hwcomposer maintainer also suggested (https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/issues/125) to run test pattern with modetest. I tested all the formats and YV12, YV16, and YV24 show R and B are swapped compared to the others.

console:/ # stop vendor.hwcomposer-3
console:/ # modetest -M vc4 -s 33:1920x1080-60@YV12
opened device `Broadcom VC4 graphics` on driver `vc4` (version 0.0.0 at 0)
setting mode 1920x1080-60.00Hz on connectors 33, crtc 92

Any other relevant information I can provide?

Thanks.

Steps to reproduce the behaviour

AOSP on Raspberry Pi 5.

Device (s)

Raspberry Pi 5

System

AOSP on Raspberry Pi 5.
Linux kernel 6.12, 6.6, and 6.1.

Logs

No response

Additional context

No response

[6by9]

Thanks for the report.
Pi5 has an updated version of the HVS to support dual 4k60 and extra pixel formats. Various bits of the hardware configuration are slightly different, and the driver should be programming it correctly.

I've reproduced the issue using kmstest -f 1280x720-YV12. (kmstest being part of https://github.com/tomba/kmsxx/ and more friendly than modetest).

In this case it does look like the hardware behaves differently to the previous generations. The driver config in https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/gpu/drm/vc4/vc4_plane.c#L125-L136 sets the component ordering for the planes to be Y CR CB, but it's then apparently ignoring it.
Checking the docs, and oddly that field isn't listed as being applicable for HVS formats 8, 10, 12, 13, 14, 15, or >18 (see https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/gpu/drm/vc4/vc4_regs.h#L1058-L1090 for the definitions). Gut feel is that it would have taken more effort to make them n/a than to implement them! C'est la vie.

Fortunately for the 3-plane formats there is the easy fix by swapping the pointers to the Cb and Cr planes. I'll sort a PR.

[6by9]

#7122 for a fix.

[KonstaT]

Thanks for looking into this.

Unfortunately still the same issue with kernel built with patch from #7122.

modetest test pattern also still shows that R and B are swapped on YV12, YV16, and YV24.

[popcornmix]

The fix worked for me when tested with:
kmstest -f 1280x720-YV12

I updated with
sudo rpi-update pulls/7122

[KonstaT]

Hmm, that's strange. I'm definitely on kernel with patch from #7122.

I only have modetest to try. All Linux tools need to be compiled against Android bionic C-library (vs. glibc) to work on Android.

[6by9]

Ah, two different approaches to defining the buffer.
kmstest creates 3 distinct plane buffers. modetest creates one buffer with offsets.
I'd only swapped the base addresses, not the offsets. Updating....

[6by9]

#7124 fixes it for both kmstest and modetest for me.

[KonstaT]

Excellent, can confirm that this issue is resolved after #7124.

Thank you very much for the quick fix!