* Thanks again everyone for your help so far! One step closer to DOOM on NuttX :)
Back in the old days when games were pure software, I enjoyed writing games for NuttX. I have wolfenstein-like engine and an experimental 3D ray-casting engine. These used to run on NuttX. The latter was once a part of the apps/ repository but I removed it when I donated NuttX to Apache (since I didn't intend to donate that [art). But I suppose it is still in the GIT history. UNRELATED: When NuttX was donated, there were a lot of files in the repository that should not have been released and were removed in this way. Many other files with different licenses were present at the time of release and these had to be sanitized, to make them Apache correct (thanks almost entirely to Alin Jerpelea). When we talk about NuttX being Apache 2 copyrighted by the ASF, we really only the git repository from a certain point forward Prior to that, checkouts from the repository are BSD licensed and copyrighted by me. I also used to run the public 2-D Wolfenstein-like screen saver on NuttX. It worked fine mostly out of the box. ________________________________ From: Matteo Golin <[email protected]> Sent: Friday, November 7, 2025 9:31 PM To: [email protected] <[email protected]> Subject: Re: RPI 4B Roadmap 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 >
