| View previous topic :: View next topic |
| Author |
Message |
nagmat84
Apprentice
Joined: 27 Mar 2007
Posts: 271
|
 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: 465
Location: Naarm/Melbourne, Australia
|
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3436
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: 5128
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: 3436
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: 5128
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: 3436
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: 5128
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: 273
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 |
|
|
|
Kernel & Hardware
