From 12.2 to 13

I did notice a driver called "efifb" that I have never seen before. From DMESG VT: Replacing driver "efifb" with new "fb".
I already had this on 12.2.
What's new to me is the line before: WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
 
There are new options in loader.conf(5), that affect some of these issues.

I fixed the terminal resolution, not by changing the resolution, but by changing the font size. This is a new option in FreeBSD 13.0.

So in loader.conf: screen.font="8x16" will reduce the font size and make it appear the same size as VT 1024x768 font size from FreeBSD 12.2.

The default font size in FreeBSD 13.0 is larger than the default from 12.2, but now we have the option to change it.
 
I just compiled a custom kernel with white on blue, as I always do with a fresh install and it didn't actually change the foreground and background colors.

This is the kernel config file:
Code:
include GENERIC
ident BSDKERNEL

options TERMINAL_NORM_ATTR=(FG_WHITE|BG_BLUE)
options TERMINAL_KERN_ATTR=(FG_YELLOW|BG_BLUE)

Everything compiled and installed like normal, but the actual colors didn't change.
Although both of these options are still documented in vt(4) for FreeBSD 13, they are indeed not working anymore. A message on the freebsd-current mailing list from january suggests that there are now loader tunables to set fore-/background colors, but no mention of those in loader.conf(5).

The VT driver is loaded in loader.conf. I did notice a driver called "efifb" that I have never seen before. From DMESG VT: Replacing driver "efifb" with new "fb".
(vt_)efifb is a framebuffer device driver that accesses the graphics hardware through UEFI's graphics output protocol (GOP) without needing a specialized graphics device driver. Once a KMS driver is loaded (like one provided by graphics/drm-kmod) it replaces efifb.
 
Although both of these options are still documented in vt(4) for FreeBSD 13, they are indeed not working anymore. A message on the freebsd-current mailing list from january suggests that there are now loader tunables to set fore-/background colors, but no mention of those in loader.conf(5).


(vt_)efifb is a framebuffer device driver that accesses the graphics hardware through UEFI's graphics output protocol (GOP) without needing a specialized graphics device driver. Once a KMS driver is loaded (like one provided by graphics/drm-kmod) it replaces efifb.
This explains it. Hopefully the loader tunable options will show up somewhere.
 
The loader tunable options showed up in that message.

Code:
teken.fg_color="7"
teken.bg_color="4"

This will make the background blue and the foreground white [notice that the numbers are not mapped to the same colors as "vidcontrol show" I had to use trial and error {red and blue were swapped}.].
 
This explains it. Hopefully the loader tunable options will show up somewhere.
grep -E "teken\.[fb]g_color" /usr/src/sys/kern/subr_terminal.c
Code:
        TUNABLE_INT_FETCH("teken.fg_color", &fg);
        TUNABLE_INT_FETCH("teken.bg_color", &bg);
There! Feel free to experiment. 🥶
I am still working through my 12.2 -> 13.0 update queue but once I'm through I sure will have a closer look at those.

On a sidenote: Thanks to vt_vbefb I now got a high(er) resolution console with loadable fonts and fast vt switching using a 1996 graphics card *yay*
 
grep -E "teken\.[fb]g_color" /usr/src/sys/kern/subr_terminal.c
Code:
        TUNABLE_INT_FETCH("teken.fg_color", &fg);
        TUNABLE_INT_FETCH("teken.bg_color", &bg);
There! Feel free to experiment. 🥶
I am still working through my 12.2 -> 13.0 update queue but once I'm through I sure will have a closer look at those.

On a sidenote: Thanks to vt_vbefb I now got a high(er) resolution console with loadable fonts and fast vt switching using a 1996 graphics card *yay*
I've noticed a performance boost of about 3-5%, but the most interesting thing about FreeBSD 13.0 is the loader tunable options.

....Oh yeah, these tunable options appear to take effect when the FreeBSD menu appears before booting the kernel. The kernel VT options didn't take effect until the kms driver was loaded, later in the boot process [of 12.2, i'm not sure but I think that syscons was the default console driver before 13, but now it appears to be vt].
 
Code:
teken.fg_color="7"
teken.bg_color="4"
This will make the background blue and the foreground white [notice that the numbers are not mapped to the same colors as "vidcontrol show" I had to use trial and error {red and blue were swapped}.].
The colors are defined in /usr/src/sys/teken/teken.h and seem to correspond to standard ANSI colors:
C:
typedef unsigned char teken_color_t;
#define TC_BLACK        0
#define TC_RED          1
#define TC_GREEN        2
#define TC_BROWN        3
#define TC_BLUE         4
#define TC_MAGENTA      5
#define TC_CYAN         6
#define TC_WHITE        7
#define TC_NCOLORS      8
#define TC_LIGHT        8       /* ORed with the others. */

Looking at the code that handles the tunables it seems that it does not quite provide the flexibility of the previous kernel config options:
C:
        fg = bg = -1;
        TUNABLE_INT_FETCH("teken.fg_color", &fg);
        TUNABLE_INT_FETCH("teken.bg_color", &bg);

        if (fg != -1) {
                default_message.ta_fgcolor = fg;
                kernel_message.ta_fgcolor = fg;
        }
        if (bg != -1) {
                default_message.ta_bgcolor = bg;
                kernel_message.ta_bgcolor = bg;
        }

        if (default_message.ta_bgcolor == TC_WHITE) {
                default_message.ta_bgcolor |= TC_LIGHT;
                kernel_message.ta_bgcolor |= TC_LIGHT;
        }

        if (default_message.ta_bgcolor == TC_BLACK &&
            default_message.ta_fgcolor < TC_NCOLORS)
                kernel_message.ta_fgcolor |= TC_LIGHT;
        teken_set_defattr(&tm->tm_emulator, &default_message);
