A Call For Deprecating The Linux Frame-Buffer FBDEV

[robclark]

Fbdev is a public ABI between the kernel and the user space. That stuff is the most difficult (by the rules) stuff to change or drop in the world of Linux. That means, that if the decision was made today to drop fbdev completely, it will then take at least several years, before the first signs of actual removal in the code base could be done. Those are simply the kernel rules. You cannot break existing user space.

Just like what Delgarde said above.

yup.. existing drivers wouldn't be removed any time quickly. The point/suggestion is, that *new* drivers should be written as drm/kms drivers rather than fbdev drivers.

Of course, perhaps not everyone who might have an opinion on the subject was present at LPC, so I am sure there will be some differing opinions. But at least the consensus of people who actually were here at LPC was that it would be a good idea to make writing drm/kms drivers for simple hardware easier, and add new drivers as drm/kms drivers rather than merging any new fbdev drivers.

BR,
-R

[curaga]

For simple 2d usage, I wonder what advantages does writing a drm/kms driver over a much simpler fbdev driver bring? I was under the impression that it's only egl/3d that it has as pros.

There's also about zero ready apps using the drm/kms interface, vs a decade of fbdev software.

[robclark]

For simple 2d usage, I wonder what advantages does writing a drm/kms driver over a much simpler fbdev driver bring? I was under the impression that it's only egl/3d that it has as pros.

There's also about zero ready apps using the drm/kms interface, vs a decade of fbdev software.

Well, X11, wayland, and kmscon come to mind ;-)

drm/kms adds a lot of features unrelated to 3d, which are missing in fbdev (hotplug, multiple displays w/ span/clone, more flexible way to handle flipping). Perhaps not something that matters too much for very simple hw. But for any more sophisticated hw, you really need drm/kms. So it is better to start recommending that new hw gets drm/kms drivers, and that userspace starts using drm/kms APIs, otherwise we never get away from this two-subsystems-to-do-same-thing situation.

It isn't like existing fbdev drivers will be removed from the kernel anytime soon. And drm/kms does provide a minimal fbdev compat layer.. it isn't fully featured, although I suppose missing features could be added (patches welcome). But in general I think it is a better idea just to add drm/kms support in all the various userspace toolkits/frameworks (sdl, directfb, etc), rather than layering on the glue.

[curaga]

X runs on fbdev, wayland runs on X, and kmscon is a huge NIH-ism when fbcon works well. :P

Multiple displays and hotplug, neither are needed in typical embedded cases, when there's only one display for the lifetime of the device. I'm not seeing whether there's any reason at all for these deployments to switch apis, the fact that someone wants to deprecate a well working api doesn't really count.

[daniels]

fbdev also doesn't support pageflipping (i.e. tear-free displays), integration with GPU acceleration, or even video overlays in any real/meaningful way. These are things which are very very much required for the embedded/mobile usecases you've mentioned.

If people want to keep on using fbdev, no-one's forcing them to switch. But it's just a recommendation that from now on, people write drivers against a modern, clean, well-maintained subsystem that supports everything modern hardware does and modern usecases require out of the box, instead of a dead subsystem that was deficient even fifteen years ago.

[robclark]

X runs on fbdev, wayland runs on X, and kmscon is a huge NIH-ism when fbcon works well. :P

X runs on fbdev w/ limited feature set (no modesetting). But there is also a basic modesetting driver now so X does not require fbdev.

Wayland on X probably doesn't really count, if you are talking about kernel display interfaces. X is not a kernel display subsystem.

And I've tried kmscon recently.. it is pretty nice actually, and way faster than fbcon, and supports hotplug. And I suppose some people would appreciate the possibility for proper support of unicode. But I guess one person's NIH-ism is another person's moving-on-and-creating-something-with-modern-features-ism :-P

Multiple displays and hotplug, neither are needed in typical embedded cases, when there's only one display for the lifetime of the device. I'm not seeing whether there's any reason at all for these deployments to switch apis, the fact that someone wants to deprecate a well working api doesn't really count.

Perhaps. But KMS doesn't hurt in these cases, and it would be nice to get to a point where everyone is using one API that can scale across a wide variety of display use cases, vs starting off w/ an overly simple display API and then later realize that you have painted yourself into a corner when you realize you need to do something more advanced.

Obviously it won't be an overnight change.. fbdev won't be removed soon. But the current situation of two display subsystems is not ideal. So it is best to start nudging things towards KMS.

[mlau]

yup.. existing drivers wouldn't be removed any time quickly. The point/suggestion is, that *new* drivers should be written as drm/kms drivers rather than fbdev drivers.

Rob, is there a document available on how to write a KMS driver for dumb framebuffer devices?

(I sort of maintain 2 fb drivers for some fringe MIPS hardware and was pondering a rewrite
of the more advanced one (it's basically a lcd controller which can source up to 4 arbitrarily-sized
windows to compose a final picture, including alpha blending. The DMA controller can even
be used to do bitblits))

[agd5f]

fbdev does not support multi-head. That alone is a major issue.

[agd5f]

Rob, is there a document available on how to write a KMS driver for dumb framebuffer devices?

Documentation written by Laurent covers KMS in general not specific to simple devices vs. complex devices:
http://lwn.net/Articles/499261/

Two simple KMS drivers:
http://lists.freedesktop.org/archive...il/021249.html
http://lists.freedesktop.org/archive...il/021245.html

[mlau]

Documentation written by Laurent covers KMS in general not specific to simple devices vs. complex devices:
http://lwn.net/Articles/499261/

Two simple KMS drivers:
http://lists.freedesktop.org/archive...il/021249.html
http://lists.freedesktop.org/archive...il/021245.html

Thanks. Exactly what I was looking for.