| 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: 460
Location: Naarm/Melbourne, Australia
|
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3434
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: 5127
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: 3434
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: 5127
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: 3434
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 |
|
|
|
Kernel & Hardware
