With the previous, Dunfell-based releases 5.7.x, (kernel 5.4.x) we had 2 framebuffer devices for the display. After switching to release 6.6.0 (mainline-kernel 6.1.80) we only have /dev/fb0 left, the overlay framebuffer /dev/fb1 does not exist anymore.
The documentation does not help.
How can we re-enable the second framebuffer?
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Transitioning from Dunfell-based releases to the newer mainline-kernel 6.1.80 (release 6.6.0) and encountering a reduction in available framebuffer devices is indicative of changes in the kernel’s handling of display and framebuffer devices. In the context of the i.MX 6 and moving to a newer kernel version, it’s important to note that the newer kernel versions have seen significant changes in how they handle graphics, particularly with a shift towards Direct Rendering Manager (DRM) based solutions over the traditional framebuffer (fbdev) interface.
To re-enable the second framebuffer (/dev/fb1) on i.MX 6 with the mainline kernel 6.1.80, you might need to consider the following approaches:
Check for Kernel Configuration: Ensure that the kernel is configured to support multiple framebuffer devices. This involves checking the kernel configuration (make menuconfig or make xconfig) for options related to framebuffer devices and DRM. Specifically, look for options related to your graphics hardware and ensure that support for multiple framebuffers is enabled.
DRM and OverlayFS: With the shift towards DRM, the approach to handling overlays and multiple framebuffers might have changed. Investigate if there’s a need to use DRM APIs or utilities to create and manage overlay framebuffers instead of relying on static /dev/fbX devices. This could involve using tools like modetest or APIs to create framebuffers dynamically.
Device Tree Adjustments: For ARM-based systems like the i.MX 6, the device tree might need adjustments to define and enable additional framebuffer devices or to configure the display subsystem correctly under the newer kernel. Review the device tree blobs (DTBs) for any necessary changes that reflect the hardware setup and desired framebuffer configurations.
Custom Kernel Patches: If the mainline kernel does not support your specific use case out of the box, you might need to look into backporting patches from the older kernel version or creating custom patches that reintroduce the functionality you need. This could involve modifying the DRM or fbdev subsystem to explicitly support multiple static framebuffer devices.
Community and Mainline Kernel Resources: Sometimes, similar issues have been encountered and addressed by the community or within newer kernel releases. Checking the Linux kernel mailing lists, forums dedicated to Linux on ARM, or even the i.MX community for insights or patches can be beneficial.
Fallback to fbdev: If your application strictly requires the fb
Please, also check if these links can help you solve your problem:
Display Output, Resolution and Timings (Linux) | Toradex Developer Center.
Hello @sst,
The /dev/fb0 interface you see on BSP 6 is in fact a framebuffer emulation implemented using DRM.
This is the case because the previous /dev/fb* interface has been deprecated for quite some time and is not directly supported by the open-source etnaviv driver used on BSP 6.
The recommended approach for overlaying two images would be to use the relevant DRM functionality.
It would also be possible to handle such overlaying in your application or using a compositor such as Weston.
Best Regards,
Bruno
Hello Bruno,
thank you for your reply. With our current system we can not switch to Weston. I will try DRM.
