Announcement

Collapse
No announcement yet.

A Call For Deprecating The Linux Frame-Buffer FBDEV

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • A Call For Deprecating The Linux Frame-Buffer FBDEV

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

    A call was made during the Linux Plumbers Conference on Wednesday to deprecate the Linux kernel FBDEV support...

    http://www.phoronix.com/vr.php?view=MTE3MjI

  • #2
    I think you forgot to tell us why? The other subsystems being more advanced isn't really a reason, IMO.

    Comment


    • #3
      I hope he will propose working alternatives for us unfortunate enough to have computers with poulsbo graphics.

      Comment


      • #4
        Originally posted by Nogotheg View Post
        I hope he will propose working alternatives for us unfortunate enough to have computers with poulsbo graphics.
        Does the gma500_gfx driver not work? From what I know it does.

        Comment


        • #5
          Originally posted by Gusar View Post
          Does the gma500_gfx driver not work? From what I know it does.
          In my case, last time I checked, it worked but couldn't turn off the screen. And that's quite an important thing to have...

          Comment


          • #6
            What is it with these lately... No, the DRM FB emulation is not even close to par to the actual fb drivers. v4l doesn't even attempt to support fbdev api.

            Either might be a better API on its own, but programs aren't going to port themselves. There are these things called "existing usage", "backwards compatiblity", etc etc which all this calls to deprecate something lately seem to not to have heard of.

            Comment


            • #7
              *all these

              Editing still broken...

              Comment


              • #8
                Originally posted by curaga View Post
                There are these things called "existing usage", "backwards compatiblity", etc etc which all this calls to deprecate something lately seem to not to have heard of.
                Deprecating something doesn't break compatibility or existing usage, doesn't mean it will disappear overnight. It simply identifies it as not having a long-term future, advising developers that they should migrate away from it. There's stuff in Java 7 that's been deprecated since 1.0, and likewise, some of the functions removed in Gtk+ 3 had been deprecated for most of the ten-year lifespan of Gtk+ 2...

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    Originally posted by curaga View Post
                    What is it with these lately... No, the DRM FB emulation is not even close to par to the actual fb drivers. v4l doesn't even attempt to support fbdev api.

                    Either might be a better API on its own, but programs aren't going to port themselves. There are these things called "existing usage", "backwards compatiblity", etc etc which all this calls to deprecate something lately seem to not to have heard of.
                    well, i've heard about how they like all that "existing usage" and "backwards compatiblity" stuff in the world of Windows®, and how that makes it a steaming pile of decomposing shit, so thank you, but i would prefer fot this deprecation to start someday and actually happen, or otherwise no change will be made at all.

                    Comment


                    • #11
                      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

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X