Using TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR you could set two pairs of fore- and background colors for a total of 4 colors independently. Now you can only set a single fore- and background color, and if the background color happens to be black, then it chooses a lighter version of the foreground color (probably bold) for the kernel messages. My configuration so far has been:
Code:
options         TERMINAL_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK)
options         TERMINAL_KERN_ATTR=(FG_LIGHTBLUE|BG_BLACK)
Which made kernel messages appear in bright blue, whereas normal messages appeared grey. I'm afraid that wont be possible to achieve with the loader tunables anymore.

....Oh yeah, these tunable options appear to take effect when the FreeBSD menu appears before booting the kernel. The kernel VT options didn't take effect until the kms driver was loaded, later in the boot process [of 12.2, i'm not sure but I think that syscons was the default console driver before 13, but now it appears to be vt].
The TERMINAL_(NORM|KERN)_ATTR options worked just the same way in vt(4) as the corresponding SC_KERNEL_CONS_ATTR and SC_NORM_ATTR options in sc(4) did before. They got active as soon as the kernel started booting, but not before that (i.e. in loader). The KMS driver should not have any effect on that and is also loaded much later in the boot process. Some tunable options like kern.vt.fb.default_mode however do only work if a KMS driver is present. Not sure when exactly vt(4) became the default console, but it was the default in 12.2 already and has been around since FreeBSD 9.3:
Code:
HISTORY
     The vt driver first appeared in FreeBSD 9.3.
 
I remember the splash screen would show up, then the screen would go into text mode, then blank out, then go text mode again after the kms driver was loaded.

If I think about it, I guess these attributes were active before the screen blanked out.

These new tunable options make the splashscreen background color whatever the console background color is, the vt kernel options didn't do that, as I recall.
 
I remember the splash screen would show up, then the screen would go into text mode, then blank out, then go text mode again after the kms driver was loaded.
That's when the KMS driver replaces vt_vga/vt_efifb and optionally switches to a higher resolution mode.

These new tunable options make the splashscreen background color whatever the console background color is, the vt kernel options didn't do that, as I recall.
Well, looks like someone thought it would be a good idea to have consistent colors during the transition from loader to kernel. YMMV. I generally dislike such restrictions being imposed on me.
 
Just tested the loader tunables and put this into my /boot/loader.conf:
Code:
teken.fg_color="4"
teken.bg_color="0"
Unfortunately that makes all text blue on black, in loader before the kernel starts booting, as well as the kernel and normal console messages, with the kernel messages just being a lighter shade of blue. Even text on all of the virtual terminals is all blue with this setting. I'm afraid that just doesn't cut it. 💩
 
I would like to modify my logo as well but I would like to see shots of what you are guys are working on. Can you good people post some pictures?
 
I didn't try to modify the logo nor the splash screen yet, I noticed that there are some newer settings that may allow for it, but I haven't looked into it at all so far.

I modified the color scheme and changed the font size with the loader tunables [previously this would have been done with kernel options at compile time].

Code:
screen.font="8x16"
teken.fg_color="7"
teken.bg_color="4"

So this is what it looks like under the previously stated options [white on blue].

These instructions, from Vermaden, reduce the number of kernel messages during the boot process.
 

Attachments

  • DSC00064.JPG
    DSC00064.JPG
    643 KB · Views: 149
  • DSC00065.JPG
    DSC00065.JPG
    647.4 KB · Views: 139
  • DSC00066.JPG
    DSC00066.JPG
    620.5 KB · Views: 149
  • DSC00067.JPG
    DSC00067.JPG
    701.2 KB · Views: 166
If you have a 16:9 display, select a 16:9 mode (with square pixels) for EFI framebuffer. Problem solved.
 
Find a 16:9 mode supported by your UEFI:

The exec shouldn't be necessary, giving the mode to efi_max_resolution should work just as well.

If you have a machine with a 16:9 panel and UEFI only offers 4:3 modes, IMHO FreeBSD ist the wrong place to complain about it. I don't think it would be a good idea to scale the logo assuming non-square pixels.
 
There are new options in loader.conf(5), that affect some of these issues.

I fixed the terminal resolution, not by changing the resolution, but by changing the font size. This is a new option in FreeBSD 13.0.

So in loader.conf: screen.font="8x16" will reduce the font size and make it appear the same size as VT 1024x768 font size from FreeBSD 12.2.

The default font size in FreeBSD 13.0 is larger than the default from 12.2, but now we have the option to change it.
What screen font sizes are available?
 
The thing is still: I don't think it makes sense to just assume non-square pixels (which will result if your panel is 16:9 while your UEFI BIOS only offers modes for 4:3). The complaint about this would be best addressed to the vendor of the hardware/firmware…

On my little notebook with 16:9 display, I found one matching mode in UEFI. Not the native resolution, but at least offering square pixels.
 
Back
Top