`micro` does not work well with 16bpp framebuffer in `fbterm`

[kneelian]

The default framebuffer set up on a Raspberry Pi with the vc4-kms-v3d overlay boot option is 16bpp, which absolutely breaks fbterm trying to run micro (no editor is displayed and micro apparently seems to fail to load, carriage return is broken causing newlines to fall diagonally and the entire terminal turns useless, basically forcing the user to shut down fbterm to recover usability). This occurs when echo $TERM gives fbterm, but micro works fine when it's set to other values (such as linux or xterm-mono)

[niten94]

I'm not sure which factor causes the issue, but could you please provide the following:

1. Version printed when running micro -version
2. Whole package version printed when running apt list fbterm
3. File created by running stty -a > stty.txt before running Micro
4. File created by micro 2> stderr.txt

Carriage return causing a diagonal effect sounds like Micro crashed and wasn't able to restore the terminal. If Micro did crash, running reset might be enough so that FbTerm doesn't need to be terminated.

I cannot test the OS and I cannot be sure where the package repositories could be accessed, but it probably uses the same fbterm package as Debian.

I had no issues when I tested on a regular Debian system. Specifically, I logged in at the console as a regular user (with access to /dev/fb*), ran fbterm, then ran TERM=fbterm micro.

[kneelian]

1. 2.0.14-11
2. No such thing; apt is a Debian-based tool, Alpine uses apk; in either case, it's built from source from https://github.com/sfzhi/fbterm as there is no package in repo

speed 38400 baud; rows 58; columns 224; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; 
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

4. empty file

It doesn't seem to register most keypresses when it crashes (so no way to run reset unfortunately), except hitting enter just moves the prompt one row down; explicitly using Ctrl-D (or alt-right and killing fbterm from htop) is more or less what seems to be working.

Reconfiguring the framebuffer to be 32bpp eliminates the problem entirely and micro works fine

[niten94]

Sorry, I assumed you were using the Debian-based OS. Are you using Alpine Linux?

I compiled the version of FbTerm that you referenced but I still couldn't reproduce the issue. I tested using an x86 Alpine VM with 16 bpp depth which I checked by running fbset. The repository and the ncurses-terminfo package provide different terminfo entries of fbterm, but Micro worked with both.

hitting enter just moves the prompt one row down; explicitly using Ctrl-D (or alt-right and killing fbterm from htop) is more or less what seems to be working.

Specifically, is the moved part something like a shell prompt with previously ran commands? If Ctrl-d properly returns to the shell that is running in FbTerm, Micro may be continuing to run somehow even though the screen couldn't be loaded.

Does htop work with 16 bpp? Could you try running micro 2> stderr.txt and sending Micro SIGSEGV outside FbTerm to take a stacktrace?

The issue seems really odd in a lot of aspects, so I might not be able to help

[kneelian]

Sorry, I assumed you were using the Debian-based OS. Are you using Alpine Linux?

I thought I specified! My apologies. Yes, Alpine 3.23 on kernel version 6.12.

Specifically, is the moved part something like a shell prompt with previously ran commands?

Just the empty prompt with the PS0 and PS1 bits of the bash prompt.

Does htop work with 16 bpp? Could you try running micro 2> stderr.txt and sending Micro SIGSEGV outside FbTerm to take a stacktrace?

Yeah, that works fine.

stderr.txt

The issue seems really odd in a lot of aspects, so I might not be able to help

It's okay, pulling it into 32bpp mode isn't very difficult (just slightly annoying because of the drivers), so I've just started doing that; I figured I'd open the issue in case someone later down the line encounters it as well in some way.