[SOLVED] How-to compute the font size to get a given terminal size with fbterm?

genss · 07-08-2014, 08:20 PM

i think it renders the output itself
not sure
(also it's broken on my setup)

bdw fbterm's "--" option will run whatever is behind it, example "fbterm -- tee text.txt" (also empty file)

Didier Spaier · 07-09-2014, 06:52 AM

Tests made by Diantre (thanks to him) show that in at least one case the display size used by fbterm is not the one I'd have expected from the output of "fbterm --vesa-mode=list", maybe linked to the fact that in that case a frame buffer was used, not the vesa backend. So we'll explore further the suggestion to use fbset, first checking that it gives the same result as "fbterm -v". Hopefully fbset is already shipped in the installer, so that's one less thing to do.

Anyhow, I'm increasingly convinced that fbterm doesn't always work reliably in VESA mode, especially with some old or not fully compliant video cards or drivers, so probably we will end up using it only if a frame buffer is available.

tronayne · 07-09-2014, 07:56 AM

I've done a thing for... well, decades as it happens (and I don't know if it'll help).

If you place something like

Code:

#	set up default columns and lines
COLUMNS=80
LINES=40
export COLUMNS LINES
eval `resize`

you'll get the actual size of the screen you're using as environment variables so the value are available to any running shell. You'd put that somewhere in the start up profile for the installer, perhaps in /etc/profile.d (if it exists in the log in sequence) or perhaps in /etc/profile or even in the root .profile file.

I do the COLUMNS, LINES and EXPORT separately so they're compatible with sh (which doesn't like something like

Code:

export COLUMNS=80

at least on Solaris and I've never changed it for Linux).

When you execute resize with X running you get all the termcap settings plus the screen size and they are exported to the environment for you. You also get the termcap and COLUMNS, ROWS settings on the console.

I dunno if that would be helpful but it seems like it might as the size values would be used by curses/ncurses.

On the other hand, I could be all wet and I'll crawl back into my cave now.

genss · 07-09-2014, 09:20 AM

Quote:

Originally Posted by Didier Spaier

Anyhow, I'm increasingly convinced that fbterm doesn't always work reliably in VESA mode, especially with some old or not fully compliant video cards or drivers, so probably we will end up using it only if a frame buffer is available.

http://tldp.org/HOWTO/Framebuffer-HOWTO/x168.html
"Unfortunately, you can not use vesafb successfully with VESA 1.2 cards."

edit: scratch that, vesa 1.2 cards are some before voodoo 2

phenixia2003 · 07-09-2014, 11:48 AM

Hello,

I looked at the source and fbterm has its own rendering procedure, so there's nothing to get from stdout/stderr. However, I wrote a small (and dirty) patch for fbterm-1.7/src/screen.cpp which prints the width, height, cols and rows in the file /tmp/fbterm.log when you run fbterm -v. This file has the following syntax:

Code:

WIDHT=[[:digit:]]\+
HEIGHT=[[:digit:]]\+
COLS=[[:digit:]]\+
ROWS=[[:digit:]]\+

Note: There will be no /tmp/fbterm.log file when fbterm fails to initialize the video.

Here is the patch:

Code:

--- fbterm.orig/fbterm-1.7/src/screen.cpp       2010-10-06 06:23:08.000000000 +0200
+++ fbterm-1.7/src/screen.cpp   2014-07-09 18:36:00.536560115 +0200
@@ -45,6 +45,8 @@
 
 Screen *Screen::createInstance()
 {
+       remove("/tmp/fbterm.log");
+
        if (!Font::instance() || !FW(1) || !FH(1)) {
                fprintf(stderr, "init font error!\n");
                return 0;
@@ -132,6 +134,14 @@
        };
        printf("[screen] driver: %s, mode: %dx%d-%dbpp, scrolling: %s\n",
                drvId(), mWidth, mHeight, mBitsPerPixel, scrollstr[mScrollType]);
+
+       FILE* pFile;
+       pFile= fopen("/tmp/fbterm.log","w");
+       fprintf(pFile,"WIDTH=%u\n",width());
+       fprintf(pFile,"HEIGHT=%u\n",height());
+       fprintf(pFile,"COLS=%u\n",cols());
+       fprintf(pFile,"ROWS=%u\n",rows());
+       fclose (pFile);
 }

Hope this helps.
--
SeB

Didier Spaier · 07-09-2014, 11:51 AM

Quote:

Originally Posted by genss

http://tldp.org/HOWTO/Framebuffer-HOWTO/x168.html
"Unfortunately, you can not use vesafb successfully with VESA 1.2 cards."

Yes,also stated in the kernel docs and I already mentioned that in post #13.

Quote:

edit: scratch that, vesa 1.2 cards are some before voodoo 2

Some folks still have one of these, so that's something we should consider. Anyhow compliance to vesa 2.0 or newer can be partial. In any case I'll probably completely avoid using the vesa backend of fbterm. We can't expect enhancement in this matter unless someone take over fbterm, that was initially only provided with a frame buffer backend.

Didier Spaier · 07-09-2014, 11:54 AM

@phenixia 2003: Thanks SeB, I'll try your patch.

phenixia2003 · 07-10-2014, 04:30 AM

Hello,

The patch below is a bit better. When running fbterm -v, it writes only one line in /tmp/fbterm.log with the following format :

Code:

WIDTH HEIGHT COLS ROWS

So, this will be easier for you to parse the data. For instance :

Code:

DATA=( $( cat 2>/dev/null /tmp/fbterm.log) )
echo "vesa resolution : ${DATA[0]} x ${DATA[1]}"
echo "text resolution : ${DATA[2]} x ${DATA[3]}"

Here is the patch:

Code:

--- screen.cpp.orig	2014-07-10 11:26:24.335007178 +0200
+++ screen.cpp	2014-07-10 10:41:30.636227413 +0200
@@ -45,6 +45,11 @@
 
 Screen *Screen::createInstance()
 {
+
+	if ( access ("/tmp/fbterm.log",F_OK) == 0) { 
+		remove("/tmp/fbterm.log");
+	}
+
 	if (!Font::instance() || !FW(1) || !FH(1)) {
 		fprintf(stderr, "init font error!\n");
 		return 0;
@@ -132,6 +137,11 @@
 	};
 	printf("[screen] driver: %s, mode: %dx%d-%dbpp, scrolling: %s\n",
 		drvId(), mWidth, mHeight, mBitsPerPixel, scrollstr[mScrollType]);
+
+	FILE* pFile;
+	pFile= fopen("/tmp/fbterm.log","w");
+	fprintf(pFile,"%u %u %u %u\n",width(),height(),cols(),rows());
+	fclose (pFile);	
 }
 
 void Screen::switchVc(bool enter)

--
SeB

phenixia2003 · 07-10-2014, 08:24 AM

Hello,

The 2 patches I sent don't cover the issue stated in the post #5 (I missed it

). To fix that, you can use one of the following :

