On Wed, Jan 15, 2025 at 11:03:29AM +0200, Tomi Valkeinen wrote: > Add new DRM pixel formats and add support for those in the Xilinx zynqmp > display driver. > > All of these formats are already supported in upstream gstreamer, except > in the gstreamer kmssink, which obviously cannot support the formats > without kernel having the formats. > > Xilinx has support for these formats in their BSP kernel, and Xilinx has > a branch here, adding the support to gstreamer kmssink: > > https://github.com/Xilinx/gst-plugins-bad.git xlnx-rebase-v1.18.5 > > New formats added: > > DRM_FORMAT_Y8 > - 8-bit Y-only > - fourcc: "GREY" > - gstreamer: GRAY8 > > DRM_FORMAT_Y10_LE32 > - 10-bit Y-only > - fourcc: "YPA4" > - gstreamer: GRAY10_LE32 > > DRM_FORMAT_XV15 > - Like NV12, but with 10-bit components > - fourcc: "XV15" > - gstreamer: NV12_10LE32 > > DRM_FORMAT_XV20 > - Like NV16, but with 10-bit components > - fourcc: "XV20" > - gstreamer: NV16_10LE32 > > DRM_FORMAT_X403 > - 10-bit 4:4:4 > - fourcc: "X403" > - gstreamer: Y444_10LE32 Could you possibly add support for those formats to the modetest util? > > Some notes: > > I know the 8-bit greyscale format has been discussed before, and the > guidance was to use DRM_FORMAT_R8. While I'm not totally against that, I > would argue that adding DRM_FORMAT_Y8 makes sense, as: 1) we can mark it > as 'is_yuv' in the drm_format_info, 2) we can have the same fourcc as in > v4l2, 3) it makes more sense for the user to use Y8/GREY format instead > of R8. > > Also, if we go with DRM_FORMAT_R8, then I think it would make sense to > also add the 10-bit grayscale version as R10, instead of Y10, and it > would also have to have 'is_yuv' false, and I feel that would just > create even more confusion. > > I have made some adjustments to the formats compared to the Xilinx's > branch. E.g. The DRM_FORMAT_Y10_LE32 format in Xilinx's kmssink uses > fourcc "Y10 ", and DRM_FORMAT_Y10. I didn't like those, as the format is > a packed format, three 10-bit pixels in a 32-bit container, and I think > Y10 means a 10-bit pixel in a 16-bit container. > > Generally speaking, if someone has good ideas for the format define > names or fourccs, speak up, as it's not easy to invent good names =). > That said, keeping them the same as in the Xilinx trees will, of course, > be slightly easier for the users of Xilinx platforms. > > There's also a bit unrelated path on top, fixing the missing max dma > seegment size in the zynqmp driver which I encountered while testing > these. > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> > --- > Changes in v2: > - I noticed V4L2 already has fourcc Y10P, referring to MIPI-style packed > Y10 format. So I changed Y10_LE32 fourcc to YPA4. If logic has any > relevance here, P means packed, A means 10, 4 means "in 4 bytes". > - Added tags to "Fix max dma segment size" patch > - Updated description for "Add warning for bad bpp" > - Link to v1: https://lore.kernel.org/r/20241204-xilinx-formats-v1-0-0bf2c5147db1@xxxxxxxxxxxxxxxx > > --- > Tomi Valkeinen (10): > drm/fourcc: Add warning for bad bpp > drm/fourcc: Add DRM_FORMAT_XV15/XV20 > drm/fourcc: Add DRM_FORMAT_Y8 > drm/fourcc: Add DRM_FORMAT_Y10_LE32 > drm/fourcc: Add DRM_FORMAT_X403 > drm: xlnx: zynqmp: Use drm helpers when calculating buffer sizes > drm: xlnx: zynqmp: Add support for XV15 & XV20 > drm: xlnx: zynqmp: Add support for Y8 and Y10_LE32 > drm: xlnx: zynqmp: Add support for X403 > drm: xlnx: zynqmp: Fix max dma segment size > > drivers/gpu/drm/drm_fourcc.c | 24 ++++++++++++++++++ > drivers/gpu/drm/xlnx/zynqmp_disp.c | 49 ++++++++++++++++++++++++++++++++++--- > drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 ++ > include/uapi/drm/drm_fourcc.h | 20 +++++++++++++++ > 4 files changed, 91 insertions(+), 4 deletions(-) > --- > base-commit: adc218676eef25575469234709c2d87185ca223a > change-id: 20241120-xilinx-formats-f71901621833 > > Best regards, > -- > Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> > -- With best wishes Dmitry
