# How to solve local terminal output mess for btop (bpytop formerly) resource monitoring tool ?



## Sergei_Shablovsky (Jun 30, 2022)

After changing screen resolution to more night (640x480 text -> 1600x1200 graphics), output from btop app (formerly bpytop on-screen real-time monitoring tool) look like mess (see attached screen photos).

The same behavior for current btop app and for previous version - bpytop.
Only one exception: btop not start (display *ERROR: No UTF-8 locale detected*) automatically, and able to start only with key —utf-force that ignore UTF compability locale detection.

[UPDATE]
*Other monitoring utility “gotop” have the same behavior: mess on a local-attached screen (ttyv0).*

How to fix this ? May be directly pointing on specific UTF-8 font in /boot/loader. conf.local ?

btop on GitHub - https://github.com/aristocratos/btop

Let’s bring You attention to next from app description:

#####################
Linux, Mac Os X and FreeBSD​For correct display, a terminal with support for:


24-bit truecolor (See list of terminals with truecolor support)
256-color terminals are supported through 24-bit to 256-color conversion when setting "truecolor" to False in the options or with "-lc/--low-color" argument.
Wide characters (Are sometimes problematic in web-based terminals)
Also needs a UTF8 locale and a font that covers:


Unicode Block “Braille Patterns” U+2800 - U+28FF
Unicode Block “Geometric Shapes” U+25A0 - U+25FF
Unicode Block "Box Drawing" and "Block Elements" U+2500 - U+259F
Notice (Text rendering issues)​If you are having problems with the characters in the graphs not looking like they do in the screenshots, it's likely a problem with your systems configured fallback font not having support for braille characters.

See Terminess Powerline for an example of a font that includes the braille symbols.

See comments by @sgleizes link and @XenHat linkin issue #100 for possible solutions.

If text are misaligned and you are using Konsole or Yakuake, turning off "Bi-Directional text rendering" is a possible fix.

Characters clipping in to each other or text/border misalignments is not bugs caused by bpytop, but most likely a fontconfig or terminal problem where the braille characters making up the graphs aren't rendered correctly. Look to the creators of the terminal emulator you use to fix these issues if the previous mentioned fixes don't work for you.

##########

Right now I have
In /boot/loader.conf.local
...
mga_load="YES"
kern.vty=sc
kern.vt.fb.default_mode=“1600x1200”
vbe_max_resolution="1600x1200"
...

