[v4,2/2] fbcon: Defer console takeover for splash screens to first switch
Commit Message
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(-)
Comments
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.
@@ -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
@@ -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);