5 ms·
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 specific
by revelation 9y ago
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/ https://lwn.net/Articles/653071/
- pjmlp 9y agoRegarding 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.
- floren 9y agoThis 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.
- pjmlp 9y agoI see, yep that way it surely worked. Thanks for jumping in.
- vardump 9y agoCurrent 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.