Why SUSE Is Using FBCON Rather Than DRM/KMS For Their In-Kernel Boot Splash

In the many forum comments and elsewhere is a frequent theme of complaints that this new SUSE technology is using the FBDEV layer rather than writing for the modern DRM/KMS APIs. SUSE's Max Staudt who has been leading the work on this kernel bootsplash system emailed into Phoronix today to clarify why their design choice.
Targeting FBDEV was done as a lower common denominator to nearly all Linux systems out there, including many embedded platforms where FB drivers remain popular. With KMS drivers offering FB emulation, there's not only support for the many desktop systems out there (and growing number of mobile platforms) with Direct Rendering Manager drivers, but also the plethora of systems still relying upon FBDEV without any thought/interest in DRM/KMS.
Additionally, Staudt explained that there isn't a good way to build this bootsplash system directly on top of the KMS interfaces. This also would prevent bootsplash from working where KMS isn't even activated yet in the very early stages of the kernel boot process.
Max Staudt further explained his design reasoning in this kernel mailing list post.
While for years there have been calls to deprecate FBDEV, Max acknowledges in the future bootsplash could be re-based to using KMS if the necessary interface additions are made and DRM/KMS drivers become more dominant in the embedded world. "I've prepared the code for a future in which fbdev no longer exists: My sysfs interface is generically called 'bootsplash', in the hope that it will one day move on top of KMS. The hooks into fbcon are minimal and the code is straightforward to port to KMS operations rather than FB. But that's for another day, as far as I can see."
20 Comments