RK3576's decoder emits 16x16 AFBC, but its VOP3 Cluster windows accept only 32x8

[Ebrahim-Shirani]

With the duplicate removed and modifiers enabled, an AFBC frame from mppvideodec arm-afbc=1 is
still never placed on a plane. Weston's drm-backend debug scope says why:
not placing view on primary: no free primary planes matching
format YUV420_8BIT (0x38305559) modifier 0x800000000000041

0x0800000000000041 is ARM_AFBC(BLOCK_SIZE_16x16 | SPARSE) — the value hardcoded as
DRM_AFBC_MODIFIER in the SDK's own waylandsink and rkximage patches, and MPP offers no
block-size choice (MPP_FRAME_FBC_AFBC_V1/V2 differ only in payload-offset convention, and
vdpu383_afbc_align_calc() aligns to 16 rows). format_modifiers_afbc_tiled_for_vop3[], however,
is 32x8 in every entry. The intersection is empty, so the display-side AFBC path is unreachable:
the compositor imports the frame through Mali and composites it on the GPU instead, and kmssink

• AFBC fails outright because drm_mode_addfb2() rejects the unadvertised modifier.

We tested whether the hardware would accept 16x16 anyway, by advertising 0x0800000000000041 on
the Cluster windows in a throwaway build. The framebuffer is created, the view is promoted, the
atomic commit succeeds and the driver reports Cluster0-win0: YU08[AFBC] ACTIVE at 60 fps with no
dropped frames — but the displayed image is corrupt, with continuous
POST_BUF_EMPTY_INTR irq err. That matches the comment in vop2_afbc_half_block_enable(), which
states that on rk3576 the bit selects "4 line per tail line for rfbc[64x4]" or "8 line per tail
line for afbc[32x8]" — no 16-line tail, hence no 16x16 superblock.

Our questions:

1. Is 32x8 the true and only AFBC layout RK3576's VOP3 Cluster windows can decode? We are
   treating the modifier list as authoritative and have reverted our experiment; a confirmation
   would let us close the question for good.
2. Can the RK3576 video decoder be made to emit 32x8 AFBC, through MPP configuration or a
   firmware/driver update? If not, decoder→display AFBC is structurally unavailable on this SoC.
3. What is the intended zero-copy compressed display path on RK3576? The Cluster windows also
   advertise DRM_FORMAT_MOD_ROCKCHIP_RFBC(64x4) and ROCKCHIP_TILED 8x8 / 4x4, but nothing in
   the SDK's userspace produces RFBC, and mppvideodec exposes no tiled-output option. If RFBC or
   tiled output is the supported route, which component is expected to produce it, and is
   GStreamer/Wayland support planned?