I agree Tomek! Tim, I have a similar question. The frame-buffer driver (according to the docs) provides a way for NuttX to bypass the kernel and directly manipulate a frame-buffer. LVGL demos and other apps (like the fb example) appear to be built on top of this frame-buffer driver. However, and my understanding may be flawed, there are other graphics implementations for the NuttX graphics subsystem ( https://nuttx.apache.org/docs/latest/components/nxgraphics/index.html). It looks like the part a developer would implement for their hardware is the NXGLIB bit (?) The API is described here: https://nuttx.apache.org/docs/latest/components/nxgraphics/nxgl.html
Probably for DOOM I will write the implementation to use the frame-buffer driver, since that seems pretty widely supported for NuttX graphics-capable devices. I think it also meshes well with the version of DOOM I plan to use: https://github.com/ozkl/doomgeneric I used this to get DOOM ported to QNX back when I worked there. It has its own RAM framebuffer that it does all the rendering to, and I would just have to copy it to the device framebuffer (which I imagine boils down to a single memcpy). The only problem I see with it is that it's GPL2 licensed. I think that there is probably nobody who will use it in a production NuttX application, more of a hobbyist curiosity, so perhaps that's fine anyways. Otherwise I can try porting fbDOOM directly once I get the proof-of-concept working, which doesn't appear to have a license and is made for framebuffer devices as well. doomgeneric ran decently fast on the Pi 4B back at QNX (I never noticed speed issues) so it probably doesn't need anything fancy to work. Maybe it would benefit from DMA and that's it. Matteo On Sat, Nov 8, 2025 at 1:52 PM Tim Hardisty <[email protected]> wrote: > Dipping in and out here as I’m supposed to be on holiday lol. If the > framebuffer is the low level interface to the hardware (?) what would be > the right NuttX/portable graphics intermediate language? > > Regards, > > Tim. > > > On 8 Nov 2025, at 19:28, Tomek CEDRO <[email protected]> wrote: > > > > We also need to create BAD APPLE on NuttX as our ultimate multimedia > > portability benchmark :D :D > > > > Some examples: > > https://www.youtube.com/watch?v=nNC6aTSKiwk > > https://www.youtube.com/watch?v=MEmF7eNj5U8 > > https://www.youtube.com/watch?v=cd5iEeIe7L0 > > https://www.youtube.com/watch?v=4kdtiOyJgtc > > https://www.youtube.com/watch?v=R6myIbJpUWo > > https://www.youtube.com/shorts/ObM7cnKjjY8 > > https://www.youtube.com/watch?v=B9TrOxXer4E > > https://www.youtube.com/watch?v=xazooShtoTM > > https://www.youtube.com/watch?v=5NXSMdUH_Cg > > https://www.youtube.com/watch?v=i0NjDNyZfbY > > https://www.youtube.com/watch?v=dx76YPgZviE > > > > And many many many more :-) > > https://www.youtube.com/results?search_query=bad+apple+hardware > > > > Tomek > > > >> On Sat, Nov 8, 2025 at 5:16 PM Matteo Golin <[email protected]> > wrote: > >> > >> That's very cool! A wolfenstein engine on NuttX is pretty interesting. I > >> figure having a couple games on NuttX could attract some curiosity from > >> hobbyists, and there's no better choice than games from the era of > clever, > >> low-resource rendering and physics. DOOM has also become somewhat of a > >> "trend" to port to low-resource devices (not the the Pi4B meets that > >> description). I've seen people run it on disposable vapes, microwaves > and > >> even fancy pregnancy tests. > >> > >> Matteo > >> > >>> On Sat, Nov 8, 2025 at 9:16 AM Tim Hardisty <[email protected]> > wrote: > >>> > >>> Or was it a dos emulator; don’t remember! > >>> > >>> > >>>> On 8 Nov 2025, at 15:03, Tim Hardisty <[email protected]> > wrote: > >>>> > >>>> Doom was the first and last “full graphics” I played I think. Doom > >>> feats after hours in the 1990’s maybe? > >>>> > >>>> Bring back Commander Keen lol. > >>>> > >>>> (Yes, have played it some times with Win3 emulators!) > >>>> > >>>> Regards, > >>>> > >>>> Tim. > >>>> > >>>>> On 8 Nov 2025, at 13:20, Gregory Nutt <[email protected]> wrote: > >>>>> > >>>>> * > >>>>> 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 > >>>>>> > >>> > > > > > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
