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!!
