Which framebuffer options need to be selected for console?

[nagmat84]

Which framebuffer options do I need to select in my kernel configuration if I wish to have a text console at native panel resolution as a fallback even if X/Waxland fails for some reason?

I am using UEFI boot with EFI stub and Plymouth boot animation. Fox X/Wayland I am using the i915 DRM driver. However, if (for some reason) X/Waxland fails and I need to fall back to the text console, I still want a "proper" console not the 80 char, 25 line legacy thing. Until now I was under the impression that I have to select CONFIG_FB_SIMPLE in combination with CONFIG_SYSFB_SIMPLEFB for that, but I was recently told that I should disable it. All my kernel configurations essentially look like this

Code: Select all

Device Drivers -->
    Firmware Drivers -->
        [*] Mark VGA/VBE/EFI FB as generic framebuffer                          (CONFIG_SYSFB_SIMPLEFB)
    Graphics Support -->
        <*> Direct Rendering Manager -->                                       (CONFIG_DRM)
                [*] Enable legacy fbdev support for your modesetting driver    (CONFIG_DRM_FBDEV_EMULATION)
                <*> Intel 8xx/9xx/G3x/G4x/HD Graphics                          (CONFIG_DRM_I915)
                < > Simple framebuffer driver                                   (CONFIG_DRM_SIMPLEDRM)
            Frame buffer Devices -->
                <*> Support for frame buffer device drivers -->                 (CONFIG_FB)
                        [ ] EFI-based Framebuffer Support                       (CONFIG_FB_EFI)
                <*> Simple Framebuffer Support                                  (CONFIG_FB_SIMPLE)

After giving it some thought, I believe CONFIG_DRM_FBDEV_EMULATION is all I need for Plymouth and a text console, right? (Besides CONFIG_DRM_I915 of course, or any other graphic card (CONFIG_AMDGPU, CONFIG_NOUVEAU) I have).

Is it safe to deselect CONFIG_FB and CONFIG_FB_SIMPLE and CONFIG_SYSFB_SIMPLEFB? Will there be any regression? The kernel help text says to select it, if unsure. That is why I did it.

[flexibeast]

Refer to the "Framebuffer" page on the wiki.

[dmpogo]

Good question, I tried to setup a framebuffer on three machines - 2 with nvidia cards and one intel GPU and cant'say got nice results. Intel still got stuck at 80x24,
on nvidia machine has a card which cannot support full native resolution of a monitor. Even post and BIOS screen looks flickerry. However once we get to X, X sets lower resolution all right and everything is dandy. I tried to teach framebuffer to set lower resolution for the screen, with no success. And only the second nvidia machine has higher resolution framebuffer on console, but it is quite slow. I need to find time and do a new attempt

[irets]

I'm not sure if this is of any help to you but I have these set.

Code: Select all

$ grep CONFIG_FB /usr/src/linux/.config | grep -v "^#"
CONFIG_FB=y
CONFIG_FB_VESA=y
CONFIG_FB_CORE=y
CONFIG_FB_NOTIFY=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_IOMEM_FOPS=y
CONFIG_FB_IOMEM_HELPERS=y
CONFIG_FB_SYSMEM_HELPERS=y
CONFIG_FB_SYSMEM_HELPERS_DEFERRED=y
CONFIG_FB_TILEBLITTING=y

And then I use Grub to set the preferred console size.

Code: Select all

$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-6.6.58-wired-r1-x86_64 root=UUID=478832c6-257f-4147-8c79-01c22a1c5aef ro vga=0x317 fbcon=nodefer

I've heard using vga=xyz is a deprecated approach but it works for me.
I also prefer a larger text size than some people.

[pietinger]

Which framebuffer options do I need to select in my kernel configuration if I wish to have a text console at native panel resolution as a fallback even if X/Waxland fails for some reason?

I am using UEFI boot with EFI stub and Plymouth boot animation. Fox X/Wayland I am using the i915 DRM driver. However, if (for some reason) X/Waxland fails and I need to fall back to the text console, I still want a "proper" console not the 80 char, 25 line legacy thing. Until now I was under the impression that I have to select CONFIG_FB_SIMPLE in combination with CONFIG_SYSFB_SIMPLEFB for that, but I was recently told that I should disable it. All my kernel configurations essentially look like this

Code: Select all

