Generic FBDEV Emulation Proposed For DRM Drivers

[phoronix]

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?page=news_item&px=Generic-FBDEV-Emulation-DRM

[King InuYasha]

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.

[starshipeleven]

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.

[Delgarde]

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...

[starshipeleven]

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.

[timofonic]

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

[starshipeleven]

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.