Announcement

Collapse
No announcement yet.

Generic FBDEV Emulation Proposed For DRM Drivers

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

  • Generic FBDEV Emulation Proposed For DRM Drivers

    Phoronix: Generic FBDEV Emulation Proposed For DRM Drivers

    DRM subsystem contributor Noralf Trønnes is proposing a patch-set to provide generic FBDEV emulation support in DRM drivers via exportable dumb buffers...

    http://www.phoronix.com/scan.php?pag...-Emulation-DRM

  • #2
    This patch series makes me very happy, as it means that we could have a single codepath in the kernel to support the whole stack. And if merged, future drivers that need to offer an framebuffer interface would get one for free through KMS, which also means that future Android and other embedded drivers would Just Work(TM) with regular Linux graphics stack, too.

    Comment


    • #3
      FBDEV should be killed, not maintaned into 21st century


      Its been almost 40 years of framebuffers, why the fuck we want them on modern GPU/Devices?

      Comment


      • #4
        Originally posted by Uramekus View Post
        FBDEV should be killed, not maintaned into 21st century


        Its been almost 40 years of framebuffers, why the fuck we want them on modern GPU/Devices?
        Embedded devices mostly. Framebuffer drivers are very easy to write and for many embedded devices are still adequate.

        Comment


        • #5
          Originally posted by starshipeleven View Post
          Embedded devices mostly. Framebuffer drivers are very easy to write and for many embedded devices are still adequate.
          Yeah, but there's not a lot of overlap here... any embedded device with DRM-capable hardware is not going to be running a framebuffer interfaces, because you wouldn't put such hardware in a device and not use it... and conversely, any embedded device that does benefit from a framebuffer driver isn't going to be using FB-emulation on a DRM driver...

          Comment


          • #6
            Originally posted by Delgarde View Post
            Yeah, but there's not a lot of overlap here... any embedded device with DRM-capable hardware is not going to be running a framebuffer interfaces, because you wouldn't put such hardware in a device and not use it... and conversely, any embedded device that does benefit from a framebuffer driver isn't going to be using FB-emulation on a DRM driver...
            Well, no. A lot of embedded applications were designed with framebuffer in mind (again its simpler than targeting DRI interfaces) and lack support for more advanced interfaces. Which is why DRI drivers still provide framebuffer emulation in the first place. This patch is just moving the driver-specific code into a generic implementation, it's not adding anything new.

            So yeah, there are embedded that have DRM-capable hardware but are run with framebuffer. Because hardware is cheap, software development is not.

            Also because DRI drivers/interfaces in embedded may very well have more bugs than something simpler like framebuffer, which again mean more time and cost to develop your application. If you don't REALLY need more than framebuffer, you don't use it.

            Comment


            • #7
              Originally posted by starshipeleven View Post
              Well, no. A lot of embedded applications were designed with framebuffer in mind (again its simpler than targeting DRI interfaces) and lack support for more advanced interfaces. Which is why DRI drivers still provide framebuffer emulation in the first place. This patch is just moving the driver-specific code into a generic implementation, it's not adding anything new.

              So yeah, there are embedded that have DRM-capable hardware but are run with framebuffer. Because hardware is cheap, software development is not.

              Also because DRI drivers/interfaces in embedded may very well have more bugs than something simpler like framebuffer, which again mean more time and cost to develop your application. If you don't REALLY need more than framebuffer, you don't use it.
              I just don't understand why switch from FBDEV to KMS is so difficult these days, really...

              I dream with a world where FBDEV doesn't exist and everyone uses Wayland & KMS

              Comment


              • #8
                Originally posted by timofonic View Post
                I just don't understand why switch from FBDEV to KMS is so difficult these days, really...
                Because, as I said, there are a ton of applications that don't need anything more than a framebuffer, as they run fullscreen in a device with an embedded (well-known) screen. Wayland is irrelevant if you only run ONE application fullscreen.

                And software development costs money. So the cheapest option usually wins.

                Comment

                Working...
                X