Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello,
Thank you for your detailed explanation and system description! I’ll address each of your questions regarding achieving 24bpp or 32bpp framebuffer output on Colibri iMX6DL with the current imx-drm stack and Linux kernel 6.6.x.
1. Is 24bpp or 32bpp Framebuffer Possible with imx-drm on iMX6DL Parallel RGB?
Based on available information, the imx-drm driver for the i.MX6 typically exposes only a 16bpp (RGB565) framebuffer for the parallel RGB interface, regardless of full 24-bit display capabilities in hardware. This limitation is common across recent mainline Linux kernels and aligns with your observations—changes to device tree settings (e.g., bus-width, interface-pix-fmt, panel bus-format) do not affect the framebuffer color depth exposed to userspace.
2. Source of the Limitation: Kernel Driver or Hardware?
This appears to be primarily a kernel driver limitation:
- The i.MX6 hardware can theoretically drive 24 bits to a parallel RGB display, and your device tree and hardware configuration confirm 24 bits are physically routed.
- The imx-drm driver currently requests and exposes a 16bpp modeset and framebuffer through DRM, likely for broad compatibility with legacy fbdev applications and due to upstream driver development history.
3. Device Tree, Kernel Config, or Patches to Enable Higher Color Depth?
There are no known device tree properties or standard kernel config options that allow selection of higher color depth for the parallel RGB output path using imx-drm. Changing bus-format, interface-pix-fmt, or similar parameters in device tree only informs the system about hardware wiring, not the in-memory framebuffer format offered by the driver. Patching the kernel—specifically the imx-drm or related DRM drivers—to support and expose 24/32bpp might be possible, but this is non-trivial and not officially supported by Toradex as of kernel 6.x.
4. Has Anyone Achieved True 24/32bpp with DRM on i.MX6 Parallel RGB?
In community and upstream forums, there are few (if any) successful reports of obtaining a true 24bpp or 32bpp system framebuffer over the DRM interface for the i.MX6’s parallel RGB output, especially with recent (5.x/6.x) kernels. The status quo remains 16bpp, both with the mainline and downstream/Freescale-based kernels.
5. Possible Workarounds or Alternative Approaches
Recommended approaches:
- Wayland/Weston: Even though the hardware sits on a 24-bit bus, system-level framebuffer output is 16bpp. Weston/Wayland compositing may internally handle higher color precision but final output is constrained to 16bpp.
- Direct Rendering: For advanced cases, you could attempt custom DRM userspace composition with explicit pixel formats via EGL/GBM, but kernel support for non-16bpp formats must be present.
- Kernel Modification: With significant effort, you might patch the imx-drm driver to request and expose higher color depth formats. This is not straightforward and carries a maintenance cost. For reference: Device Tree Overview | Toradex
- Legacy fbdev: In the past (with older kernels and legacy fbdev drivers, e.g., cfb or mxcfb), some users managed partial 24bpp output, but this is no longer supported/recommended.
- Accept 16bpp Output: Most commercial designs with i.MX6 parallel RGB use the provided 16bpp output, which simplifies driver and compositing requirements.
Summary
- Current imx-drm exposes only 16bpp on parallel RGB—even with 24-bit wiring.
- This is a kernel driver limitation rather than a hardware restriction.
- No device tree or config workaround is available; kernel source changes would be required.
If your application demands true 24- or 32-bit in-memory framebuffer format at the system level, alternate hardware platforms or significant kernel customization would be necessary.
If you would like guidance on possible starting points for driver modification or testing alternative pixel formats, please let me know.
Best regards,
Toradex AI Assistant.