Patch 1 :

In this case, the file /tmp/fbterm.log is created when running fbterm -v, or when the "font size is too huge". It has the syntax below :

Code:

WITDH HEIGHT COLS ROWS

Here is the patch:

Code:

--- fbterm.orig/fbterm-1.7/src/screen.cpp	2014-07-10 11:26:24.335007178 +0200
+++ fbterm-1.7/src/screen.cpp	2014-07-10 15:23:04.710187000 +0200
@@ -45,6 +45,11 @@
 
 Screen *Screen::createInstance()
 {
+
+	if ( access ("/tmp/fbterm.log",F_OK) == 0) { 
+		remove("/tmp/fbterm.log");
+	}
+
 	if (!Font::instance() || !FW(1) || !FH(1)) {
 		fprintf(stderr, "init font error!\n");
 		return 0;
@@ -82,6 +87,12 @@
 
 	if (!pScreen->mCols || !pScreen->mRows) {
 		fprintf(stderr, "font size is too huge!\n");
+	
+		FILE* pFile;
+		pFile= fopen("/tmp/fbterm.log","w");
+		fprintf(pFile,"%u %u %u %u\n",pScreen->mWidth,pScreen->mHeight,pScreen->mCols,pScreen->mRows);
+		fclose (pFile);	
+
 		delete pScreen;
 		return 0;
 	}
@@ -132,6 +143,11 @@
 	};
 	printf("[screen] driver: %s, mode: %dx%d-%dbpp, scrolling: %s\n",
 		drvId(), mWidth, mHeight, mBitsPerPixel, scrollstr[mScrollType]);
+
+	FILE* pFile;
+	pFile= fopen("/tmp/fbterm.log","w");
+	fprintf(pFile,"%u %u %u %u\n",width(),height(),cols(),rows());
+	fclose (pFile);	
 }
 
 void Screen::switchVc(bool enter)

Patch 2:

In this case, the same data as the patch above are written, but on *stdout*, and *only* when the "font size is too huge". Here it is:

Code:

--- fbterm.orig/fbterm-1.7/src/screen.cpp	2014-07-10 11:26:24.335007178 +0200
+++ fbterm-1.7/src/screen.cpp	2014-07-10 15:25:49.943192287 +0200
@@ -82,6 +82,7 @@
 
 	if (!pScreen->mCols || !pScreen->mRows) {
 		fprintf(stderr, "font size is too huge!\n");
+		fprintf(stdout,"%u %u %u %u\n",pScreen->mWidth,pScreen->mHeight,pScreen->mCols,pScreen->mRows);
 		delete pScreen;
 		return 0;
 	}

--
SeB

Didier Spaier · 07-10-2014, 11:59 AM

Merci Sébastien.

Unfortunately, recent tests show that display resolutions output of "fbterm --vesa-mode=list" are not always usable, e.g. in case the display device doesn't provide all of them: we've found a case where the video card supports up to 1920x1440 according to "fbterm --vesa-mode=list", but the external monitor's highest available resolution is 1366x768.