Device Drivers -->
    Firmware Drivers -->
        [*] Mark VGA/VBE/EFI FB as generic framebuffer                          (CONFIG_SYSFB_SIMPLEFB)
    Graphics Support -->
        <*> Direct Rendering Manager -->                                       (CONFIG_DRM)
                [*] Enable legacy fbdev support for your modesetting driver    (CONFIG_DRM_FBDEV_EMULATION)
                <*> Intel 8xx/9xx/G3x/G4x/HD Graphics                          (CONFIG_DRM_I915)
                < > Simple framebuffer driver                                   (CONFIG_DRM_SIMPLEDRM)
            Frame buffer Devices -->
                <*> Support for frame buffer device drivers -->                 (CONFIG_FB)
                        [ ] EFI-based Framebuffer Support                       (CONFIG_FB_EFI)
                <*> Simple Framebuffer Support                                  (CONFIG_FB_SIMPLE)

After giving it some thought, I believe CONFIG_DRM_FBDEV_EMULATION is all I need for Plymouth and a text console, right? (Besides CONFIG_DRM_I915 of course, or any other graphic card (CONFIG_AMDGPU, CONFIG_NOUVEAU) I have).

Is it safe to deselect CONFIG_FB and CONFIG_FB_SIMPLE and CONFIG_SYSFB_SIMPLEFB? Will there be any regression? The kernel help text says to select it, if unsure. That is why I did it.

We have 3 "simple"-options in the kernel ... two of them cause problems with some machines:
CONFIG_SYSFB_SIMPLEFB and CONFIG_DRM_SIMPLEDRM
Therefore I dont recommed them. (IF you do a configuration from scratch = with the default settings, THEN both are disabled; therefore both are not mentionend in my Wiki article for configuring the kernel).

The third one is usually not needed ... because you need only one of CONFIG_FB_EFI or CONFIG_FB_VESA. So, CONFIG_FB_SIMPLE is only in use if both of them do not work (you can use FB_SIMPLE as "fallback"). See also: https://wiki.gentoo.org/wiki/User:Pieti ... nd_Console

If you want a different size you can set it also in the kernel configuration directly (I need it because I have a 4k monitor and the default font size is too small for me):
https://wiki.gentoo.org/wiki/User:Pieti ... y_routines

[dmpogo]

We have 3 "simple"-options in the kernel ... two of them cause problems with some machines:
CONFIG_SYSFB_SIMPLEFB and CONFIG_DRM_SIMPLEDRM
Therefore I dont recommed them. (IF you do a configuration from scratch = with the default settings, THEN both are disabled; therefore both are not mentionend in my Wiki article for configuring the kernel).

The third one is usually not needed ... because you need only one of CONFIG_FB_EFI or CONFIG_FB_VESA. So, CONFIG_FB_SIMPLE is only in use if both of them do not work (you can use FB_SIMPLE as "fallback"). See also: https://wiki.gentoo.org/wiki/User:Pieti ... nd_Console

If you want a different size you can set it also in the kernel configuration directly (I need it because I have a 4k monitor and the default font size is too small for me):
https://wiki.gentoo.org/wiki/User:Pieti ... y_routines

If I understood wiki correctly, modern GPU's have build-in framebuffers which do not require kernel module and take over when drm is initialized. Indeed my Gen 7 Thinkpad carbon X1
shows

Code: Select all

dmesg | grep fb0
[    0.384655] fbcon: i915drmfb (fb0) is primary device
[    1.241516] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

i915drmfb is not a separate framebuffer module. Only simple and efi framebuffers are enabled in kernel config. I do not know what was used before drm was enable, and
whether simple_fb was needed to switch to i915drmfb later on.

[pietinger]

If I understood wiki correctly, modern GPU's have build-in framebuffers which do not require kernel module and take over when drm is initialized. Indeed my Gen 7 Thinkpad carbon X1
shows [...]

Yes. I guess you have compiled your i915 module statically into the kernel and not as module. The difference is: The kernel initializes all static modules before it has access to its root partition, all modularized modules after that.

If you use an initramfs then the kernel does not mount the root partition, but handover to the init-script of the initramfs (and there is no return to some init-functions of the kernel; init must mount the root partition and starts at last /sbin/init) ... and now the initramfs needs a console until the i915 modules are loaded and initialized later, when NOT using STATIC i915.

[dmpogo]

If I understood wiki correctly, modern GPU's have build-in framebuffers which do not require kernel module and take over when drm is initialized. Indeed my Gen 7 Thinkpad carbon X1
shows [...]

