Wayland, Dumb Frame-Buffers & Embedded SoCs
If you're not following the many Linux development mailing lists out there, the latest major discussion surrounding the Wayland Display Server that's spanned the Wayland, DRI/DRM, and Fbdev mailing lists has been about using Wayland on "dumb frame-buffers", KMS vs. fbdev, and DRM drivers on embedded SoCs.
This multi-topic discussion was started by a user, Geert Uytterhoeven, asking (the email) about the differences between kernel mode-setting (KMS) and simple fbdev drivers in the Linux kernel. At the same time, Geert was wondering if Wayland can be run on a "dumb frame-buffer" while letting the CPU handle advanced operations like image transparency.
Since last year there's been experimental work to run Wayland on a Linux frame-buffer. Kernel mode-setting also provides support for panic messages and greater debugging support (like a Linux "Blue Screen of Death") when the system is hosed, but so far that hasn't made much of a major debut yet. There's also Red Hat's Plymouth as a better boot-screen (that's now also used by Ubuntu and other Linux distributions) and it depends explicitly upon the KMS APIs for support.
The response to Geert's question by Intel's Jesse Barnes in the email was that DRM KMS APIs provide everything fbdev can provide, but it also adds in memory management, a method of exposing hardware acceleration (via GEM/TTM), and an effective way to manage multiple display outputs.
There was also another rant about KMS and fbdev by another user. "So if KMS is so cool and provides many advantages over fbdev and such... Why isn't more widely used instead of still relying on fbdev? Why still using fbdev emulation (that is partial and somewhat broken, it seems) instead using KMS directly? I know the graphic driver situation is quite bad on Linux, especially on the embedded world. Fbdev seems is still quite used there by binary blob drivers." In summarizing his message, "I hope all this gets to suck a bit less."
The reasons that Jesse Barnes provides for fbdev still being widely used in the embedded world is the inertia with fbdev having been around for a long time already and the DRM/KMS APIs providing more than what most developers looking for a basic frame-buffer really need. Alan Cox also interjected over more documentation being available for fbdev than KMS.
Corbin Simpson also added that Linux KMS is still missing basic user-space utilities for manipulating KMS drivers/displays and a direct KMS console rather than relying upon any emulation. He's also after a "xf86-video-modesetting" driver which would work with various KMS drivers that may not have an actual DDX driver available. It would be a generic KMS DDX driver as he's been working on kernel mode-setting support for some old GPUs, but without any user-space X driver, that work is of limited use until Wayland is mainstream. "One of the big goals of KMS was a generic userspace-facing API, like FB, but without the suck."
Tiago Vignatti also jumped on the list to say that he's worked on Wayland from a frame-buffer.
AMD's Alex Deucher was yet another developer taking part in this discussion. He brought up the SoC vendors that are adding an fbdev emulation layer on top of V4L. With V4L there is its own EDID, HDMI, and CEC handling to deal with.
Bringing up SoCs led Robert Fekete of Linaro to write about the situation. It's just a big mess with SoC/embedded graphics right now and trying to get them to use DRM/KMS rather than V4L/fbdev.
- Developments within V4L2 has mainly been driven by embedded devices while DRM is a result of desktop Graphics cards. And for some extent also solving different problems.
He then brought up a Linaro discussion that is currently taking place regarding memory management. With open-source DRM/KMS drivers there's GEM (Graphics Execution Manager) and TTM (Translation Table Maps) to pick from. Intel uses GEM while the ATI/AMD and Nouveau drivers are using TTM while interfacing with the GEM APIs. The VIA Linux DRM work is also using primarily TTM. With the SoC vendors though, they have a few other choices. There's also HWMEM, UMP, CMA, VCM, CMEM, and PMEM as possible memory choices when developing a driver, but those are not in the kernel.
That's a quick overview of where the discussion is at right now.
Latest Articles & Reviews
Latest Linux News
Most Viewed News This Week