What's the new interface to the framebuffer? As someone who's actually used /dev/fb (on Android devices), it's pretty damn easy, which makes it a great baseline for getting some graphics on the screen.

The first thing, certainly on Android, is to forget the idea that there is one framebuffer ;)

The current interface is DRM (drivers/gpu/drm) and there specifically, atomic modesetting:

https://lwn.net/Articles/653071/

Current GPU implementations often support multiple arbitrary "framebuffers" layered on top of each other. Similar to hardware sprites from 8/16-bit era or like more recent hardware "mouse cursor". With the exception they can cover whole screen.

So you can have multiple framebuffers in the same time with arbitrary color formats (like 8-bit grayscale, 16/32-bit (A)RGB, YUV2, etc.). Bilinear scaling, alpha-blending and mirroring/90/180/270 degree rotations are often supported as well.

It's important to understand these framebuffers are not composited anywhere else, but are actually scanned to the display device in real time, on the fly.

Traditional framebuffer can of course be emulated by setting a single layer to cover full screen without alpha-blending.

Regarding Android I am surprised it even worked, unless OP has rooted their device or was using an old version.

Starting with Android N, Google has been locking down what is possible to do via the NDK and apps can no longer directly read outside their own sandboxed filesystem, so no /dev.

This was back in 2011. We modified the init script to stop the zygote process from launching, then used our own C code running as a normal Linux process to work with /dev/fb. So yeah it was rooted and it was an old version, but we were mostly outside of the Android ecosystem entirely.

I see, yep that way it surely worked. Thanks for jumping in.

Sometimes the legacy interfaces are the ones that are most likely to be present

For a single screen embedded application it might be more than enough and you don't need to load a WM, etc