Announcement

Collapse
No announcement yet.

A Call To Stop Making FBDEV Linux Frame-Buffer Drivers

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

  • A Call To Stop Making FBDEV Linux Frame-Buffer Drivers

    Phoronix: A Call To Stop Making FBDEV Linux Frame-Buffer Drivers

    Back in 2012 was a call for deprecating Linux FBDEV drivers in a move to try to kill off the FBDEV subsystem in favor of modern DRM drivers. As I've brought up several times since, FBDEV drivers are still kicking in the Linux kernel. Sent out today thought was another call to try to encourage developers to stop developing FBDEV drivers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Before (or instead of) asking FBDEV devs to stop developing I would ask them "why".
    Maybe you can find surprises you wouldn't expect!

    Comment


    • #3
      using DRM to get graphics over a simple chip that is connected over I2C is definitely overkill

      i wish people would ask around before giving their opinion

      Comment


      • #4
        Originally posted by gens View Post
        using DRM to get graphics over a simple chip that is connected over I2C is definitely overkill
        There are several drm drivers for simple single display devices that do not support any sort of acceleration. There is no requirement that the device supports any sort of acceleration and just about all of the code related to acceleration is vendor specific.

        Comment


        • #5
          What about certain ARM platforms? framebuffers are sometimes the only option.

          Comment


          • #6
            Originally posted by schmidtbag View Post
            What about certain ARM platforms? framebuffers are sometimes the only option.
            only because people write fbdev drivers for them instead of a simple drm/kms driver using cma-helpers

            trust me, I've written a drm/kms driver for such a device, replacing a simple fbdev driver. (And gaining DT bindings, support for external encoder chips, etc, etc, at the same time.)

            Comment


            • #7
              How easy is it to make the most simple DRM driver with just a framebuffer pointer and hardcoded width/height and pixelformat?
              ... and then to make an "advanced" driver with configurable width/height, pixelformat and maybe even bufferswap, vsync and DMA fill/copy?

              And how can you easily do a simple application using DRM directly (without X or Wayland)?

              Sometimes it is probably about making it easy for people and showing a path through the complexity.
              Last edited by Veto; 24 September 2015, 01:53 PM. Reason: How to do simple userspace?

              Comment


              • #8
                Originally posted by Veto View Post
                How easy is it to make the most simple DRM driver with just a framebuffer pointer and hardcoded width/height and pixelformat?
                ... and then to make an "advanced" driver with configurable width/height, pixelformat and maybe even bufferswap, vsync and DMA fill/copy?

                And how can you easily do a simple application using DRM directly (without X or Wayland)?
                There are several examples of simple (tilcdc, udl, mgag200, ast) and complex (i915, radeon, amdgpu) drm/kms drivers. Additionally, kms provides an fbdev emulation layer so you can still use things like fbcon that use the fbdev interfaces if you don't want to use kms directly.

                Comment


                • #9
                  Does Linux contain a Vesa DRM driver? No? Then what the phuq are they talking about?

                  Comment


                  • #10
                    Originally posted by birdie View Post
                    Does Linux contain a Vesa DRM driver? No? Then what the phuq are they talking about?
                    perhaps read the original message? "So let's not add any more new fbdev drivers." Seems pretty self explanatory..

                    Comment

                    Working...
                    X