| View previous topic :: View next topic |
| Author |
Message |
nagmat84
Apprentice
Joined: 27 Mar 2007
Posts: 272
|
 Posted: Tue Nov 19, 2024 9:50 pm Post subject: Which framebuffer options need to be selected for console? |
 |
|
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: | 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. |
|
| Back to top |
|
 |
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 471
Location: Naarm/Melbourne, Australia
|
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3439
Location: Canada
|
| Posted: Wed Nov 20, 2024 5:08 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
irets
Apprentice
Joined: 17 Dec 2019
Posts: 229
|
| Posted: Wed Nov 20, 2024 11:47 am Post subject: |
|
|
I'm not sure if this is of any help to you but I have these set.
| Code: | $ 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: | $ 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. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5148
Location: Bavaria
|
| Posted: Wed Nov 20, 2024 5:58 pm Post subject: |
|
|
| nagmat84 wrote: | 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: | 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:Pietinger/Experimental/Manual_Configuring_Current_Kernel#Framebuffer_Device_and_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:Pietinger/Experimental/Manual_Configuring_Current_Kernel#Library_routines
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3439
Location: Canada
|
| Posted: Thu Nov 21, 2024 8:26 pm Post subject: |
|
|
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: |
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. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5148
Location: Bavaria
|
| Posted: Thu Nov 21, 2024 10:50 pm Post subject: |
|
|
| dmpogo wrote: | 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.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3439
Location: Canada
|
| Posted: Fri Nov 22, 2024 4:26 am Post subject: |
|
|
| pietinger wrote: | | dmpogo wrote: | 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 ? |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5148
Location: Bavaria
|
| Posted: Fri Nov 22, 2024 12:40 pm Post subject: |
|
|
| dmpogo wrote: | | 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).
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 275
Location: Pennsylvania, USA
|
| Posted: Sat Nov 23, 2024 4:53 am Post subject: |
|
|
| pietinger wrote: | | dmpogo wrote: | | 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. |
|
| Back to top |
|
|
g2user2024
n00b
Joined: 19 Nov 2024
Posts: 4
|
| Posted: Sat Nov 23, 2024 6:15 am Post subject: |
|
|
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: | 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: | Simple framebuffer support: Symbol: FB_SIMPLE [=n]
Depends on: HAS_IOMEM [=y] && FB [=y] && !DRM_SIMPLEDRM [=y]
|
From dmesg: | Code: | [ 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: | [*] 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: | 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: | Device Drivers --->
Frame buffer Devices --->
<*> Simple framebuffer support (FB_SIMPLE) |
Did I read things right? |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5148
Location: Bavaria
|
| Posted: Sat Nov 23, 2024 9:09 am Post subject: |
|
|
| g2user2024 wrote: | | 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: | 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: | [ 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) |
| g2user2024 wrote: | 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: | [*] VESA VGA graphics support
[*] EFI-based Framebuffer Support |
|
In fact, you only need one of the two.
| g2user2024 wrote: | And this could be selected instead: | Code: | Device Drivers --->
Frame buffer Devices --->
<*> Simple framebuffer support (FB_SIMPLE) |
|
Usually not necessary.
| g2user2024 wrote: | And this not needed and causes the black screen for the first 15 seconds of the boot: | Code: | 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: | Device Drivers --->
Firmware Drivers --->
[*] Mark VGA/VBE/EFI FB as generic system framebuffer |
Try also to disable this:
| Code: | Device Drivers --->
Graphics support --->
Console display driver support --->
[*] Framebuffer Console Deferred Takeover |
For my 4k I am using only this option enabled:
| Code: | Library routines --->
[*] Select compiled-in fonts
[*] Terminus 16x32 font (not supported by all drivers) |
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3439
Location: Canada
|
| Posted: Sat Nov 23, 2024 11:43 am Post subject: |
|
|
| sublogic wrote: | | pietinger wrote: | | dmpogo wrote: | | 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: |
[ 0.216575] pci 0000:00:02.0: BAR 2: assigned to efifb
|
I have a console earlier on
| Code: |
[ 0.096179] Console: colour dummy device 80x25
|
and then i915 appear taking console over
| Code: |
[ 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 |
|
| Back to top |
|
|
|
Kernel & Hardware
