DirectFB2 Aims To Resurrect DirectFB For Embedded Systems

[phoronix]

Phoronix: DirectFB2 Aims To Resurrect DirectFB For Embedded Systems

The DirectFB library had been a popular option for embedded systems in running off the Linux frame-buffer to avoid the full overhead of an X11 server. But a number of years ago DirectFB disappeared and ultimately stopped being maintained. Meanwhile Wayland has been making lots of inroads into mobile/embedded and areas once popular for DirectFB use. But now it turns out DirectFB2 is in development as a fork of the original DirectFB...

https://www.phoronix.com/scan.php?page=news_item&px=DirectFB2-2022

[nickblack]

excellent! ought say kmscon run within it?

[uid313]

Maybe they should just abandon DirectFB, embedded devices can use Wayland.

[cl333r]

Maybe they should just abandon DirectFB, embedded devices can use Wayland.

Are they developing it because Wayland isn't light-weight enough or because there's software depending on DirectFB (or that can't run on Wayland)?

[kpedersen]

Maybe they should just abandon DirectFB, embedded devices can use Wayland.

Obligatory: Wayland is protocol blah, blah, blah.

I don't believe there is yet a Wayland compositor that doesn't need a substantial rendering stack. Many embedded devices are unable to access i.e OpenGL. Consider instead that for some embedded devices, you may well see Wayland compositors *on top* of DirectFB. Just like you see with X11 today. Wayland is simply a layer on top of something like the framebuffer.

Why I don't think DirectFB is maintained very much is because it seems a little unnecessary. It is very easy just to mmap /dev/fb0 and use that. DirectFB does have potential benefits of providing an abstraction (i.e for FreeBSD, DOS, etc). But embedded rarely care about that.

[oiaohm]

Maybe they should just abandon DirectFB, embedded devices can use Wayland.

There is a reason against this.

Are they developing it because Wayland isn't light-weight enough or because there's software depending on DirectFB (or that can't run on Wayland)?

Different usage case. DirectFB is designed as a library not as a protocol. DirectFB is for the usage case of you have 1 application you want it to output graphical to screen and you don't want compositor or anything else running. So single process running. Wayland being protocol is more built for the usage case that you are running multi applications.

I don't believe there is yet a Wayland compositor that doesn't need a substantial rendering stack. Many embedded devices are unable to access i.e OpenGL. Consider instead that for some embedded devices, you may well see Wayland compositors *on top* of DirectFB. Just like you see with X11 today. Wayland is simply a layer on top of something like the framebuffer.

https://gitlab.freedesktop.org/wayland/weston/-/tree/main/libweston/backend-fbdev

kpedersen there have been quite a few different wayland compositors that have been done as light as wayland allows yes sitting on Linux framebuffer with no opengl. So far all of the ones I know doing this have been deprecated. The lack of security of the Linux kernel framebuffer mode is a problem..

Why I don't think DirectFB is maintained very much is because it seems a little unnecessary. It is very easy just to mmap /dev/fb0 and use that. DirectFB does have potential benefits of providing an abstraction (i.e for FreeBSD, DOS, etc). But embedded rarely care about that.

True but you do get vendor provided Linux kernels where /dev/fb0 is missing. Yes android linux kernels that provide KMS/DRI/DRM system are not required to provide Linux kernel framebuffer FBDEV emulation.
https://youtu.be/3n4RIbZuGHo?t=196 yes this is 2019 shows android going on route of deprecating fbdev usage and the presentation you used showing FB usage kpederson is 2020.

So going direct to /dev/fb0 does not always work. DirectFB has started to have a place again as it was extend to support using KMS/DRI/DRM stuff as well a fbdev.

The ability to use vendor built kernels is a big one. Yes prior to 2019 android change its was always likely that you would have kernels that had fbdev with KMS/DRI/DRM support.

Its not only Wayland implementations deprecating the usage of fbdev its android and many others. This is also leading to the issue of using the old fbdev methods is using the least tested path in a lot of cases. So DirectFB2 restarting now makes sense we have a transition. Yes Nvidia deciding to support wayland also means DirectFB2 should also be able to work with Nvidia closed source drivers as well.

The abstraction embedded rarely has cared about but that changed now that fbdev is not promised to be in the vendor provided kernels so not tested by vendor as working.

[coder]

...well, I guess people using that Nintendo 64 Linux port got bored with serial console and decided to throw some pixels on their monitors.