But it seems that "fbset" instead take in account all the display stack, at least it gives the same results as "fbterm -v" in aforementioned case, be it with or without KMS (for some reason in case of KMS the resolution shown by both methods is 1024x768).

So I think that we will use fbterm only if a frame buffer is available (i.e. /proc /fbterm is not empty) and then use the output of fbset to set the font size (argument of the -s option of fbterm) according to the display size. In that case we'll use a True Type font, else we'll fall back to use a bitmap (not scalable) font.

Anyway thanks for your patch, that I have expanded to display in addition the font size in pixels in font.cpp adding just after line # 212 this code snippet:

Code:

FILE* pFile;
pFile= fopen("/tmp/fbterm.log2","w");
fprintf(pFile,"%dpx %dpx\n", mWidth, mHeight);
fclose (pFile);

Then to display the results:

Code:

DATA=( $( cat 2>/dev/null /tmp/fbterm.log) )
echo "vesa resolution : ${DATA[0]} x ${DATA[1]}"
echo "text resolution : ${DATA[2]} x ${DATA[3]}"
DATA2=( $( cat 2>/dev/null /tmp/fbterm.log2) )
echo "font size : ${DATA2[0]} x ${DATA2[1]}"

As an example if I type "fbterm -s 900 -v " I get:

Code:

~$ ./bof.sh 
vesa resolution : 1680 x 1050
text resolution : 3 x 1
font size : 542px x 1048px

Yes, only 3 glyphs displayed on the screen with this font size...

That will allow to compute the maximum font size that will give at least C columns and L lines knowing the display resolution.

It would be more accurate to use the FreeType API to make this computation (mimicking what fbterm does) but that's beyond my knowledge and the approximation will be good enough for my purpose

PS I have edited this thread's title to state the goal instead of a way to reach it, as we'll eventually use another way than the one initially considered.

Didier Spaier · 07-11-2014, 03:36 PM

So, we now compute the font size to be given as argument of the -s option of FbTerm.

For the curious among readers (if any :-), here is how it's done:

Code:

Upstream="setTrueTypeFonts"
. /usr/lib/setup/SeTlocales
font_name="`cat /tmp/font_name`"
# ATM we use only one font but that can change
# The maximum size that can be displayed differs upon font's
# metrics. This is for my work horse (max resolution 1680x1050)
if [ "$font_name" = "DejaVu Sans Mono" ]; then 
  MaxSize=900 
  WidthMaxRatio=542
  HeightMaxRatio=1048
fi
DisplaySize="`/usr/sbin/fbset|grep "^mode"|grep -o [[:digit:]][[:digit:]][[:digit:]]*`"
DisplayWidth="`echo $DisplaySize|awk '{print $1}'`"
DisplayHeight="`echo $DisplaySize|awk '{print $2}'`"
# We want to get at least  87 lines and 27 colums 
# to properly display dialogs during installation
TargetTermWidth=87 
TargetTermHeight=27 
FontWidth=`echo "$DisplayWidth $TargetTermWidth"|awk '{print int(($1 / $2) + 0.5)}'`
FontHeight=`echo "$DisplayHeight $TargetTermHeight"|awk '{print int(($1 / $2) + 0.5)}'`
SizeWidth=`echo "$FontWidth $MaxSize $WidthMaxRatio"|awk '{print int(($1 *  $2 / $3 ) + 0.5)}'`
SizeHeight=`echo "$FontHeight $MaxSize $HeightMaxRatio"|awk '{print int(($1 * $2 / $3) + 0.5)}'`
# $Size will be  the argument of the -s option of fbterm.
if [ "$SizeWidth" -lt "$SizeHeight" ];then
  Size=$SizeWidth
else
  Size=$SizeHeight
fi
echo "$Size">/tmp/font_size
# What follows is just to check the results while testing. We need to
# compare them with the output of "fbterm -s $Size -n $font_name -v".
FontWidth=`echo "$Size $WidthMaxRatio $MaxSize"|awk '{print int(($1 * $2 / $3) + 0.5)}'`
FontHeight=`echo $Size $HeightMaxRatio $MaxSize|awk '{print int(($1 * $2 / $3) + 0.5)}'`
TermWidth=`echo "$DisplayWidth $FontWidth"|awk '{print int(($1 / $2) + 0.5)}'`
TermHeight=`echo "$DisplayHeight $FontHeight"|awk '{print int(($1 / $2) + 0.5)}'`
echo "[display] ${DisplayWidth}x${DisplayHeight}" >/tmp/display
echo "[target term] size: ${TargetTermWidth}:$TargetTermHeight" >>/tmp/display
echo "Font size = $Size" >>/tmp/display
echo "[font] size: ${FontWidth}:$FontHeight" >>/tmp/display
echo "[term] size: ${TermWidth}:$TermHeight" >> /tmp/display

That seems to work so far, so I mark this thread as [SOLVED].

To folks following the Slint project: new installers including this feature will be provided for testing purposes. Their availability will be announced.

Thanks to all who helped solve this issue.