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.

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

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 can't correctly set background and foreground colours using escape sequences. fg and bg does change. But weechat reverts back to default black and white. It seems tput does the same if asked to reset to defaults, it sets black and white as default instead of what I had set earlier.

So is there a way to change default background and foreground color such that if I tell tput to reset colors, the colors I originally set (not black and white) is restored ? Just like terminal?

Edit: How can I change default Foreground and Background colour?

Edit: This may be important. https://github.com/OliverLew/dotfiles/issues/2

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.

@m040601

Wow, you've written a lot, dude. I'll answer point by point.

1.

Although if I might suggest, the best would even be setting the default to:
~/.config/fbterm/fbtermrc
instead of:
~/.config/fbtermrc

I cannot change the configuration location one more time. While it is viable to check several places, I am not sure whether complicating the path by adding a directory is really useful for a program which uses a single configuration file. Also, I believe .config is not a good place for such things you said. Personally, I'd like to separate configuration and other stuff.

2.

Notice that I dont do "export TERM=fbterm-256color". I simply do "export TERM=fbterm" If I choose the 256color version it messes everything.

It is strange, because the termcap file for TERM=fbterm is from ncurses package, while the termcap for TERM=fbterm-256color is built with fbterm. I don't know why it messes everything in your case, I experience no problems with this.

3.

I personally use fbterm like this. I alias fbterm to $MY_BIN_DIR/fbterm-pre.sh. The "pre" script sets wallpaper and starts fbterm with a custom command:

exec fbterm -n "$DEFAULT_FONT_NAME" -s "$DEFAULT_FONT_SIZE" -- "$MY_BIN_DIR/fbterm-post.sh" "$1"

The "post" script does export TERM=fbterm-256color and then tmux attach.

With this configuration, I just type fbterm and bam, I'm in a fancy tmux session with all colors and font characters. When I detach from the session, fbterm also quits.

4.

The only thing I cant manage to work is changing the color pallete.

The palette is hardcoded in fbterm, there is no way to change the colors without developing another patch. To implement palette customization correctly, it is easier to create a fork, because if I go an obvious way, there will be 256 additional environment variables.