Is it possible to output YUV color to the frame buffer

How-to
1

Description

Hi, I’m working with a modified instance of a “simpledrm” kernel driver framebuffer where the only modification is it adds YUV support (so not much changes there). The plane’s only listed supported format is YUYV when checked with modetest, so I’m confident that aspect is working and I don’t believe it would be doing conversion from YUV to RGB in the driver.

The framebuffer is setup that way such that my HW will read it when it wants to but expects the data there to be YUYV (8 bit 4:2:2) format. I thought I had setup things moderately well to configure that, but noticed that there wasn’t really a way to save colours natively in YUV so I was hopeful there might be some conversion behind the scenes. From what I can deduce, the colour output into the framebuffer is instead RGB565 which produces some interesting results in YUV (pure red is seen as Y=248, U=V=0).

I suspect I need to add either a callback for conversion for weak support (calculation every time) or new colour handling and draw function support (at minimum, probably more for blending / drawing).

What MCU/Processor/Board and compiler are you using?

Xilinx ZynqUS+ running busybox, linux kernel is a fork of 6.1 LTS

What LVGL version are you using?

9.3.0 dev

What do you want to achieve?

  • Generally, is it possible to have it output in YUV colour space into the buffer?
  • Is there a native color space change I can modify it to use (to avoid potentially costly colour space conversion at final step)?
  • If not native colour space change, is there a function/setting/callback that I set/add that could convert it to YUV?
    • If so, would adding it in the flush_cb drm_flush be the best place to do so? I recall seeing a note about something similar for swapping endianness of RGB.

What have you tried so far?

lv_conf.h

#define LV_COLOR_DEPTH=16

lv_linux_drm.c

#if LV_COLOR_DEPTH == 16
    #define DRM_FOURCC DRM_FORMAT_YUYV
#else
    #error LV_COLOR_DEPTH not supported
#endif

then for testing, I also tried setting the display color format in my main executable before I setup any colors. No chnage.

Additional Notes

If I have to do a bit of an overhaul to get native YUV handling, I have some rudimentary specific use case ideas which can maybe jankily work in my use case since i don’t do blending.

2

I managed to hack together a solution, but it’s not something I’d commit to the code base as it’s super specific and does leave some 422 compression artifacts