| Message ID | 20240219090239.22568-2-daniel.van.vugt@canonical.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Delegated to: | Helge Deller |
| Headers | show |
| Series | [v4,1/2] dummycon: Add dummycon_(un)register_switch_notifier | expand |
Hi Daniel, On Mon, Feb 19, 2024 at 05:02:34PM +0800, Daniel van Vugt wrote: > Until now, deferred console takeover only meant defer until there is > output. But that risks stepping on the toes of userspace splash screens > as console messages may appear before the splash screen. > > This becomes more likely the later the splash screen starts, but even > systems whose splash exists in initrd may not be not immune because they > still rely on racing against all possible kernel messages that might > trigger the fbcon takeover. And those kernel messages are hardware > dependent so what boots silently on one machine may not be so quiet on > the next. We also want to shield users from seeing warnings about their > hardware/firmware that they don't always have the power to fix themselves, > and may not be deemed worthy of fixing by the vendor. > > So now we check the command line for the expectation of userspace splash > (CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION) and if present > then defer fbcon's takeover until the first console switch. In the case > of Plymouth, its value would typically be "splash". This keeps the boot > experience clean and silent so long as the command line requests so. > > Closes: https://bugs.launchpad.net/bugs/1970069 > Cc: Mario Limonciello <mario.limonciello@amd.com> > Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com> It's not clear to me why we should want to make it an option? If one strategy is better than the other, and I guess the new one is if you consider it fixes a bug and bothered to submit it upstream, why not just get rid of the old one entirely? I guess my question is: why do we want the choice, and what are the tradeoff each strategy brings? Maxime
On 2/22/2024 05:08, Maxime Ripard wrote: > Hi Daniel, > > On Mon, Feb 19, 2024 at 05:02:34PM +0800, Daniel van Vugt wrote: >> Until now, deferred console takeover only meant defer until there is >> output. But that risks stepping on the toes of userspace splash screens >> as console messages may appear before the splash screen. >> >> This becomes more likely the later the splash screen starts, but even >> systems whose splash exists in initrd may not be not immune because they >> still rely on racing against all possible kernel messages that might >> trigger the fbcon takeover. And those kernel messages are hardware >> dependent so what boots silently on one machine may not be so quiet on >> the next. We also want to shield users from seeing warnings about their >> hardware/firmware that they don't always have the power to fix themselves, >> and may not be deemed worthy of fixing by the vendor. >> >> So now we check the command line for the expectation of userspace splash >> (CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION) and if present >> then defer fbcon's takeover until the first console switch. In the case >> of Plymouth, its value would typically be "splash". This keeps the boot >> experience clean and silent so long as the command line requests so. >> >> Closes: https://bugs.launchpad.net/bugs/1970069 >> Cc: Mario Limonciello <mario.limonciello@amd.com> >> Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com> I did test this series on an Ubuntu userspace and it works as you suggest it should. Tested-by: Mario Limonciello <mario.limonciello@amd.com> > > It's not clear to me why we should want to make it an option? If one > strategy is better than the other, and I guess the new one is if you > consider it fixes a bug and bothered to submit it upstream, why not just > get rid of the old one entirely? > > I guess my question is: why do we want the choice, and what are the > tradeoff each strategy brings? > > Maxime The reason for choice is that it keys off a kernel command line parameter that is inconsistent across distributions. For example Ubuntu uses "splash", Fedora used "rhgb" etc. Even the plymouth userspace maintains a list for it's behaviors of what parameters to look for to start at bootup. So the obvious alternative is to clone that list in the kernel.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig index bc31db6ef7..2f9435335f 100644 --- a/drivers/video/console/Kconfig +++ b/drivers/video/console/Kconfig @@ -138,6 +138,18 @@ config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER by the firmware in place, rather then replacing the contents with a black screen as soon as fbcon loads. +config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION + string "Command line parameter to defer takeover to first switch" + depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER + default "" + help + If enabled this defers further the framebuffer console taking over + until the first console switch has occurred. And even then only if + the specified parameter is found on the command line. This ensures + fbcon does not interrupt userspace splash screens such as Plymouth + which may be yet to start rendering at the time of the first console + output. + config STI_CONSOLE bool "STI text console" depends on PARISC && HAS_IOMEM diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 1183e7a871..e5d841ab03 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -76,6 +76,7 @@ #include <linux/crc32.h> /* For counting font checksums */ #include <linux/uaccess.h> #include <asm/irq.h> +#include <asm/cmdline.h> #include "fbcon.h" #include "fb_internal.h" @@ -3348,7 +3349,7 @@ static int fbcon_output_notifier(struct notifier_block *nb, { WARN_CONSOLE_UNLOCKED(); - pr_info("fbcon: Taking over console\n"); + pr_info("fbcon: Taking over console for output\n"); dummycon_unregister_output_notifier(&fbcon_output_nb); @@ -3357,6 +3358,27 @@ static int fbcon_output_notifier(struct notifier_block *nb, return NOTIFY_OK; } + +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION +static int initial_console; +static struct notifier_block fbcon_switch_nb; + +static int fbcon_switch_notifier(struct notifier_block *nb, + unsigned long action, void *data) +{ + struct vc_data *vc = data; + + WARN_CONSOLE_UNLOCKED(); + + if (vc->vc_num != initial_console) { + pr_info("fbcon: Taking over console for switch\n"); + dummycon_unregister_switch_notifier(&fbcon_switch_nb); + schedule_work(&fbcon_deferred_takeover_work); + } + + return NOTIFY_OK; +} +#endif #endif static void fbcon_start(void) @@ -3368,8 +3390,18 @@ static void fbcon_start(void) deferred_takeover = false; if (deferred_takeover) { - fbcon_output_nb.notifier_call = fbcon_output_notifier; - dummycon_register_output_notifier(&fbcon_output_nb); +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION + if (cmdline_find_option_bool(boot_command_line, + CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION)) { + initial_console = fg_console; + fbcon_switch_nb.notifier_call = fbcon_switch_notifier; + dummycon_register_switch_notifier(&fbcon_switch_nb); + } else +#endif + { + fbcon_output_nb.notifier_call = fbcon_output_notifier; + dummycon_register_output_notifier(&fbcon_output_nb); + } return; } #endif @@ -3416,8 +3448,12 @@ void __exit fb_console_exit(void) { #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER console_lock(); - if (deferred_takeover) + if (deferred_takeover) { dummycon_unregister_output_notifier(&fbcon_output_nb); +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION + dummycon_unregister_switch_notifier(&fbcon_switch_nb); +#endif + } console_unlock(); cancel_work_sync(&fbcon_deferred_takeover_work);
Until now, deferred console takeover only meant defer until there is output. But that risks stepping on the toes of userspace splash screens as console messages may appear before the splash screen. This becomes more likely the later the splash screen starts, but even systems whose splash exists in initrd may not be not immune because they still rely on racing against all possible kernel messages that might trigger the fbcon takeover. And those kernel messages are hardware dependent so what boots silently on one machine may not be so quiet on the next. We also want to shield users from seeing warnings about their hardware/firmware that they don't always have the power to fix themselves, and may not be deemed worthy of fixing by the vendor. So now we check the command line for the expectation of userspace splash (CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION) and if present then defer fbcon's takeover until the first console switch. In the case of Plymouth, its value would typically be "splash". This keeps the boot experience clean and silent so long as the command line requests so. Closes: https://bugs.launchpad.net/bugs/1970069 Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com> --- v2: Added Kconfig option instead of hard coding "splash". v3: Default to disabled, not "splash". If enabled then take over on switch rather than on first output after switch. v4: Elaborate more in the commit message about races and Kconfig. Also move these revision comments below the line marker. --- drivers/video/console/Kconfig | 12 +++++++++ drivers/video/fbdev/core/fbcon.c | 44 +++++++++++++++++++++++++++++--- 2 files changed, 52 insertions(+), 4 deletions(-)