Yes. I guess you have compiled your i915 module statically into the kernel and not as module. The difference is: The kernel initializes all static modules before it has access to its root partition, all modularized modules after that.

If you use an initramfs then the kernel does not mount the root partition, but handover to the init-script of the initramfs (and there is no return to some init-functions of the kernel; init must mount the root partition and starts at last /sbin/init) ... and now the initramfs needs a console until the i915 modules are loaded and initialized later, when NOT using STATIC i915.

Right, so in my situation where indeed i915 is compiled into the kernel and where I do not use initramfs - just straight EFI stub of the kernel binary - then do I understand you correctly, no other framdebuffers such as simple_fb or efi_fb are ever used ? Control goes to i915 as soon as kernel binary is loaded, and it always takes care of the framebuffer ?

[pietinger]

Right, so in my situation where indeed i915 is compiled into the kernel and where I do not use initramfs - just straight EFI stub of the kernel binary - then do I understand you correctly, no other framdebuffers such as simple_fb or efi_fb are ever used ? Control goes to i915 as soon as kernel binary is loaded, and it always takes care of the framebuffer ?

AFAIK no ... (but I can be wrong here ... there where a lot of changes in some major kernel versions) ... AFAIK kernel starts efi_fb (or others) and this handover control to i915 (when available).

[sublogic]

Right, so in my situation where indeed i915 is compiled into the kernel and where I do not use initramfs - just straight EFI stub of the kernel binary - then do I understand you correctly, no other framdebuffers such as simple_fb or efi_fb are ever used ? Control goes to i915 as soon as kernel binary is loaded, and it always takes care of the framebuffer ?

AFAIK no ... (but I can be wrong here ... there where a lot of changes in some major kernel versions) ... AFAIK kernel starts efi_fb (or others) and this handover control to i915 (when available).

I think pietinger is right (or was right two years ago). In this forum post from 2022 I have dmesg fragments with the main video driver modular at first, then built-in. In both cases you can see the final driver taking over from the early console.

I don't remember what kernel version that was, but it was a gentoo-sources on an i686 legacy boot, current as of the date of the post.

[g2user2024]

The interaction of the kernel console settings has aslo mystfied me. By chance these settings eventually produce a usable console (ctrl-alt-f1) on a 4K display, but the first 15 seconds or so of a boot only have a black screen. I have no idea as to which font gets used:

Code: Select all

Kernel hacking --->
    x86 Debugging --->
        [*] Enable verbose x86 bootup info messages
        [*] Early printk
Device Drivers --->
    Graphics support  --->
        Console display driver support  --->
           [*]  VGA text console
               (132) Initial number of console screen columns
               (35) Initial number of console screen rows
           [*]   Framebuffer Console support
           [*]   Framebuffer Console Deferred Takeover
        Frame buffer Devices  --->
           <*> Support for frame buffer device drivers  --->
              [*]   VESA VGA graphics support
              [*]   EFI-based Framebuffer Support
     <*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)  --->
         [*]   Enable legacy fbdev support for your modesetting driver
             (100)   Overallocation of the fbdev buffer
         <*>   Simple framebuffer driver (DRM_SIMPLEDRM)
       <M>   AMD GPU
    Firmware Drivers  --->
       [*] Mark VGA/VBE/EFI FB as generic system framebuffer
Library routines  --->
    [*] Select compiled-in fonts
         [*]   console 10x18 font (not supported by all drivers)
    [*] Sparc console 12x22 font (not supported by all drivers)
    [*] Terminus 16x32 font (not supported by all drivers)

In 6.11.8, it looks like some constraints have been added so that:

Code: Select all

    Simple framebuffer support:  Symbol: FB_SIMPLE [=n]
        Depends on: HAS_IOMEM [=y] && FB [=y] && !DRM_SIMPLEDRM [=y]

From dmesg:

Code: Select all

[    0.161272] Console: colour dummy device 132x35
[    1.040135] fbcon: Taking over console
[    2.561024] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[   21.652618] fbcon: amdgpudrmfb (fb0) is primary device
[   21.817392] amdgpu 0000:03:00.0: [drm] fb0: amdgpudrmfb frame buffer device

So from the previous explanations and frame buffer article on the wiki, the following are needed for the bootup info messages and early printk:

Code: Select all

              [*]   VESA VGA graphics support
              [*]   EFI-based Framebuffer Support

And this not needed and causes the black screen for the first 15 seconds of the boot:

