On Thu, Nov 6, 2025 at 5:53 PM Matteo Golin <[email protected]> wrote: > 1) I am actually familiar with the rpi4-osdev project. In part 5, the > author uses the framebuffer approach for graphics: > https://github.com/babbleberry/rpi4-osdev/tree/master/part5-framebuffer. > This is actually a really simple approach to implement, which is why I > imagine it wouldn't be difficult to integrate with NuttX's frame buffer > method of graphics. The main problem for me is that it's very slow. I want > to figure out how to leverage the actual GPU so that graphics can be faster > and more complex. I have not started looking extensively into that yet, but > was mainly wondering how that approach fits into NuttX's graphics system.
>From the long years on FreeBSD desktop where nvidia is the only vendor providing native high quality GPU drivers it seems good to have "generic" framebuffer driver that will work on any hardware in the first place and then GPU specific drivers with hardware acceleration where available. This allows not only having graphics on anything, but more importantly a fallback when GPU drivers fail / buggy / unavailable. Anything here means not only Xorg (and similar) but also raw console that can launch framebuffer applications or a mouse pointer that can copy-paste in the raw console! :-) Console woks on top of the video framebuffer (i.e. /dev/ttyv0..7), Xorg also works on top of the framebuffer (when launched it goes to place of /dev/ttyv8). This is modular and versatile design that allows text mode console on video display, graphical applications in raw video console, and Xorg or similar. There are two framebuffer drivers on FreeBSD: 1. VESA (old / bios machines): https://man.freebsd.org/cgi/man.cgi?query=vesa. 2. SCFB (new / usefi machines): https://man.freebsd.org/cgi/man.cgi?query=scfb Therer are two console drivers on FreeBSD: 1. SYSCONS/SC (old / bios machines): https://man.freebsd.org/cgi/man.cgi?query=syscons 2. VT (new / uefi machines): https://man.freebsd.org/cgi/man.cgi?query=vt SCFB / VT works also on embedded systems like rPI (over HDMI if that works). It seems work-in-progress but works for years already. The only problem I saw so far is the console colors packed into two bit field (afair) that may need structure changes to get dedicated 8..24 bit bit field to get more colors that will be breaking change thus it may be good to think ahead and use this wider field if we want to do something similar in NuttX :-) Here is newcons / vt wiki: https://wiki.freebsd.org/Newcons Hope this helps a bit or gives some reference point :-) On Linux ~20 years ago it was also possible to draw on raw video framebuffer using DirectFB (now version 2) even with no Xorg, see https://en.wikipedia.org/wiki/DirectFB :-) Current DRM/KMS approach is a moving target and kind of PITA because FreeBSD followed that path to have GPU drivers compatible with Linux for easier porting and this only brings problems because things change constantly and are pain to maintain / use thus I would recommend to avoid this path :-( I guess we care most about this design / approach where we have FrameBuffer that allows drawing directly (i.e. LVGL), having console, or Xorg or similar (there is example Xorg compatible server in NuttX!!) :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
