My current thinking is that I am being naive/showing inexperience of consoles. I suspect that the newline is handled via the console to both send the command to the host (i.e. NuttX) *and* move to a "physical" newline on the display.

So I am looking to monitor keyboard input and look for the '\n', but yesterday got bogged down in pipes and dup and dup2 lol.

For the FB LCD to actually behave as a console I think it needs to handle stdin as well as stdout. If this is right I will probably add a Kconfig choice to either use this app as a simple stdout device, or a full blown console...much like nxterm but without the need of the nx server etc.

On 08/03/2025 16:50, Alan C. Assis wrote:
Hi Tim,
Could you please try to run: "ls -l | hexdump"

It could show if the '\n' is received correctly.

BR,

Alan

On Fri, Mar 7, 2025 at 3:47 PM Tim Hardisty <timhardist...@gmail.com> wrote:

I am writing a Framebuffer console app that takes stdout and stderr and
renders the text to a framebuffer device. Based on existing NXGL code
and example apps.

It spawns NSH, and I get the NSH prompt on my LCD - and it basically
works. I have also added functions to decode the handful of VT100 codes
that the nsh app sends, such as cursor on/off, clear to eol etc.

But I am stumped by an apparent lack of a newline being sent to stdout
when, for example, you simply hit ENTER on the keyboard; or do a
directory listing (ls - l) followed by ENTER. With no newline being sent
at the start of the output, the first line of text sits at the end of
the current line until there's a '/n' within the stream.

I must be missing something, perhaps relating to how the VT100 escape
codes should be interpreted or some other console "rule" I haven’t
managed to find anywhere.

Has anyone got any suggestions - it's driving me crazy!!


Reply via email to