Code: Select all

Device Drivers --->
    Graphics support  --->
       <*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)  --->
           <*>   Simple framebuffer driver (DRM_SIMPLEDRM)

And this could be selected instead:

Code: Select all

Device Drivers --->
    Frame buffer Devices  --->
        <*> Simple framebuffer support (FB_SIMPLE)

Did I read things right?

[pietinger]

Did I read things right?

I think so ... please let me say a few more things:

You have always a dummy console (CONFIG_DUMMY_CONSOLE) ... you can configure here:

Code: Select all

Device Drivers --->
    Graphics support  --->
        Console display driver support  --->
               (132) Initial number of console screen columns
               (35) Initial number of console screen rows

The kernel initializes it very, very soon in the boot process - BEFORE enabling all cores of your CPU (I have an hardened config; my kernel clears the whole memory; this takes 4.2 seconds for 64 GB; you see I am using the default values 80x25):

Code: Select all

[    0.099933] mem auto-init: clearing system memory may take some time...
[    0.099938] software IO TLB: area num 32.
[    4.330661] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1
...
[    4.331676] Console: colour dummy device 80x25
[    4.331678] printk: legacy console [tty0] enabled
...
[    4.374776] smp: Bringing up secondary CPUs ...
[    4.374820] smpboot: x86: Booting SMP configuration:
...
[    4.408944] smp: Brought up 1 node, 32 CPUs
[    4.408944] smpboot: Total of 32 processors activated (191769.00 BogoMIPS)

So from the previous explanations and frame buffer article on the wiki, the following are needed for the bootup info messages and early printk:

Code: Select all

              [*]   VESA VGA graphics support
              [*]   EFI-based Framebuffer Support

In fact, you only need one of the two.

And this could be selected instead:

Code: Select all

Device Drivers --->
    Frame buffer Devices  --->
        <*> Simple framebuffer support (FB_SIMPLE)

Usually not necessary.

And this not needed and causes the black screen for the first 15 seconds of the boot:

Code: Select all

Device Drivers --->
    Graphics support  --->
       <*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)  --->
           <*>   Simple framebuffer driver (DRM_SIMPLEDRM)

Yes, I always recommend to disable it ... and this makes also more problems than it solves - I also always recommend to leave it disabled:

Code: Select all

Device Drivers --->
    Firmware Drivers  --->
       [*] Mark VGA/VBE/EFI FB as generic system framebuffer

Try also to disable this:

Code: Select all

Device Drivers --->
    Graphics support  --->
        Console display driver support  --->
           [*]   Framebuffer Console Deferred Takeover

For my 4k I am using only this option enabled:

Code: Select all

Library routines  --->
    [*] Select compiled-in fonts
    [*] Terminus 16x32 font (not supported by all drivers)

[dmpogo]

Right, so in my situation where indeed i915 is compiled into the kernel and where I do not use initramfs - just straight EFI stub of the kernel binary - then do I understand you correctly, no other framdebuffers such as simple_fb or efi_fb are ever used ? Control goes to i915 as soon as kernel binary is loaded, and it always takes care of the framebuffer ?

AFAIK no ... (but I can be wrong here ... there where a lot of changes in some major kernel versions) ... AFAIK kernel starts efi_fb (or others) and this handover control to i915 (when available).

I think pietinger is right (or was right two years ago). In this forum post from 2022 I have dmesg fragments with the main video driver modular at first, then built-in. In both cases you can see the final driver taking over from the early console.

I don't remember what kernel version that was, but it was a gentoo-sources on an i686 legacy boot, current as of the date of the post.

In my case, the only mention of efifb in dmesg is

Code: Select all

[    0.216575] pci 0000:00:02.0: BAR 2: assigned to efifb

I have a console earlier on

Code: Select all

[    0.096179] Console: colour dummy device 80x25

and then i915 appear taking console over

Code: Select all

[    0.291137] i915 0000:00:02.0: vgaarb: deactivate vga console
[    0.294617] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    0.294669] Loading firmware: i915/kbl_dmc_ver1_04.bin
[    0.295900] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
.......
[    0.336166] i915 0000:00:02.0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it
[    0.336179] i915 0000:00:02.0: [drm] [ENCODER:117:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it
[    0.351536] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
......
[    0.358849] fbcon: i915drmfb (fb0) is primary device

There is no mentioning of other framebuffers between console at 0.09 and i915 at 0.29 except that one single line I mentioned first