Accessing a DRM Framebuffer to display an image

submited by

Style Pass

2024-11-30 13:00:05

This shows random data on the display and a lot of gray, red, blue, and green dots appear. This doesn't tell us if everything is working as expected because maybe the resolution is wrong or some timings are too tight but it gives already an indication if the display controller works and if the display gets some understandable data.

However, this example only works for framebuffer device drivers under Linux. For the iMX6 this means that the above method only works for the proprietary driver but not for the upstream-based driver. Modern Linux graphics drivers like the iMX6 upstream driver provide a DRM interface to the user space and therefore don't provide a framebuffer device. We can't just simply dump data to a character device to show it on a display. Instead, we need to set up a whole pipeline that tells what framebuffer should be used as input to the CRTC.

This image shows three different stages which can be configured by DRM. The first stage CRTC (Cathode-ray tube controller, the name comes from old cathode-ray tube displays) takes memory as input and creates an image based on the framebuffer and planes. Planes can overlay others (e.g. primary, cursor, video, etc.) and the output of the CRTC stage will result in a modified memory buffer that contains the image which should be displayed. Not all DRM drivers support multiple planes. The minimum required plane is one, which is the primary plane. The primary plane represents the dumb framebuffer in this example.