Kudos Tim! Please consider submitting it to the mainline, it could be very useful for NXBoot and for people willing to have a simple way to display some messages on the screen.
BR, Alan On Wed, Mar 12, 2025 at 12:29 PM Tim Hardisty <timhardist...@gmail.com> wrote: > I went back and tried NXterm: > > * I only got it to work once, then played with some pixel depths and > it broke and I can't get it working again > * When it worked, it suffered exactly the same VT100 ANSI escape > sequence issues that I had seen - and mostly fixed - with my own > app, namely: > o NSH sends 5 VT100 codes (CURSOR_ON, CURSOR_OFF, CLEAREOL, > CLEARLINE, CURSORL(n) and there is no decode support for them in > NXterm or NXGL > o The footprint grew from 500k to 540k for my test build. Not a > big deal perhaps. > o For things like stdio redirection (e.g. from mcuboot) NX > client/server is unnecessary > o just like I found with my app, there are missing newlines in > exactly the same place. Perhaps changes to other NuttX code > since NXGL was written have broken/changed this. My app has > fixed (worked around?) this by calling for a newline when needed. > > On balance, I think my app does have merit as it does now have support > for those five VT100 codes - although I am struggling with the > CURSORL(n) decoding at the moment (also see github issue > https://github.com/apache/nuttx/issues/15933). And works (at least for > me!) and can handle STDIN redirection too. > > Additional VT100 decoding would be useful in the future - for colours > and also to allow full support for the CLE NuttX provides. > > Adding a splashscreen (i.e. boot logo) to this should be relatively > trivial and is something I'd like too - I'll look into it. > > For now, the remaining issue I have to solved is the decoding of the > VT100_CURSORL(n) and once I have that cracked I will submit a PR and we > can discuss it there too. > > On 12/03/2025 13:14, Alan C. Assis wrote: > > Hi Tim, > > > > About your progress with fbcon, just realized you created it as an > > application, do you think it could be part of the kernel (like in Linux) > ? > > > > This way it could be used to print the initialization messages from the > > kernel too. > > > > Sometime ago we discussed the idea of adding a boot logo to NuttX, like > in > > Linux. Maybe fbcon could be a start. > > > > I think the nxterm could work for your purpose, but it will increase the > > final firmware size (in case of NXBoot usage). > > > > BR, > > > > Alan > > > > > > > > On Wed, Mar 12, 2025 at 7:12 AM Tim Hardisty<timhardist...@gmail.com> > > wrote: > > > >> Thanks Greg. I have allowed myself to get carried away I think. > >> > >> * I wanted stdout and stderr to render on a FB to display basic > >> messages during bootloading (MCUboot) > >> * There were FBtext examples but not quite what I wanted > >> * There is LVGLterm - again, not quite what I wanted but food for > thought > >> * NxTerm seemed overkill for my needs. Perhaps I was wrong, but... > >> * I created an "FBcon" app that successfully pipes stdout and stderr > >> to a FB, using NXGL font and font rendering functions and spawns a > >> task/app configured via Kconfig (e.g. mcuboot) > >> * Moved on a step to think "what about stdin...and got bogged down in > >> VT100 as a spawned NSH from my "FBcon" was full of them, which I > >> decoded, but have been suffering anomalies. > >> > >> So... > >> > >> For an FB console proper, I don't want to reinvent the wheel and NxTerm > >> is probably just fine, should I need this. > >> > >> The question now is perhaps better rephrased as: > >> > >> /What is a good, lightweight, and "consistent with NuttX > principles" > >> way to add text rendering to a FB device to allow the rendering of > >> text (e.g. stdout) to it. Is it:/ > >> > >> 1. /Code, based on existing, added to my mcuboot "app" to handle > >> the redirects? In other words, largely what I have written, > >> within my own app, and nothing to do with NuttX or NuttX-apps? > >> / > >> 2. /An example app that does stdin/stdout redirection and spawns a > >> task - a combination of LVGLterm and NXGL functions - as per > >> what I have working (with the stdin stuff removed. I can tidy > it > >> up and submit as a PR > >> / > >> 3. /Perhaps a new FB-based character driver where the write > >> function takes and handles characters and renders as pixels./ > >> 4. /IOCTL to the existing FB-based driver to take text and render > >> it, or some variation on that theme. > >> / > >> 5. /Something else?/ > >> > >> On 12/03/2025 03:16, Gregory Nutt wrote: > >>> NxConsole is a related feature based on an NxTerm. It takes I/O from > >>> /dev/console so provides an NSH shell on a framebuffer. > >>> > >>> There are several screenshots of an NxConsole (running under the NxWM > >>> window manager) here: > >>> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629473&preview=/139629402/140774634/NxWM-ScreenShots.pdf > >>> On 3/11/2025 5:38 PM, Gregory Nutt wrote: > >>>> Sounds like you need an nxterm. An nxterm is the logical counterpart > >>>> to an xterm. You can find it at nutts/grapphics/nxterm. > >>>> > >>>> It supports echoing text in a framebuffer and quite a few VT100 > >>>> keyboard inputs. There are all also lots of example to illustrate > >>>> building and using it. It hasn't been used in a long time so I can't > >>>> guarantee its current state. > >>>> > >>>> There is a lot of discussion in Confluence as well. This is probably > >>>> to the point: > >>>> https://cwiki.apache.org/confluence/display/NUTTX/NxTerm+Example > >>>> > >>>>