And I make corrections in /etc/login.conf to enable UTF-8 systemwide (based on this tread https://forums.freebsd.org/threads/system-wide-utf-8.54388/):

defaults:\
        :charset=UTF-8:\
        :lang=en_US.UTF-8:\
        :setenv=LC_COLLATE=C:\
         :umask=022:

If this corrections in /etc/login.conf not enough may be better to make how described in this https://www.b1c1l1.com/blog/2011/05/09/using-utf-8-unicode-on-freebsd/ article ?


----------



## T-Daemon (Jun 30, 2022)

Sergei_Shablovsky said:


> ERROR: No UTF-8 locale detected
> ...
> How to fix this ? May be directly pointing on specific UTF-8 font in /boot/loader. conf.local ?
> ...
> ...



syscons(4), sc(4) doesn't support UTF-8 encoding, vt(4) does. See Newcons wiki syscons(4) Comparison.



Sergei_Shablovsky said:


> If you are having problems with the characters in the graphs not looking like they do in the screenshots, it's likely a problem with your systems configured fallback font not having support for braille characters.
> 
> See Terminess Powerline for an example of a font that includes the braille symbols.


Those fonts are true type fonts ( TTF ), they can't be used in sc(4).

Try vidfont(1), maybe one the fonts in /usr/share/syscons/fonts works with sysutils/btop. If a font works satisfactory it can be set in /etc/rc.conf ( see " System console options" in /etc/defaults/rc.conf ).

Or you could try converting those Terminess Powerline fonts into .fnt.


----------



## Sergei_Shablovsky (Jun 30, 2022)

T-Daemon said:


> syscons(4), sc(4) doesn't support UTF-8 encoding, vt(4) does


Thank You for help!

Sad to read this,- because looks like for my Matrox G200e chip, that integrated in iRMC, sc(4) is only solution to make hi-resolution on local screen...
please see last page here -
Post in thread 'Change resolution to 1600x1200 on integrated Matrox MGA G200e in D2939 Fujitsu motherboard'
https://forums.freebsd.org/threads/...n-d2939-fujitsu-motherboard.82686/post-573218

Also FreeBSD promised that sc(4) in v.14+ would be deprecated? Or I miss something?


----------



## Sergei_Shablovsky (Jun 30, 2022)

T-Daemon said:


> Try vidfont(1), maybe one the fonts in /usr/share/syscons/fonts works with sysutils/btop. If a font works satisfactory it can be set in /etc/rc.conf ( see " System console options" in /etc/defaults/rc.conf ).


Please explain a little bit more (I have small experience in setting fonts linked to console).
Thank You so much !


----------



## T-Daemon (Jun 30, 2022)

Execute in the console vidfont(1), that will open a dialog(1) from which a font can be chosen. The chosen font takes immediate effect, run sysutils/btop to see if it's displayed correct. 

If one of the fonts works well with sysutils/btop set in /etc/rc.conf using the `allscreens_flags` variable (it sets vidcontrol(1) options), e.g., for setting font iso-8x16.fnt from /usr/share/syscons/fonts:

```
allscreens_flags="-f iso-8x16"
```


----------



## Sergei_Shablovsky (Jun 30, 2022)

T-Daemon said:


> Try vidfont(1),


I trying to play with vidfont(1) to choosing different fonts with “UTF-8” in name:
- the issue still exist;
- the characters changing according selected font;

If I need to try each other fonts?


----------



## Sergei_Shablovsky (Jun 30, 2022)

T-Daemon said:


> Or you could try converting those Terminess Powerline fonts into .fnt.


Please suggest me great tool for properly and error free converting. Thank You!


----------



## T-Daemon (Jun 30, 2022)

Earlier I only glanced at the prerequisites of sysutils/btop, the importend point I didn't pay attention then (sorry, should have read all the text thoroughly), which is:


Sergei_Shablovsky said:


> Also needs a UTF8 locale and a font that covers:
> 
> 
> Unicode Block “Braille Patterns” U+2800 - U+28FF
> ...



And sysutils/gotop:


> Console Users
> 
> gotop requires a font that has braille and block character Unicode code points; some distributions do not provide this. ...



Since syscons(4), sc(4) doesn't support (unicode) UTF-8 encoding, no font or locale will help here. Those two application can't be used in sc(4).


----------



## Sergei_Shablovsky (Jun 30, 2022)

T-Daemon said:


> Since syscons(4), sc(4) doesn't support (unicode) UTF-8 encoding, no font or locale will help here. Those two application can't be used in sc(4).


Thank You for help!

Developer of btop/bpytop confirm:


> Btop prints out ANSI escape sequences for formatting and coloring and relies on UTF-8 encoded fonts to display the correct symbols. If your terminal (or terminal emulator) of choice doesn't support either of those two requirements, it's simply not gonna work as intended.



So, I need to step back and try to pushing my Matrox G200e [PILOT] embedded in iRMC working with vt.

Do You have some thoughts how to doing this?


----------



## yuripv79 (Jun 30, 2022)

1. First of all, which release are you running that you had to modify /etc/login.conf?
2. Check that the changes you made were really applied running `locale` command.
3. What is the mga module?
4. Why do you need to force the sc?

P.S. I tried running btop in console, and all of the fonts available through `vidfont` give me nicely working program, you don't have to add news ones.


----------



## Sergei_Shablovsky (Jul 1, 2022)

dsdqmhsx said:


> 1. First of all, which release are you running that you had to modify /etc/login.conf?


Thank You for help!
FreeBSD 12.3-STABLE


dsdqmhsx said:


> 2. Check that the changes you made were really applied running `locale` command.


Already doing, each time after modifying
/boot/login.conf
/boot/login.conf.local

Right now locale output are:

LANG=en_US.UTF-8
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=


dsdqmhsx said:


> 3. What is the mga module?


mga.ko - for Matrox-based graphics card, also includes Matrox G200/G200e.

More on this please read Page2-3 in this thread and this page above (where I confirm that there are no visual difference between vesa.ko and mga.ko loaded by “YES” directive).



dsdqmhsx said:


> 4. Why do you need to force the sc?


Because all my previous efforts with vt() fail and more experienced users on this forum suggest to using sc() with corrections in /boot/device.hints.
(also see my post above)



dsdqmhsx said:


> P.S. I tried running btop in console, and all of the fonts available through `vidfont` give me nicely working program, you don't have to add news ones.


Which ver FreeBSD You use ?
Which directives for vt() You use in loader.conf and loader.conf.local ?
Please give “locale” output here.


----------



## yuripv79 (Jul 1, 2022)

Sergei_Shablovsky said:


> Already doing, each time after modifying
> /boot/login.conf
> /boot/login.conf.local


I guess /boot/ here is a typo, and you meant /etc/.


Sergei_Shablovsky said:


> LANG=en_US.UTF-8
> LC_CTYPE="C"
> LC_COLLATE="C"
> LC_TIME="C"
> ...


That's not going to work, LC_* variables override LANG, find where you set them to C and remove.


Sergei_Shablovsky said:


> More on this please read Page2-3 in this thread and this page above (where I confirm that there are no visual difference between vesa.ko and mga.ko loaded by “YES” directive).


Not sure I follow, you probably mean your other thread; could you please provide the TL;DR version -- looks like you can't change resolution with vt in BIOS mode?


Sergei_Shablovsky said:


> Which ver FreeBSD You use ?
> Which directives for vt() You use in loader.conf and loader.conf.local ?
> Please give “locale” output here.


For me it's always -CURRENT, no directives for vt (also using UEFI boot so resolution is not a problem), and:

$ locale
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_TIME="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=


----------



## Sergei_Shablovsky (Jul 1, 2022)

dsdqmhsx said:


> I guess /boot/ here is a typo, and you meant /etc/.


Sorry, I check double twice: both files in /boot/ on my system.


dsdqmhsx said:


> That's not going to work, LC_* variables override LANG, find where you set them to C and remove.


I try...



dsdqmhsx said:


> Not sure I follow, you probably mean your other thread; could you please provide the TL;DR version -- looks like you can't change resolution with vt in BIOS mode?


Sorry, my mistake. I mean this https://forums.freebsd.org/threads/...mga-g200e-in-d2939-fujitsu-motherboard.82686/ thread.

Because issue involving both resolution changes and enabling UTF-8 for bpytop/btop, I just make this mess...


dsdqmhsx said:


> For me it's always -CURRENT, no directives for vt (also using UEFI boot so resolution is not a problem), and:
> 
> $ locale
> LANG=C.UTF-8
> ...



Please, describe a little bit more where I need to make changes to properly enabling UTF-8 ?
Like in this https://www.b1c1l1.com/blog/2011/05/09/using-utf-8-unicode-on-freebsd/ article ?

Thank You!

P.S. This rack server are BIOS, non UEFI.


----------



## yuripv79 (Jul 1, 2022)

Sergei_Shablovsky said:


> Sorry, I check double twice: both files in /boot/ on my system.


Are you confusing /boot/loader.conf and /etc/login.conf?  The latter is used to set the locale properly.


Sergei_Shablovsky said:


> Please, describe a little bit more where I need to make changes to properly enabling UTF-8 ?


Remove all changes in /etc/login.conf that you did previously and update the *default* capability so it would look like the following at the end -- this is how it's done in 13.x by default:

```
default:\
...
        :umask=022:\
        :charset=UTF-8:\
        :lang=C.UTF-8:
```
Run `cap_mkdb /etc/login.conf`, log out, log in, check the `locale` output.


Sergei_Shablovsky said:


> Because issue involving both resolution changes and enabling UTF-8 for bpytop/btop, I just make this mess...


btop seem to require a minimal window size of 80x24 (in characters), that should be the default resolution with vt.  Reading that thread you seem to mention that you need a resolution *less* than 1600x1200, so the default one with vt should do?


----------



## Sergei_Shablovsky (Jul 1, 2022)

dsdqmhsx said:


> Are you confusing /boot/loader.conf and /etc/login.conf?  The latter is used to set the locale properly.
> 
> Remove all changes in /etc/login.conf that you did previously and update the *default* capability so it would look like the following at the end -- this is how it's done in 13.x by default:
> 
> ...


As I note in first message in this thread, already done:
——
And I make corrections in /etc/login.conf to enable UTF-8 systemwide (based on this tread https://forums.freebsd.org/threads/system-wide-utf-8.54388/):

defaults:\
:charset=UTF-8:\
:lang=en_US.UTF-8:\
:setenv=LC_COLLATE=C:\
:umask=022:
——-


dsdqmhsx said:


> btop seem to require a minimal window size of 80x24 (in characters), that should be the default resolution with vt.  Reading that thread you seem to mention that you need a resolution *less* than 1600x1200, so the default one with vt should do?


If I understand You correctly, Yes, due ability iRMC controller to capturing video output (may be buffer size, etc...), *resolution must be 1600x1200 or less.*


----------



## Sergei_Shablovsky (Jul 1, 2022)

dsdqmhsx said:


> Are you confusing /boot/loader.conf and /etc/login.conf?  The latter is used to set the locale properly.


My misstyping, Of course /etc/login.conf


----------



## yuripv79 (Jul 1, 2022)

Sergei_Shablovsky said:


> As I note in first message in this thread, already done:


Not really, please pay attention to the details as they do matter 

The post you have linked (as well as my post) suggests to modify *default* login class by adding needed definitions to it, while you have *defaults* class in your paste with just those definitions, so unless you explicitly modified your user to be in *defaults* class the changes you made do nothing.  Also, you don't really need to override LC_COLLATE to plain C, just use C.UTF-8 locale.


----------



## Sergei_Shablovsky (Jul 3, 2022)

dsdqmhsx said:


> Not really, please pay attention to the details as they do matter


My mistake, sorry.
Now   :lang=C.UTF-8:\

One question: why You using   :lang=C.UTF-8: instead   :lang=en_US.UTF-8: ?


----------



## Sergei_Shablovsky (Jul 3, 2022)

dsdqmhsx said:


> That's not going to work, LC_* variables override LANG, find where you set them to C and remove.


I am a little bit disappointed, I not set to “C” by myself (may be system defaults) in which files am I seek for this?

Thank You again one time!


----------



## Sergei_Shablovsky (Jul 3, 2022)

dsdqmhsx said:


> looks like you can't change resolution with vt in BIOS mode?


On moment now - You are right: 
with sc and flags for sc -> resolution possible set to desired 1600x1200
with vt -> I do not know how to change resolution to desired 1600x1200

But I hope it would be possible: when chipset able to work at 1600x1200 in sc(), why the same not possible with vt()?


----------



## yuripv79 (Jul 3, 2022)

Sergei_Shablovsky said:


> My mistake, sorry.


I meant that "default" and "default*s*" are two different classes, the former is well defined and is used, well, by default; the latter does nothing unless you explicitly assigned your login to that class.  Please make sure that you are modifying the *default* entry and not *defaults*.


Sergei_Shablovsky said:


> One question: why You using :lang=C.UTF-8: instead :lang=en_US.UTF-8: ?


It's the same old C locale, hence I do not have to override LC_COLLATE (and, likely, LC_NUMERIC) back to C as was done in your case, with the added benefit of UTF-8 charset.


----------



## T-Daemon (Jul 3, 2022)

Sergei_Shablovsky said:


> when chipset able to work at 1600x1200 in sc(), why the same not possible with vt()?


You where able to set the resolution in sc(4) with vidcontrol(1) [... mode]. vt(4) does not support that feature (maybe in the future).

The Matrox 200e doesn't support VBE framebuffer mode either (VT(vbefb:), which would allow to set a higher screen resolution. The solution I see here to get a higher resolution for sysutils/btop and sysutils/gotop is to install Xorg (which you want to avoid), or add a dedicated graphics card to get VBE framebuffer support.

I have an old nVIDIA GPU (GT 630, rebranded GeForce GT 430 DDR3 from 2012) supporting  vbefb, where I can change resolution in vt(4), beginning with FreeBSD 13.0. Version 12.3 doesn't include the vt vbefb driver.


----------



## Sergei_Shablovsky (Jul 4, 2022)

T-Daemon said:


> You where able to set the resolution in sc(4) with vidcontrol(1) [... mode].


As I previously wrote, I successfully set this internal iRMC Matrox chip to 1600x1200 by directive in /boot/loader.conf and /boot/loader.conf.local, and /boot/device.hints


T-Daemon said:


> vt(4) does not support that feature (maybe in the future).





T-Daemon said:


> The Matrox 200e doesn't support VBE framebuffer mode either (VT(vbefb:), which would allow to set a higher screen resolution.


You mean ability working vt() with vidcontrol() OR ability vt() to set higher resolution exactly in this *integrated Matrox G200e in iRMC* ?
(Please see other my thread here on forum about this)



T-Daemon said:


> The solution I see here to get a higher resolution for sysutils/btop and sysutils/gotop is to install Xorg (which you want to avoid), or add a dedicated graphics card to get VBE framebuffer support.


No in option because this is specialized network router (so any additional software is highly not recommended) and *all slots are filled by NICs*.



T-Daemon said:


> I have an old nVIDIA GPU (GT 630, rebranded GeForce GT 430 DDR3 from 2012) supporting  vbefb, where I can change resolution in vt(4), beginning with FreeBSD 13.0. Version 12.3 doesn't include the vt vbefb driver.


Are You completely sure that my *integrated G200e in iRMC* not able to support vbefb ?
(Official Fujitsu server support are really horrible... not answering on mails, just “ok we create ticket 123456 blah-blah-blah”, I try to receive answer several times within 1 year...)

Is this ability depend on *FreeBSD driver or hardware realization* ?

Thank You!


----------



## Sergei_Shablovsky (Jul 4, 2022)

dsdqmhsx said:


> I meant that "default" and "default*s*" are two different classes, the former is well defined and is used, well, by default; the latter does nothing unless you explicitly assigned your login to that class.  Please make sure that you are modifying the *default* entry and not *defaults*.


Just check: *default*. 

Thank You for help!


----------



## T-Daemon (Jul 5, 2022)

Sergei_Shablovsky said:


> As I previously wrote, I successfully set this internal iRMC Matrox chip to 1600x1200 by directive in /boot/loader.conf and /boot/loader.conf.local, and /boot/device.hints


Not sure which setting  manipulates the screen resolution in your configuration files on your system. Maybe vesa.ko and `hint.sc.0.vesa_mode="285"`? (The vesa driver is integrated in the GENERIC kernel, it doesn't need to be loaded as module.)

Or loading the mga.ko module?



Sergei_Shablovsky said:


> You mean ability working vt() with vidcontrol() OR ability vt() to set higher resolution exactly in this *integrated Matrox G200e in iRMC* ?


I mean the support of vidcontrol(1) [... mode] in vt(4).



Sergei_Shablovsky said:


> Are You completely sure that my *integrated G200e in iRMC* not able to support vbefb ?


The output of `dmesg | grep VT` from your Thread change-resolution-to-1600x1200-on-integrated-matrox-mga-g200e-in-d2939-fujitsu-motherboard.82686/post-540450 suggests vbefb is not supported.

Athough it's not clear if the command is executed on a 12.3 or 13.x system. When executed on 12.3 it won't show vbefb support. VT VBE framebuffer device support is only available starting with 13.0. 12.x kernel series can't support vbefb.

Check booting a 13.1-RELEASE installer image (without installing). At the "Welcome" dialog drop to "Shell" or "Live CD" and execute `dmesg | grep 'VT('`.

If VBE framebuffer device is supported the output should look similar to following (this is what is printed on my system):

```
VT(vga): resolution 640x480
VT(vbefb): resolution 1920x1080
```

If by any chance the line `VT(vbefb):` appears, set in /boot/loader.conf (or /boot/loader.conf.local)  `screen.textmode=0` or `vbe_max_resolution="1600x1200"` (for details see loader.conf(5)).


----------



## Sergei_Shablovsky (Jul 6, 2022)

In other thread
Phishfry wrote​
The Matrox driver is real old and meant for AGP Cards. So you will probably end up like this guy.
It does look like there was a drm driver at one time. mgadrm
DriDrivers - FreeBSD Wiki

What do s You think about this, is possible to use mgadrm.ko ?


----------



## Sergei_Shablovsky (Jul 6, 2022)

T-Daemon said:


> Athough it's not clear if the command is executed on a 12.3 or 13.x system. When executed on 12.3 it won't show vbefb support. VT VBE framebuffer device support is only available starting with 13.0. 12.x kernel series can't support vbefb.


Sad, but this is our headpain: FW/Router now based on 12.3 and only may be later this year would be possible upgrade to 13.0 (or 13.1, not sure, all of this depend on fw/router software developer).



T-Daemon said:


> Check booting a 13.1-RELEASE installer image (without installing). At the "Welcome" dialog drop to "Shell" or "Live CD" and execute `dmesg | grep 'VT('`.





T-Daemon said:


> If VBE framebuffer device is supported the output should look similar to following (this is what is printed on my system):
> 
> ```
> VT(vga): resolution 640x480
> ...


VT(vga): resolution 640x480


----------



## Sergei_Shablovsky (Jul 6, 2022)

T-Daemon said:


> Not sure which setting manipulates the screen resolution in your configuration files on your system. Maybe vesa.ko and `hint.sc.0.vesa_mode="285"`? (The vesa driver is integrated in the GENERIC kernel, it doesn't need to be loaded as module.)
> 
> Or loading the mga.ko module?


Recently I try to hw restart only with vesa.ko (with mga.ko commented out): surprisingly result are the same,- only hint.sc.0.vesa_mode=“285” able to change screen resolution to 1600x1200.

So, looks like system access to card by *kernel*, not mga.ko... But I not sure because luck of knowledge...

Again one time THANK YOU SO MUCH for help!


----------

