Arch Linux User Repository

I have applied the proposed "configurable color palette" patch. Now the colors may be specified in the configuration file using numbered parameters color-num=RRGGBB.

color-235=212121
color-247=a6a19b
color-background=235
color-foreground=247

I changed my mind. $XDG_CONFIG_HOME/fbterm/fbtermrc is now an allowed configuration location along with the old $XDG_CONFIG_HOME/fbtermrc. Old location is used only when $XDG_CONFIG_HOME/fbterm/ does not exist.

To set a wallpaper in fbterm, you'll need fbv package (framebuffer image viewer). Execute the following instructions right before launching fbterm (works in POSIX-compliant shell like dash):

# hide cursor
echo -ne "\e[?25l"
# display fullscreen-stretched image and quit viewer without screen refreshing
fbv -ciuker "$WALLPAPER_FILE" << EOF
q
EOF
# use current screen state as a wallpaper
export FBTERM_BACKGROUND_IMAGE=1

To enable 256 color mode properly, do export TERM=fbterm-256color AFTER fbterm starts and then attach to a tmux session. If TERM is not linux upon fbterm launch, it will fail. Tmux is needed because fbterm provides escape codes that differ from broadly used codes, so tmux serves as an abstraction layer.

Unlike vanilla fbterm, in this version the configuration file is located at $XDG_CONFIG_HOME/fbtermrc or $HOME/.config/fbtermrc if XDG_CONFIG_HOME is unset or empty (the original placement is $HOME/.fbtermrc). Also, the configuration file is not forcibly recreated anymore. For default configuration, see /etc/fbterm/fbtermrc.example.

This package does not build properly:

make[2]: Nothing to be done for 'install-exec-am'.
tic fbterm
"fbterm", line 2, terminal 'fbterm-256color': /usr/share/terminfo/f: permission denied
make[2]: *** [Makefile:424: install-data-local] Error 1
make[2]: Leaving directory '/home/dk/.cache/paru/clone/fbterm/src/fbterm-1.7/terminfo'
make[1]: *** [Makefile:317: install-am] Error 2
make[1]: Leaving directory '/home/dk/.cache/paru/clone/fbterm/src/fbterm-1.7/terminfo'
make: *** [Makefile:378: install-recursive] Error 1

Why does the it require access to /usr/share/terminfo/f during the build stage?

tic fbterm
"fbterm", line 2, terminal 'fbterm-256color': /usr/share/terminfo/f: permission denied

fbterm/src/fbterm-1.7/terminfo$ cat Makefile.am

EXTRA_DIST = fbterm

install-data-local:
       tic fbterm

PKGBUILD
----
...
  mkdir -p tic
  TERMINFO=$srcdir/$_gitname-$_majorver/tic tic terminfo/fbterm
...

It looks like both the PKGBUILD and the stock Makefile.am in fbterm-1.7/terminfo are running tic on terminfo/fbterm, but running tic from the Makefile, without first resetting the TERMINFO= directory, tic tries to access the filesystem outside of the BUILDDIR directory.

You could run makepkg -o, then edit the toplevel Makefile to remove the "terminfo" subdirctory from the list:

...
SUBDIRS = src im doc
...

and then makepkg -ei. It's not elegant, but it works.

I get a strange error while doin makepkg:

make[2]: Für das Ziel „install-exec-am“ ist nichts zu tun.
tic fbterm
"fbterm", line 2, terminal 'fbterm-256color': /usr/share/terminfo/f: permission denied
make[2]: *** [Makefile:424: install-data-local] Fehler 1
make[2]: Verzeichnis „/tmp/pkgbuild-0/fbterm/src/fbterm-1.7/terminfo“ wird verlassen
make[1]: *** [Makefile:317: install-am] Fehler 2
make[1]: Verzeichnis „/tmp/pkgbuild-0/fbterm/src/fbterm-1.7/terminfo“ wird verlassen
make: *** [Makefile:378: install-recursive] Fehler 1

I read something about that cant install terminfo and recompiled a patched ncurses which should resolv the issue but unfortunately does not.

Any suggestions?

@Neubulae This package has little difference from debian vanilla, the patches do not modify core behavior of fbterm.

does this follow the same procedure as enabling fast scrolling for vanilla fbterm? Edit: The real reason I asked this question is because I am using an AMDGPU on a 2K, 144Hz screen, which, for whatever reason, suffers bad performance. I wonder how do I circumvent this problem. Following the procedure listed on uvesafb page gives me an fbterm -v output of EFI VGA instead of amdgpudrmfb and that gives me a better performance, but that also prevents me from booting into GDM either. I don't actually understand what's going on and I don't know how to proceed further.

https://wiki.archlinux.org/title/Fbterm

I have ressurected the Archwiki "fbterm" page from the dead. There is now a proper place to put all these tiny important bits of information about fbterm in Arch. Things like tips, ticks, differences to upstream introduced by this PKGBUILD patches etc.

Please help us make that a great usefull page.

@ivanp: Could you check that all the very important notes you "pinned" and posted here are there if relevant.

It still needs some updating and editing, reviewed by someone more knowleageble than me. Especially for the delicate intrincacies of patches, terminfo, etc.

Hope this can serve better all of those cli/framebuffer Arch fans. We're a very very tiny minority. So it's not easy to find usefull/correct/updated information on the Big Internet.

For specific, Framebufffer ONLY, things a much better use can be made of the Archwiki. So that the ticks, tips, and modern usage possibilities dont get lost in a giant page listing all the other CLI/TUI apps and tools, that are not framebuffer specific.

Fixed screen_render.cpp, updated fbtermrc.example and manpage.

I just found out there need to be another change in the modified color palette patch, otherwise background image will be covered with color0 (but not sure if missed anything else):

diff --git a/src/screen_render.cpp b/src/screen_render.cpp
index e8f39b8..9fced10 100644
--- a/src/screen_render.cpp
+++ b/src/screen_render.cpp
@@ -78,7 +78,7 @@ void Screen::initFillDraw()

        u32 color = 0;
        Config::instance()->getOption("color-background", color);
-       if (color > 7) color = 0;
+       if (color > NR_COLORS) color = 0;
        bgcolor = color;

        u32 size = mBytesPerLine * ((mRotateType == Rotate0 || mRotateType == Rotate180) ? mHeight : mWidth);

@m040601 All kudos to the guy who has implemented the patch. I just bump pkgrel here :)

About the colors configuration: yes, this is correct. The parameters change the terminal palette, and a user may select two colors of the palette as foreground/background defaults.

```` ivanp7 commented on 2022-01-16 I have applied the proposed "configurable color palette" patch.

It works faboulously. No more horrid default deep blue colors in w3m links
for me :). Fantastic work. Thanks ivanp7 for contiuosly improving this
package.

Now the colors may be specified in the configuration file using numbered parameters color-num=RRGGBB.

color-235=212121 color-247=a6a19b color-background=235 color-foreground=247 ````

This information should be added to the man page and the /etc/fbtermrc.example. Making it crystal clear for the ones of us who aren't so well versed these RGB, terminal things.

To summarize it again (as I read it):

1. You can configure up to 255 colors like this:

color-0=XXYYZZ color-1=XXYYZZ ... color-254=XXYYZZ color-255=XXYYZZ

where XXYYZZ are "RGB" values.

1. Two special variables are:

color-background= color-foreground=

They take a value from 0-255. Of the previously defined color-X variables. Example

color-235=212121 color-247=a6a19b color-background=235 color-foreground=247