SYSCONS console driver: garbage characters are printed

D

Deleted member 65953

Guest
On a fresh install of FreeBSD-13.0-RELEASE-amd64.vhd, I changed the default console driver to sc by adding kern.vty=sc to /boot/loader.conf, followed by a reboot. However, the use of sc results in some garbage characters. For example, the screenshot below shows some garbage characters that appear when I run man syscons:

freebsd-man-syscons-garbage.png


How do I solve the problem?

I noticed that garbage characters are not printed when using vt instead of sc. I need to use sc because I am resizing the console using vidcontrol.
 
What are your locale configurations (LANG, LC, all that)? And what is TERM set to? It looks a little bit like the terminal is trying to display unicode characters in an invalid fashion.
 
ralphbsz said:
What are your locale configurations (LANG, LC, all that)? And what is TERM set to? It looks a little bit like the terminal is trying to display unicode characters in an invalid fashion.
Click to expand...
I didn't make any changes to the locale configurations. As mentioned, I have only made one change to a fresh install of FreeBSD-13.0-RELEASE-amd64.vhd; I added kern.vty=sc to /boot/loader.conf.

Code: 
# 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=

Code: 
# echo $TERM
xterm

Code: 
# echo $MM_CHARSET
UTF-8
 
mr123 said:
Code: 
# locale
LANG=C.UTF-8
Click to expand...
syscons(4) doesn't support UTF-8.

Beginning with 13.0 (actually when it was CURRENT, if I'm not mistaken) localization has been set to UTF-8 by login classes method in /etc/login.conf to the default login class.

Edit /etc/login.conf, remove or comment UTF-8 lines
Code: 
default:\
        ...
        :charset=UTF-8:\
        :lang=C.UTF-8:
Also remove the backslash from :umask=022:\, run cap_mkdb /etc/login.conf afterwards. To take effect of the new localization, logged in users must log out and log in.
 
Interesting. I actually now suspect that it is something other than UTF-8, namely the handling of escape sequences. Which would be in some strange intertwined with 8-bit support and UTF-8. Here is one possible explanation.

When you do "man foo", the man program by default outputs the result using only very simple formatting, namely overstriking with control H (backspace). So the parts that are boldfaced are detected by the pager, which is usually some version of less. What less does is this: If it sees a boldfaced piece of text (overstrike in the form t^Hte^Hex^Hex^Ht), it removes the overstrikes, and instead outputs the escape sequence for bold face, which is Esc[1m or Csi1m (where Esc = 0x1B and Csi=0x9B). And this is where the problem MIGHT arise: Depending on the setting of Unicode, character set and 8-bit clean (in the terminal settings, visible in stty), less MIGHT try to use the Csi character, which MIGHT confuse the console.

If you have ample time, you could test it, the following way: Create a file that contains text, in a mix of regular and overstrike. Cat the text to the screen, and it should look normal, no errors, no visible overstrike (no backspaces), but also no bold face. Then run the text through less, and you should see bold text. The question is: At the boundary between regular and bold, will everything look normal?
 
You must log in or register to reply here.
Back
Top