| Message ID | 20250225164436.56654-1-arnd@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] dummycon: only build module if there are users | expand |
Hi Arnd Am 25.02.25 um 17:44 schrieb Arnd Bergmann: > From: Arnd Bergmann <arnd@arndb.de> > > Dummycon is used as a fallback conswitchp for vgacon and fbcon > in the VT code, and there are no references to it if all three > are disabled, so just leave it out of the kernel image for > configurations without those. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/video/console/Kconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig > index bc31db6ef7d2..1c4263c164ce 100644 > --- a/drivers/video/console/Kconfig > +++ b/drivers/video/console/Kconfig > @@ -47,8 +47,7 @@ config SGI_NEWPORT_CONSOLE > card of your Indy. Most people say Y here. > > config DUMMY_CONSOLE > - bool > - default y > + def_bool VT || VGA_CONSOLE || FRAMEBUFFER_CONSOLE What about MDA_CONSOLE and STI_CONSOLE. Don't they require this as fallback? Best regards Thomas > > config DUMMY_CONSOLE_COLUMNS > int "Initial number of console screen columns"
Am 26.02.25 um 08:48 schrieb Thomas Zimmermann: > Hi Arnd > > Am 25.02.25 um 17:44 schrieb Arnd Bergmann: >> From: Arnd Bergmann <arnd@arndb.de> >> >> Dummycon is used as a fallback conswitchp for vgacon and fbcon >> in the VT code, and there are no references to it if all three >> are disabled, so just leave it out of the kernel image for >> configurations without those. >> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> >> --- >> drivers/video/console/Kconfig | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/video/console/Kconfig >> b/drivers/video/console/Kconfig >> index bc31db6ef7d2..1c4263c164ce 100644 >> --- a/drivers/video/console/Kconfig >> +++ b/drivers/video/console/Kconfig >> @@ -47,8 +47,7 @@ config SGI_NEWPORT_CONSOLE >> card of your Indy. Most people say Y here. >> config DUMMY_CONSOLE >> - bool >> - default y >> + def_bool VT || VGA_CONSOLE || FRAMEBUFFER_CONSOLE > > What about MDA_CONSOLE and STI_CONSOLE. Don't they require this as > fallback? I did some grepping in the kernel sources and found the answer to this question. It's still surprising that the other consoles don't use dummycon. They are never unloaded, it seems. Best regards Thomas > > Best regards > Thomas > >> config DUMMY_CONSOLE_COLUMNS >> int "Initial number of console screen columns" >
On Wed, Feb 26, 2025, at 08:48, Thomas Zimmermann wrote: > Am 25.02.25 um 17:44 schrieb Arnd Bergmann: >> From: Arnd Bergmann <arnd@arndb.de> >> >> Dummycon is used as a fallback conswitchp for vgacon and fbcon >> in the VT code, and there are no references to it if all three >> are disabled, so just leave it out of the kernel image for >> configurations without those. >> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >> --- >> drivers/video/console/Kconfig | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig >> index bc31db6ef7d2..1c4263c164ce 100644 >> --- a/drivers/video/console/Kconfig >> +++ b/drivers/video/console/Kconfig >> @@ -47,8 +47,7 @@ config SGI_NEWPORT_CONSOLE >> card of your Indy. Most people say Y here. >> >> config DUMMY_CONSOLE >> - bool >> - default y >> + def_bool VT || VGA_CONSOLE || FRAMEBUFFER_CONSOLE > > What about MDA_CONSOLE and STI_CONSOLE. Don't they require this as fallback? > MDA_CONSOLE clearly does not, because that is only the second console when VGA_CONSOLE is the main one. For sti_console, I don't see how it would do use it: when CONFIG_VT is enabled, the line above turns on DUMMY_CONSOLE, but without CONFIG_VT there seems to be no reference to it after 58a5c67aadde ("parisc/sticon: Always register sticon console driver"). I also see that CONFIG_STI_CONSOLE is a 'bool' symbol, so there is no dynamic loading/unloading of the driver. Arnd
Hi Am 26.02.25 um 08:55 schrieb Arnd Bergmann: > On Wed, Feb 26, 2025, at 08:48, Thomas Zimmermann wrote: >> Am 25.02.25 um 17:44 schrieb Arnd Bergmann: >>> From: Arnd Bergmann <arnd@arndb.de> >>> >>> Dummycon is used as a fallback conswitchp for vgacon and fbcon >>> in the VT code, and there are no references to it if all three >>> are disabled, so just leave it out of the kernel image for >>> configurations without those. >>> >>> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >>> --- >>> drivers/video/console/Kconfig | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig >>> index bc31db6ef7d2..1c4263c164ce 100644 >>> --- a/drivers/video/console/Kconfig >>> +++ b/drivers/video/console/Kconfig >>> @@ -47,8 +47,7 @@ config SGI_NEWPORT_CONSOLE >>> card of your Indy. Most people say Y here. >>> >>> config DUMMY_CONSOLE >>> - bool >>> - default y >>> + def_bool VT || VGA_CONSOLE || FRAMEBUFFER_CONSOLE >> What about MDA_CONSOLE and STI_CONSOLE. Don't they require this as fallback? >> > MDA_CONSOLE clearly does not, because that is only the second > console when VGA_CONSOLE is the main one. > > For sti_console, I don't see how it would do use it: when CONFIG_VT > is enabled, the line above turns on DUMMY_CONSOLE, but without > CONFIG_VT there seems to be no reference to it after > 58a5c67aadde ("parisc/sticon: Always register sticon console > driver"). I also see that CONFIG_STI_CONSOLE is a 'bool' symbol, > so there is no dynamic loading/unloading of the driver. Thanks. Here's another general question. vgacon and fbcon only seem usable with CONFIG_VT=y. Wouldn't it make sense to have them depend on CONFIG_VT=y? dummycon could then be implemented as part of the vt code, maybe even become a vt-internal thing. The console code is complex, so I'm probably missing something here? Best regards Thomas > > Arnd
On Wed, Feb 26, 2025, at 09:16, Thomas Zimmermann wrote: > Am 26.02.25 um 08:55 schrieb Arnd Bergmann: > Here's another general question. vgacon and fbcon only seem usable with > CONFIG_VT=y. Wouldn't it make sense to have them depend on CONFIG_VT=y? > dummycon could then be implemented as part of the vt code, maybe even > become a vt-internal thing. The console code is complex, so I'm probably > missing something here? I think in theory one may have a system use fbcon purely to get the boot logo, but not actually support VT. I had also assumed there might be a way to use fbcon as the console (i.e. printk) but not register the tty, but it looks like the console code still requires vt. After I looked at the vt and conswitchp code some more, I wonder if we could go the other way and instead of integrating it more make the conswitchp logic optional: most of the complexity here deals with switching between text console and fbcon dynamically, but having any text console support is getting very rare (vga on alpha/mips/x86-32, newport on mips-ip22, sti on parisc). If we do this, the conswitchp code could be merged with dummycon in drivers/video/console, with the simpler alternative just calling into fbcon functions. I'm not sure if we can already drop vgacon from normal x86-64 distro configs, i.e. if there are cases that are not already covered by any of efi-earlycon, efifb, vga16fb, vesafb/uvesafb or a PCI DRM driver. Arnd
"Arnd Bergmann" <arnd@arndb.de> writes: Hello Arnd, > On Wed, Feb 26, 2025, at 09:16, Thomas Zimmermann wrote: >> Am 26.02.25 um 08:55 schrieb Arnd Bergmann: >> Here's another general question. vgacon and fbcon only seem usable with >> CONFIG_VT=y. Wouldn't it make sense to have them depend on CONFIG_VT=y? >> dummycon could then be implemented as part of the vt code, maybe even >> become a vt-internal thing. The console code is complex, so I'm probably >> missing something here? > > I think in theory one may have a system use fbcon purely to get the > boot logo, but not actually support VT. I had also assumed there might > be a way to use fbcon as the console (i.e. printk) but not register > the tty, but it looks like the console code still requires vt. > > After I looked at the vt and conswitchp code some more, I wonder > if we could go the other way and instead of integrating it more > make the conswitchp logic optional: most of the complexity here > deals with switching between text console and fbcon dynamically, > but having any text console support is getting very rare (vga > on alpha/mips/x86-32, newport on mips-ip22, sti on parisc). > > If we do this, the conswitchp code could be merged with dummycon This sounds like a much better approach indeed. > in drivers/video/console, with the simpler alternative just > calling into fbcon functions. I'm not sure if we can already drop > vgacon from normal x86-64 distro configs, i.e. if there are cases > that are not already covered by any of efi-earlycon, efifb, > vga16fb, vesafb/uvesafb or a PCI DRM driver. > I believe vgacon is still useful for x86 with legacy BIOS, because vesafb (and simpledrm) only works if the user defines a mode using the vga= kernel cmdline parameter. > Arnd >
On Wed, Feb 26, 2025, at 13:05, Javier Martinez Canillas wrote: > "Arnd Bergmann" <arnd@arndb.de> writes: >> in drivers/video/console, with the simpler alternative just >> calling into fbcon functions. I'm not sure if we can already drop >> vgacon from normal x86-64 distro configs, i.e. if there are cases >> that are not already covered by any of efi-earlycon, efifb, >> vga16fb, vesafb/uvesafb or a PCI DRM driver. >> > > I believe vgacon is still useful for x86 with legacy BIOS, because > vesafb (and simpledrm) only works if the user defines a mode using > the vga= kernel cmdline parameter. Right, at the minimum, a configuration without vgacon would have to pick a graphical mode in arch/x86/boot/video*.c if one wasn't already set by grub. Looking through the git history of that code, it seems that there are lots of corner cases with weird 32-bit hardware. Anything from the past 20 years is probably reasonably safe, but there still needs to be a way to configure vgacon back in to be safe. Arnd
On 2/26/25 12:46, Arnd Bergmann wrote: > On Wed, Feb 26, 2025, at 09:16, Thomas Zimmermann wrote: >> Am 26.02.25 um 08:55 schrieb Arnd Bergmann: >> Here's another general question. vgacon and fbcon only seem usable with >> CONFIG_VT=y. Wouldn't it make sense to have them depend on CONFIG_VT=y? >> dummycon could then be implemented as part of the vt code, maybe even >> become a vt-internal thing. The console code is complex, so I'm probably >> missing something here? > > I think in theory one may have a system use fbcon purely to get the > boot logo, but not actually support VT. I had also assumed there might > be a way to use fbcon as the console (i.e. printk) but not register > the tty, but it looks like the console code still requires vt. > > After I looked at the vt and conswitchp code some more, I wonder > if we could go the other way and instead of integrating it more > make the conswitchp logic optional: most of the complexity here > deals with switching between text console and fbcon dynamically, > but having any text console support is getting very rare (vga > on alpha/mips/x86-32, newport on mips-ip22, sti on parisc). Yes, it's rare. But on parisc, if no supported fbdev or drm graphic card is found, it needs to stays on sticon (which always works). Otherwise - if a card was found - the kernel switches dynamically to fbcon. > If we do this, the conswitchp code could be merged with dummycon > in drivers/video/console, with the simpler alternative just > calling into fbcon functions. As mentioned above, that should be optional then. > I'm not sure if we can already drop > vgacon from normal x86-64 distro configs, i.e. if there are cases > that are not already covered by any of efi-earlycon, efifb, > vga16fb, vesafb/uvesafb or a PCI DRM driver. Helge
Hi Am 26.02.25 um 12:46 schrieb Arnd Bergmann: > On Wed, Feb 26, 2025, at 09:16, Thomas Zimmermann wrote: >> Am 26.02.25 um 08:55 schrieb Arnd Bergmann: >> Here's another general question. vgacon and fbcon only seem usable with >> CONFIG_VT=y. Wouldn't it make sense to have them depend on CONFIG_VT=y? >> dummycon could then be implemented as part of the vt code, maybe even >> become a vt-internal thing. The console code is complex, so I'm probably >> missing something here? > I think in theory one may have a system use fbcon purely to get the > boot logo, but not actually support VT. I had also assumed there might > be a way to use fbcon as the console (i.e. printk) but not register > the tty, but it looks like the console code still requires vt. > > After I looked at the vt and conswitchp code some more, I wonder > if we could go the other way and instead of integrating it more > make the conswitchp logic optional: most of the complexity here > deals with switching between text console and fbcon dynamically, > but having any text console support is getting very rare (vga > on alpha/mips/x86-32, newport on mips-ip22, sti on parisc). > > If we do this, the conswitchp code could be merged with dummycon > in drivers/video/console, with the simpler alternative just > calling into fbcon functions. I'm not sure if we can already drop > vgacon from normal x86-64 distro configs, i.e. if there are cases > that are not already covered by any of efi-earlycon, efifb, > vga16fb, vesafb/uvesafb or a PCI DRM driver. Thanks for the lengthy answer. I don't want to add work to your todo list. For vgacon, I wouldn't remove it yet, as there still exisits x86_64 systems with plain VGA support. Best regards Thomas > > Arnd >
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig index bc31db6ef7d2..1c4263c164ce 100644 --- a/drivers/video/console/Kconfig +++ b/drivers/video/console/Kconfig @@ -47,8 +47,7 @@ config SGI_NEWPORT_CONSOLE card of your Indy. Most people say Y here. config DUMMY_CONSOLE - bool - default y + def_bool VT || VGA_CONSOLE || FRAMEBUFFER_CONSOLE config DUMMY_CONSOLE_COLUMNS int "Initial number of console screen columns"