Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 24

Thread: A Call For Deprecating The Linux Frame-Buffer FBDEV

  1. #11
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by pq__ View Post
    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

  2. #12
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,272

    Default

    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.

  3. #13
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by curaga View Post
    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.

  4. #14
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,272

    Default

    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.

  5. #15
    Join Date
    Jul 2009
    Posts
    286

    Default

    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.

  6. #16
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by curaga View Post
    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

    Quote Originally Posted by curaga View Post
    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.

  7. #17
    Join Date
    Sep 2006
    Posts
    214

    Default

    Quote Originally Posted by robclark View Post
    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))

  8. #18
    Join Date
    Dec 2007
    Posts
    2,402

    Default

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

  9. #19
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    Quote Originally Posted by mlau View Post
    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

  10. #20
    Join Date
    Sep 2006
    Posts
    214

    Default

    Quote Originally Posted by agd5f View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •