I managed to get something working with the frame buffer interface, so success so far! https://github.com/apache/nuttx/pull/17294
Unfortunately, I encountered an issue trying to compile the LVGL demo so it hasn't been much more interesting than some test rectangles so far. https://github.com/apache/nuttx-apps/issues/3208 The frame-buffer driver was actually really simple to get working after looking at Lup's blogs, so thank you for the tip Tomek (and Greg, for the easy-to-implement driver)! I will probably go back and document the bit of the frame buffer lower-half that I understand, since a little bit of developer documentation for how to write a lower-half and what's exactly needed to get running would be useful. There's also no docs for the framebuffer example application, which I plan to fix shortly. It would be good to know what the output should look like so I'm not scratching my head wondering if I got it right or not :) Thanks again everyone for your help so far! One step closer to DOOM on NuttX :) Matteo On Thu, Nov 6, 2025 at 2:37 PM Tomek CEDRO <[email protected]> wrote: > 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 >
