I am setting up a microdisplay connected to a BBB on the parallel LCD interface (RGB565). I also have a 5" 800x480 TFT LCD that I am using for testing since it is easier to see. I am in the process of configuring the BBB to output video data over the parallel LCD bus for the LCD instead of the HDMI framer.
I used the BB-BONE-LCD5-01-00A1.dts overlay example from the bb.org-overlays repository and only changed a couple back-porch lengths to comply with the datasheet from my LCD manufacturer. The overlay was compiled using the bb.org-overlays repo Makefile, placed into /lib/firmware, and loaded as a U-boot overlay. The disable_uboot_overlay_video option was set to disable the HDMI framer overlay. I verified that the overlays are detected and loaded appropriately by examining U-Boot output.
My goal is to play media using Gstreamer, which is installed and working as expected from a software perspective.
Text and large blocks of homogenous color are displayed (seemingly) correctly on the LCD. The issue seems to be with color gradients/areas with a lot of changing color.
I don’t have a lot of experience here but it seems like something in the framebuffer/DRM is configured incorrectly, almost like the number of bits per pixel is wrong and some color info is bleeding over into alpha channel? The bpp setting in the panel block in the dt overlay is set to 16, as it is in the example from the bb.org-overlays repo.
The below images show the Tux logo at boot, and the output of the kmscube OpenGL test utility:
Note the pixelated/aliased green-purple halo around Tux, and the stripes on the kmscube, which is normally a smooth color gradient. I have seen similar results with this green-purple pixelated halo around edges/areas of quick color change when displaying other images with Gstreamer and the PowerVR SDK (OpenGL).
This issue does not appear when the same LCD, with a deframer attached, is connected to the BBB over HDMI. Therefore I assume there is some setting, either in device tree or perhaps somewhere in a kernel function, that I need to change to reflect the new LCD configuration.
I do believe all the graphics examples such as kmscube are compiled to render to an RGBA8888 context but I assume the dithering to RGB565 should take place in some lower level driver.