[PATCH 1/2] dummycon: Add dummycon_(un)register_switch_notifier

[PATCH 1/2] dummycon: Add dummycon_(un)register_switch_notifier

[Daniel van Vugt]

To detect switch attempts before a real console exists. This will be
used for the same purpose as dummycon_(un)register_output_notifier,
for fbcon to detect a more polite time to take over.

Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
---
 drivers/video/console/dummycon.c | 35 +++++++++++++++++++++++++++-----
 include/linux/console.h          |  2 ++
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 14af5d9e13..55e9b600ce 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -83,6 +83,32 @@ static int dummycon_blank(struct vc_data *vc, int blank, int mode_switch)
 	/* Redraw, so that we get putc(s) for output done while blanked */
 	return 1;
 }
+
+/* This is protected by the console_lock */
+static RAW_NOTIFIER_HEAD(dummycon_switch_nh);
+
+void dummycon_register_switch_notifier(struct notifier_block *nb)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_chain_register(&dummycon_switch_nh, nb);
+}
+
+void dummycon_unregister_switch_notifier(struct notifier_block *nb)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_chain_unregister(&dummycon_switch_nh, nb);
+}
+
+static int dummycon_switch(struct vc_data *vc)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_call_chain(&dummycon_switch_nh, 0, vc);
+
+	return 0;
+}
 #else
 static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos) { }
 static void dummycon_putcs(struct vc_data *vc, const unsigned short *s,
@@ -91,6 +117,10 @@ static int dummycon_blank(struct vc_data *vc, int blank, int mode_switch)
 {
 	return 0;
 }
+static int dummycon_switch(struct vc_data *vc)
+{
+	return 0;
+}
 #endif
 
 static const char *dummycon_startup(void)
@@ -120,11 +150,6 @@ static bool dummycon_scroll(struct vc_data *vc, unsigned int top,
 	return false;
 }
 
-static int dummycon_switch(struct vc_data *vc)
-{
-	return 0;
-}
-
 /*
  *  The console `switch' structure for the dummy console
  *
diff --git a/include/linux/console.h b/include/linux/console.h
index 779d388af8..8fd70ae623 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -531,5 +531,7 @@ extern void console_init(void);
 /* For deferred console takeover */
 void dummycon_register_output_notifier(struct notifier_block *nb);
 void dummycon_unregister_output_notifier(struct notifier_block *nb);
+void dummycon_register_switch_notifier(struct notifier_block *nb);
+void dummycon_unregister_switch_notifier(struct notifier_block *nb);
 
 #endif /* _LINUX_CONSOLE_H */
-- 
2.43.0

[PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

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. So check for the
"splash" parameter (as used by Plymouth) and if present then extend the
deferral until the first switch.

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>
---
 drivers/video/fbdev/core/fbcon.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 63af6ab034..5b9f7635f7 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"
@@ -146,6 +147,7 @@ static inline void fbcon_map_override(void)
 
 #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
 static bool deferred_takeover = true;
+static int initial_console = -1;
 #else
 #define deferred_takeover false
 #endif
@@ -3341,7 +3343,7 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
 	console_unlock();
 }
 
-static struct notifier_block fbcon_output_nb;
+static struct notifier_block fbcon_output_nb, fbcon_switch_nb;
 static DECLARE_WORK(fbcon_deferred_takeover_work, fbcon_register_existing_fbs);
 
 static int fbcon_output_notifier(struct notifier_block *nb,
@@ -3358,6 +3360,21 @@ static int fbcon_output_notifier(struct notifier_block *nb,
 
 	return NOTIFY_OK;
 }
+
+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) {
+		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
+		dummycon_register_output_notifier(&fbcon_output_nb);
+	}
+
+	return NOTIFY_OK;
+}
 #endif
 
 static void fbcon_start(void)
@@ -3370,7 +3387,14 @@ static void fbcon_start(void)
 
 	if (deferred_takeover) {
 		fbcon_output_nb.notifier_call = fbcon_output_notifier;
-		dummycon_register_output_notifier(&fbcon_output_nb);
+		fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
+		initial_console = fg_console;
+
+		if (cmdline_find_option_bool(boot_command_line, "splash"))
+			dummycon_register_switch_notifier(&fbcon_switch_nb);
+		else
+			dummycon_register_output_notifier(&fbcon_output_nb);
+
 		return;
 	}
 #endif
@@ -3417,8 +3441,10 @@ 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);
+		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
+	}
 	console_unlock();
 
 	cancel_work_sync(&fbcon_deferred_takeover_work);
-- 
2.43.0

Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch

[Mario Limonciello]

On 2/2/2024 02:53, 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. So check for the
> "splash" parameter (as used by Plymouth) and if present then extend the
> deferral until the first switch.
> 
> 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>
> ---
>   drivers/video/fbdev/core/fbcon.c | 32 +++++++++++++++++++++++++++++---
>   1 file changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 63af6ab034..5b9f7635f7 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"
> @@ -146,6 +147,7 @@ static inline void fbcon_map_override(void)
>   
>   #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>   static bool deferred_takeover = true;
> +static int initial_console = -1;
>   #else
>   #define deferred_takeover false
>   #endif
> @@ -3341,7 +3343,7 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>   	console_unlock();
>   }
>   
> -static struct notifier_block fbcon_output_nb;
> +static struct notifier_block fbcon_output_nb, fbcon_switch_nb;
>   static DECLARE_WORK(fbcon_deferred_takeover_work, fbcon_register_existing_fbs);
>   
>   static int fbcon_output_notifier(struct notifier_block *nb,
> @@ -3358,6 +3360,21 @@ static int fbcon_output_notifier(struct notifier_block *nb,
>   
>   	return NOTIFY_OK;
>   }
> +
> +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) {
> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
> +		dummycon_register_output_notifier(&fbcon_output_nb);
> +	}
> +
> +	return NOTIFY_OK;
> +}
>   #endif
>   
>   static void fbcon_start(void)
> @@ -3370,7 +3387,14 @@ static void fbcon_start(void)
>   
>   	if (deferred_takeover) {
>   		fbcon_output_nb.notifier_call = fbcon_output_notifier;
> -		dummycon_register_output_notifier(&fbcon_output_nb);
> +		fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
> +		initial_console = fg_console;
> +
> +		if (cmdline_find_option_bool(boot_command_line, "splash"))
> +			dummycon_register_switch_notifier(&fbcon_switch_nb);

So there is a problem here that this would only apply if the distro 
happened to use "splash" which some distros use something different.

I looked at the matching plymouth code [1] and they have a bunch of 
variations of what they accept and what it does.

[1] 
https://gitlab.freedesktop.org/plymouth/plymouth/-/blob/main/src/main.c?ref_type=heads#L888

If from the kernel side we're going to have code that caters to the 
userspace behavior of plymouth we probably need to match all those cases 
they do too.

Another alternative could be to make it a kernel configuration option 
for which string to look for to activate this behavior.

> +		else
> +			dummycon_register_output_notifier(&fbcon_output_nb);
> +
>   		return;
>   	}
>   #endif
> @@ -3417,8 +3441,10 @@ 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);
> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
> +	}
>   	console_unlock();
>   
>   	cancel_work_sync(&fbcon_deferred_takeover_work);

[PATCH v2 1/2] dummycon: Add dummycon_(un)register_switch_notifier

[Daniel van Vugt]

To detect switch attempts before a real console exists. This will be
used for the same purpose as dummycon_(un)register_output_notifier,
for fbcon to detect a more polite time to take over.

Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
---
 drivers/video/console/dummycon.c | 35 +++++++++++++++++++++++++++-----
 include/linux/console.h          |  2 ++
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 14af5d9e13..55e9b600ce 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -83,6 +83,32 @@ static int dummycon_blank(struct vc_data *vc, int blank, int mode_switch)
 	/* Redraw, so that we get putc(s) for output done while blanked */
 	return 1;
 }
+
+/* This is protected by the console_lock */
+static RAW_NOTIFIER_HEAD(dummycon_switch_nh);
+
+void dummycon_register_switch_notifier(struct notifier_block *nb)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_chain_register(&dummycon_switch_nh, nb);
+}
+
+void dummycon_unregister_switch_notifier(struct notifier_block *nb)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_chain_unregister(&dummycon_switch_nh, nb);
+}
+
+static int dummycon_switch(struct vc_data *vc)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_call_chain(&dummycon_switch_nh, 0, vc);
+
+	return 0;
+}
 #else
 static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos) { }
 static void dummycon_putcs(struct vc_data *vc, const unsigned short *s,
@@ -91,6 +117,10 @@ static int dummycon_blank(struct vc_data *vc, int blank, int mode_switch)
 {
 	return 0;
 }
+static int dummycon_switch(struct vc_data *vc)
+{
+	return 0;
+}
 #endif
 
 static const char *dummycon_startup(void)
@@ -120,11 +150,6 @@ static bool dummycon_scroll(struct vc_data *vc, unsigned int top,
 	return false;
 }
 
-static int dummycon_switch(struct vc_data *vc)
-{
-	return 0;
-}
-
 /*
  *  The console `switch' structure for the dummy console
  *
diff --git a/include/linux/console.h b/include/linux/console.h
index 779d388af8..8fd70ae623 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -531,5 +531,7 @@ extern void console_init(void);
 /* For deferred console takeover */
 void dummycon_register_output_notifier(struct notifier_block *nb);
 void dummycon_unregister_output_notifier(struct notifier_block *nb);
+void dummycon_register_switch_notifier(struct notifier_block *nb);
+void dummycon_unregister_switch_notifier(struct notifier_block *nb);
 
 #endif /* _LINUX_CONSOLE_H */
-- 
2.43.0

[PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

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. So check the
command line for the expectation of userspace splash and if present then
extend the deferral until after the first switch.

V2: Added Kconfig option instead of hard coding "splash".

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>
---
 drivers/video/console/Kconfig    | 13 +++++++++++
 drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
 2 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index bc31db6ef7..a6e371bfb4 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
+	depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+	default "splash"
+	help
+	  If enabled this defers further the framebuffer console taking over
+	  until the first console switch has occurred. And even then only if
+	  text has been output, and 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. "splash" is the simplest
+	  distro-agnostic condition for this that Plymouth checks for.
+
 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 63af6ab034..98155d2256 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"
@@ -3358,6 +3359,26 @@ 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) {
+		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
+		dummycon_register_output_notifier(&fbcon_output_nb);
+	}
+
+	return NOTIFY_OK;
+}
+#endif
 #endif
 
 static void fbcon_start(void)
@@ -3370,7 +3391,16 @@ static void fbcon_start(void)
 
 	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
+			dummycon_register_output_notifier(&fbcon_output_nb);
+
 		return;
 	}
 #endif
@@ -3417,8 +3447,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);
-- 
2.43.0

Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel Vetter]

On Tue, Feb 06, 2024 at 06:10:51PM +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. So check the
> command line for the expectation of userspace splash and if present then
> extend the deferral until after the first switch.
> 
> V2: Added Kconfig option instead of hard coding "splash".
> 
> 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>
> ---
>  drivers/video/console/Kconfig    | 13 +++++++++++
>  drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
>  2 files changed, 49 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index bc31db6ef7..a6e371bfb4 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
> +	depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> +	default "splash"
> +	help
> +	  If enabled this defers further the framebuffer console taking over
> +	  until the first console switch has occurred. And even then only if
> +	  text has been output, and 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. "splash" is the simplest
> +	  distro-agnostic condition for this that Plymouth checks for.

Hm this seems a bit strange since a lot of complexity that no one needs,
also my impression is that it's rather distro specific how you want this
to work. So why not just a Kconfig option that lets you choose how much
you want to delay fbcon setup, with the following options:

- no delay at all
- dely until first output from the console (which then works for distros
  which set a log-level to suppress unwanted stuff)
- delay until first vt-switch. In that case I don't think we also need to
  delay for first output, since vt switch usually means you'll get first
  output right away (if it's a vt terminal) or you switch to a different
  graphical console (which will keep fbcon fully suppressed on the drm
  side).

I think you could even reuse the existing
CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER for this, and then just
compile-time select which kind of notifier to register (well plus the
check for "splash" on the cmdline for the vt switch one I guess).

Thoughts?

Cheers, Sima


> +
>  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 63af6ab034..98155d2256 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"
> @@ -3358,6 +3359,26 @@ 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) {
> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
> +		dummycon_register_output_notifier(&fbcon_output_nb);
> +	}
> +
> +	return NOTIFY_OK;
> +}
> +#endif
>  #endif
>  
>  static void fbcon_start(void)
> @@ -3370,7 +3391,16 @@ static void fbcon_start(void)
>  
>  	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
> +			dummycon_register_output_notifier(&fbcon_output_nb);
> +
>  		return;
>  	}
>  #endif
> @@ -3417,8 +3447,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);
> -- 
> 2.43.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Mario Limonciello]

On 2/6/2024 08:21, Daniel Vetter wrote:
> On Tue, Feb 06, 2024 at 06:10:51PM +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. So check the
>> command line for the expectation of userspace splash and if present then
>> extend the deferral until after the first switch.
>>
>> V2: Added Kconfig option instead of hard coding "splash".
>>
>> 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>
>> ---
>>   drivers/video/console/Kconfig    | 13 +++++++++++
>>   drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
>>   2 files changed, 49 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
>> index bc31db6ef7..a6e371bfb4 100644
>> --- a/drivers/video/console/Kconfig
>> +++ b/drivers/video/console/Kconfig
>> @@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
>> +	depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>> +	default "splash"
>> +	help
>> +	  If enabled this defers further the framebuffer console taking over
>> +	  until the first console switch has occurred. And even then only if
>> +	  text has been output, and 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. "splash" is the simplest
>> +	  distro-agnostic condition for this that Plymouth checks for.
> 
> Hm this seems a bit strange since a lot of complexity that no one needs,
> also my impression is that it's rather distro specific how you want this
> to work. So why not just a Kconfig option that lets you choose how much
> you want to delay fbcon setup, with the following options:
> 
> - no delay at all
> - dely until first output from the console (which then works for distros
>    which set a log-level to suppress unwanted stuff)
> - delay until first vt-switch. In that case I don't think we also need to
>    delay for first output, since vt switch usually means you'll get first
>    output right away (if it's a vt terminal) or you switch to a different
>    graphical console (which will keep fbcon fully suppressed on the drm
>    side).
> 

IIUC there is an "automatic" VT switch that happens with Ubuntu GRUB + 
Ubuntu kernels.

Why?

Couldn't this also be suppressed by just not doing that?

> I think you could even reuse the existing
> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER for this, and then just
> compile-time select which kind of notifier to register (well plus the
> check for "splash" on the cmdline for the vt switch one I guess).
> 
> Thoughts?
> 
> Cheers, Sima
> 
> 
>> +
>>   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 63af6ab034..98155d2256 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"
>> @@ -3358,6 +3359,26 @@ 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) {
>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>> +		dummycon_register_output_notifier(&fbcon_output_nb);
>> +	}
>> +
>> +	return NOTIFY_OK;
>> +}
>> +#endif
>>   #endif
>>   
>>   static void fbcon_start(void)
>> @@ -3370,7 +3391,16 @@ static void fbcon_start(void)
>>   
>>   	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
>> +			dummycon_register_output_notifier(&fbcon_output_nb);
>> +
>>   		return;
>>   	}
>>   #endif
>> @@ -3417,8 +3447,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);
>> -- 
>> 2.43.0
>>
> 

Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

On 6/2/24 23:41, Mario Limonciello wrote:
> On 2/6/2024 08:21, Daniel Vetter wrote:
>> On Tue, Feb 06, 2024 at 06:10:51PM +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. So check the
>>> command line for the expectation of userspace splash and if present then
>>> extend the deferral until after the first switch.
>>>
>>> V2: Added Kconfig option instead of hard coding "splash".
>>>
>>> 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>
>>> ---
>>>   drivers/video/console/Kconfig    | 13 +++++++++++
>>>   drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
>>>   2 files changed, 49 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
>>> index bc31db6ef7..a6e371bfb4 100644
>>> --- a/drivers/video/console/Kconfig
>>> +++ b/drivers/video/console/Kconfig
>>> @@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
>>> +    depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>> +    default "splash"
>>> +    help
>>> +      If enabled this defers further the framebuffer console taking over
>>> +      until the first console switch has occurred. And even then only if
>>> +      text has been output, and 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. "splash" is the simplest
>>> +      distro-agnostic condition for this that Plymouth checks for.
>>
>> Hm this seems a bit strange since a lot of complexity that no one needs,
>> also my impression is that it's rather distro specific how you want this
>> to work. So why not just a Kconfig option that lets you choose how much
>> you want to delay fbcon setup, with the following options:
>>
>> - no delay at all
>> - dely until first output from the console (which then works for distros
>>    which set a log-level to suppress unwanted stuff)
>> - delay until first vt-switch. In that case I don't think we also need to
>>    delay for first output, since vt switch usually means you'll get first
>>    output right away (if it's a vt terminal) or you switch to a different
>>    graphical console (which will keep fbcon fully suppressed on the drm
>>    side).
>>

I had similar thoughts, and had prototyped some of this already. But in the end
it felt like extra complexity there was no demand for.

If you would like to specify the preferred Kconfig design then I can implement
it. Though I don't think there is an enumeration type. It could also be a
runtime enumeration (deferred_takeover) controlled by fbcon=something.

> 
> IIUC there is an "automatic" VT switch that happens with Ubuntu GRUB + Ubuntu
> kernels.
> 
> Why?
> 
> Couldn't this also be suppressed by just not doing that?

I have not seen any automatic VT switches in debugging but now that you mention
it I was probably only debugging on drm-misc-next and not an Ubuntu kernel.

- Daniel

> 
>> I think you could even reuse the existing
>> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER for this, and then just
>> compile-time select which kind of notifier to register (well plus the
>> check for "splash" on the cmdline for the vt switch one I guess).
>>
>> Thoughts?
>>
>> Cheers, Sima
>>
>>
>>> +
>>>   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 63af6ab034..98155d2256 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"
>>> @@ -3358,6 +3359,26 @@ 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) {
>>> +        dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>> +        dummycon_register_output_notifier(&fbcon_output_nb);
>>> +    }
>>> +
>>> +    return NOTIFY_OK;
>>> +}
>>> +#endif
>>>   #endif
>>>     static void fbcon_start(void)
>>> @@ -3370,7 +3391,16 @@ static void fbcon_start(void)
>>>         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
>>> +            dummycon_register_output_notifier(&fbcon_output_nb);
>>> +
>>>           return;
>>>       }
>>>   #endif
>>> @@ -3417,8 +3447,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);
>>> -- 
>>> 2.43.0
>>>
>>
> 

Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel Vetter]

On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
> On 6/2/24 23:41, Mario Limonciello wrote:
> > On 2/6/2024 08:21, Daniel Vetter wrote:
> >> On Tue, Feb 06, 2024 at 06:10:51PM +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. So check the
> >>> command line for the expectation of userspace splash and if present then
> >>> extend the deferral until after the first switch.
> >>>
> >>> V2: Added Kconfig option instead of hard coding "splash".
> >>>
> >>> 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>
> >>> ---
> >>>   drivers/video/console/Kconfig    | 13 +++++++++++
> >>>   drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
> >>>   2 files changed, 49 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> >>> index bc31db6ef7..a6e371bfb4 100644
> >>> --- a/drivers/video/console/Kconfig
> >>> +++ b/drivers/video/console/Kconfig
> >>> @@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
> >>> +    depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> >>> +    default "splash"
> >>> +    help
> >>> +      If enabled this defers further the framebuffer console taking over
> >>> +      until the first console switch has occurred. And even then only if
> >>> +      text has been output, and 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. "splash" is the simplest
> >>> +      distro-agnostic condition for this that Plymouth checks for.
> >>
> >> Hm this seems a bit strange since a lot of complexity that no one needs,
> >> also my impression is that it's rather distro specific how you want this
> >> to work. So why not just a Kconfig option that lets you choose how much
> >> you want to delay fbcon setup, with the following options:
> >>
> >> - no delay at all
> >> - dely until first output from the console (which then works for distros
> >>    which set a log-level to suppress unwanted stuff)
> >> - delay until first vt-switch. In that case I don't think we also need to
> >>    delay for first output, since vt switch usually means you'll get first
> >>    output right away (if it's a vt terminal) or you switch to a different
> >>    graphical console (which will keep fbcon fully suppressed on the drm
> >>    side).
> >>
> 
> I had similar thoughts, and had prototyped some of this already. But in the end
> it felt like extra complexity there was no demand for.

For me this one is a bit too complex, since if you enable the vt switch
delay you also get the output delay on top. That seems one too much and I
can't come up with a use-case where you actually want that. So just a
choice of one or the other or none feels cleaner.

> If you would like to specify the preferred Kconfig design then I can implement
> it. Though I don't think there is an enumeration type. It could also be a
> runtime enumeration (deferred_takeover) controlled by fbcon=something.

There's a choice in Kconfig, see e.g. kernel/Kconfig.hz for an example.

> > IIUC there is an "automatic" VT switch that happens with Ubuntu GRUB + Ubuntu
> > kernels.
> > 
> > Why?
> > 
> > Couldn't this also be suppressed by just not doing that?
> 
> I have not seen any automatic VT switches in debugging but now that you mention
> it I was probably only debugging on drm-misc-next and not an Ubuntu kernel.

Hm but I don't see how the output delay would paper over a race (if there
is one) reliable for this case? If you do vt switch for boot splash or
login screen and don't yet have drm opened for display or something like
that, then fbcon can sneak in anyway ...

Cheers, Sima
> 
> - Daniel
> 
> > 
> >> I think you could even reuse the existing
> >> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER for this, and then just
> >> compile-time select which kind of notifier to register (well plus the
> >> check for "splash" on the cmdline for the vt switch one I guess).
> >>
> >> Thoughts?
> >>
> >> Cheers, Sima
> >>
> >>
> >>> +
> >>>   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 63af6ab034..98155d2256 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"
> >>> @@ -3358,6 +3359,26 @@ 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) {
> >>> +        dummycon_unregister_switch_notifier(&fbcon_switch_nb);
> >>> +        dummycon_register_output_notifier(&fbcon_output_nb);
> >>> +    }
> >>> +
> >>> +    return NOTIFY_OK;
> >>> +}
> >>> +#endif
> >>>   #endif
> >>>     static void fbcon_start(void)
> >>> @@ -3370,7 +3391,16 @@ static void fbcon_start(void)
> >>>         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
> >>> +            dummycon_register_output_notifier(&fbcon_output_nb);
> >>> +
> >>>           return;
> >>>       }
> >>>   #endif
> >>> @@ -3417,8 +3447,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);
> >>> -- 
> >>> 2.43.0
> >>>
> >>
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Mario Limonciello]

On 2/7/2024 03:51, Daniel Vetter wrote:
> On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
>> On 6/2/24 23:41, Mario Limonciello wrote:
>>> On 2/6/2024 08:21, Daniel Vetter wrote:
>>>> On Tue, Feb 06, 2024 at 06:10:51PM +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. So check the
>>>>> command line for the expectation of userspace splash and if present then
>>>>> extend the deferral until after the first switch.
>>>>>
>>>>> V2: Added Kconfig option instead of hard coding "splash".
>>>>>
>>>>> 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>
>>>>> ---
>>>>>    drivers/video/console/Kconfig    | 13 +++++++++++
>>>>>    drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
>>>>>    2 files changed, 49 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
>>>>> index bc31db6ef7..a6e371bfb4 100644
>>>>> --- a/drivers/video/console/Kconfig
>>>>> +++ b/drivers/video/console/Kconfig
>>>>> @@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
>>>>> +    depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>>>> +    default "splash"
>>>>> +    help
>>>>> +      If enabled this defers further the framebuffer console taking over
>>>>> +      until the first console switch has occurred. And even then only if
>>>>> +      text has been output, and 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. "splash" is the simplest
>>>>> +      distro-agnostic condition for this that Plymouth checks for.
>>>>
>>>> Hm this seems a bit strange since a lot of complexity that no one needs,
>>>> also my impression is that it's rather distro specific how you want this
>>>> to work. So why not just a Kconfig option that lets you choose how much
>>>> you want to delay fbcon setup, with the following options:
>>>>
>>>> - no delay at all
>>>> - dely until first output from the console (which then works for distros
>>>>     which set a log-level to suppress unwanted stuff)
>>>> - delay until first vt-switch. In that case I don't think we also need to
>>>>     delay for first output, since vt switch usually means you'll get first
>>>>     output right away (if it's a vt terminal) or you switch to a different
>>>>     graphical console (which will keep fbcon fully suppressed on the drm
>>>>     side).
>>>>
>>
>> I had similar thoughts, and had prototyped some of this already. But in the end
>> it felt like extra complexity there was no demand for.
> 
> For me this one is a bit too complex, since if you enable the vt switch
> delay you also get the output delay on top. That seems one too much and I
> can't come up with a use-case where you actually want that. So just a
> choice of one or the other or none feels cleaner.
> 
>> If you would like to specify the preferred Kconfig design then I can implement
>> it. Though I don't think there is an enumeration type. It could also be a
>> runtime enumeration (deferred_takeover) controlled by fbcon=something.
> 
> There's a choice in Kconfig, see e.g. kernel/Kconfig.hz for an example.
> 
>>> IIUC there is an "automatic" VT switch that happens with Ubuntu GRUB + Ubuntu
>>> kernels.
>>>
>>> Why?
>>>
>>> Couldn't this also be suppressed by just not doing that?
>>
>> I have not seen any automatic VT switches in debugging but now that you mention
>> it I was probably only debugging on drm-misc-next and not an Ubuntu kernel.
> 
> Hm but I don't see how the output delay would paper over a race (if there
> is one) reliable for this case? If you do vt switch for boot splash or
> login screen and don't yet have drm opened for display or something like
> that, then fbcon can sneak in anyway ...

Ubuntu has had in (at least some) kernels:

https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=320cfac8ef31

I'm unsure if it's still there today, but maybe it would be best if the 
author (Andy) could enlighten us?  Any idea why that didn't go upstream?

I had thought that tied with a automatic VT switch that was trying to 
hide fbcon as well.

> 
> Cheers, Sima
>>
>> - Daniel
>>
>>>
>>>> I think you could even reuse the existing
>>>> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER for this, and then just
>>>> compile-time select which kind of notifier to register (well plus the
>>>> check for "splash" on the cmdline for the vt switch one I guess).
>>>>
>>>> Thoughts?
>>>>
>>>> Cheers, Sima
>>>>
>>>>
>>>>> +
>>>>>    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 63af6ab034..98155d2256 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"
>>>>> @@ -3358,6 +3359,26 @@ 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) {
>>>>> +        dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>>> +        dummycon_register_output_notifier(&fbcon_output_nb);
>>>>> +    }
>>>>> +
>>>>> +    return NOTIFY_OK;
>>>>> +}
>>>>> +#endif
>>>>>    #endif
>>>>>      static void fbcon_start(void)
>>>>> @@ -3370,7 +3391,16 @@ static void fbcon_start(void)
>>>>>          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
>>>>> +            dummycon_register_output_notifier(&fbcon_output_nb);
>>>>> +
>>>>>            return;
>>>>>        }
>>>>>    #endif
>>>>> @@ -3417,8 +3447,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);
>>>>> -- 
>>>>> 2.43.0
>>>>>
>>>>
>>>
> 

Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

On 8/2/24 04:21, Mario Limonciello wrote:
> On 2/7/2024 03:51, Daniel Vetter wrote:
>> On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
>>> On 6/2/24 23:41, Mario Limonciello wrote:
>>>> On 2/6/2024 08:21, Daniel Vetter wrote:
>>>>> On Tue, Feb 06, 2024 at 06:10:51PM +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. So check the
>>>>>> command line for the expectation of userspace splash and if present then
>>>>>> extend the deferral until after the first switch.
>>>>>>
>>>>>> V2: Added Kconfig option instead of hard coding "splash".
>>>>>>
>>>>>> 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>
>>>>>> ---
>>>>>>    drivers/video/console/Kconfig    | 13 +++++++++++
>>>>>>    drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
>>>>>>    2 files changed, 49 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
>>>>>> index bc31db6ef7..a6e371bfb4 100644
>>>>>> --- a/drivers/video/console/Kconfig
>>>>>> +++ b/drivers/video/console/Kconfig
>>>>>> @@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
>>>>>> +    depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>>>>> +    default "splash"
>>>>>> +    help
>>>>>> +      If enabled this defers further the framebuffer console taking over
>>>>>> +      until the first console switch has occurred. And even then only if
>>>>>> +      text has been output, and 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. "splash" is the simplest
>>>>>> +      distro-agnostic condition for this that Plymouth checks for.
>>>>>
>>>>> Hm this seems a bit strange since a lot of complexity that no one needs,
>>>>> also my impression is that it's rather distro specific how you want this
>>>>> to work. So why not just a Kconfig option that lets you choose how much
>>>>> you want to delay fbcon setup, with the following options:
>>>>>
>>>>> - no delay at all
>>>>> - dely until first output from the console (which then works for distros
>>>>>     which set a log-level to suppress unwanted stuff)
>>>>> - delay until first vt-switch. In that case I don't think we also need to
>>>>>     delay for first output, since vt switch usually means you'll get first
>>>>>     output right away (if it's a vt terminal) or you switch to a different
>>>>>     graphical console (which will keep fbcon fully suppressed on the drm
>>>>>     side).
>>>>>
>>>
>>> I had similar thoughts, and had prototyped some of this already. But in the end
>>> it felt like extra complexity there was no demand for.
>>
>> For me this one is a bit too complex, since if you enable the vt switch
>> delay you also get the output delay on top. That seems one too much and I
>> can't come up with a use-case where you actually want that. So just a
>> choice of one or the other or none feels cleaner.

Remember the output "delay" goes to zero if any putc has occurred prior to
registration (see dummycon.c).

My current reason for using both is that in theory it prevents fbcon from
taking over *earlier* than it did before, in case there was never any output.
But I don't think there is "never any output" by the time you've tried to
manually VT switch so maybe that's unnecessary.

>>
>>> If you would like to specify the preferred Kconfig design then I can implement
>>> it. Though I don't think there is an enumeration type. It could also be a
>>> runtime enumeration (deferred_takeover) controlled by fbcon=something.
>>
>> There's a choice in Kconfig, see e.g. kernel/Kconfig.hz for an example.

Thanks!

>>
>>>> IIUC there is an "automatic" VT switch that happens with Ubuntu GRUB + Ubuntu
>>>> kernels.
>>>>
>>>> Why?
>>>>
>>>> Couldn't this also be suppressed by just not doing that?
>>>
>>> I have not seen any automatic VT switches in debugging but now that you mention
>>> it I was probably only debugging on drm-misc-next and not an Ubuntu kernel.
>>
>> Hm but I don't see how the output delay would paper over a race (if there
>> is one) reliable for this case? If you do vt switch for boot splash or
>> login screen and don't yet have drm opened for display or something like
>> that, then fbcon can sneak in anyway ...

There is no VT switch according to my logs, so there is no race with the
patchset. The only race that occurs is without this patchset, which is what's
being fixed here.

> 
> Ubuntu has had in (at least some) kernels:
> 
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=320cfac8ef31
> 
> I'm unsure if it's still there today, but maybe it would be best if the author
> (Andy) could enlighten us?  Any idea why that didn't go upstream?
> 
> I had thought that tied with a automatic VT switch that was trying to hide
> fbcon as well.

I checked the current Ubuntu 24.04 kernel yesterday and there is no VT switch
(anymore). The vc_num stays at zero until you do a manual VT switch. This seems
to be true for both drm-misc-next and Ubuntu kernels.

There is still vt.handoff=7 on the command line for Ubuntu, but I'm not sure it
has a function anymore. Maybe it was primarily for legacy BIOS? Andy can confirm.

> 
>>
>> Cheers, Sima
>>>
>>> - Daniel
>>>
>>>>
>>>>> I think you could even reuse the existing
>>>>> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER for this, and then just
>>>>> compile-time select which kind of notifier to register (well plus the
>>>>> check for "splash" on the cmdline for the vt switch one I guess).
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Cheers, Sima
>>>>>
>>>>>
>>>>>> +
>>>>>>    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 63af6ab034..98155d2256 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"
>>>>>> @@ -3358,6 +3359,26 @@ 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) {
>>>>>> +        dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>>>> +        dummycon_register_output_notifier(&fbcon_output_nb);
>>>>>> +    }
>>>>>> +
>>>>>> +    return NOTIFY_OK;
>>>>>> +}
>>>>>> +#endif
>>>>>>    #endif
>>>>>>      static void fbcon_start(void)
>>>>>> @@ -3370,7 +3391,16 @@ static void fbcon_start(void)
>>>>>>          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
>>>>>> +            dummycon_register_output_notifier(&fbcon_output_nb);
>>>>>> +
>>>>>>            return;
>>>>>>        }
>>>>>>    #endif
>>>>>> @@ -3417,8 +3447,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);
>>>>>> -- 
>>>>>> 2.43.0
>>>>>>
>>>>>
>>>>
>>
> 

Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel Vetter]

On Thu, Feb 08, 2024 at 09:16:50AM +0800, Daniel van Vugt wrote:
> On 8/2/24 04:21, Mario Limonciello wrote:
> > On 2/7/2024 03:51, Daniel Vetter wrote:
> >> On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
> >>> On 6/2/24 23:41, Mario Limonciello wrote:
> >>>> On 2/6/2024 08:21, Daniel Vetter wrote:
> >>>>> On Tue, Feb 06, 2024 at 06:10:51PM +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. So check the
> >>>>>> command line for the expectation of userspace splash and if present then
> >>>>>> extend the deferral until after the first switch.
> >>>>>>
> >>>>>> V2: Added Kconfig option instead of hard coding "splash".
> >>>>>>
> >>>>>> 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>
> >>>>>> ---
> >>>>>>    drivers/video/console/Kconfig    | 13 +++++++++++
> >>>>>>    drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
> >>>>>>    2 files changed, 49 insertions(+), 2 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> >>>>>> index bc31db6ef7..a6e371bfb4 100644
> >>>>>> --- a/drivers/video/console/Kconfig
> >>>>>> +++ b/drivers/video/console/Kconfig
> >>>>>> @@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
> >>>>>> +    depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> >>>>>> +    default "splash"
> >>>>>> +    help
> >>>>>> +      If enabled this defers further the framebuffer console taking over
> >>>>>> +      until the first console switch has occurred. And even then only if
> >>>>>> +      text has been output, and 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. "splash" is the simplest
> >>>>>> +      distro-agnostic condition for this that Plymouth checks for.
> >>>>>
> >>>>> Hm this seems a bit strange since a lot of complexity that no one needs,
> >>>>> also my impression is that it's rather distro specific how you want this
> >>>>> to work. So why not just a Kconfig option that lets you choose how much
> >>>>> you want to delay fbcon setup, with the following options:
> >>>>>
> >>>>> - no delay at all
> >>>>> - dely until first output from the console (which then works for distros
> >>>>>     which set a log-level to suppress unwanted stuff)
> >>>>> - delay until first vt-switch. In that case I don't think we also need to
> >>>>>     delay for first output, since vt switch usually means you'll get first
> >>>>>     output right away (if it's a vt terminal) or you switch to a different
> >>>>>     graphical console (which will keep fbcon fully suppressed on the drm
> >>>>>     side).
> >>>>>
> >>>
> >>> I had similar thoughts, and had prototyped some of this already. But in the end
> >>> it felt like extra complexity there was no demand for.
> >>
> >> For me this one is a bit too complex, since if you enable the vt switch
> >> delay you also get the output delay on top. That seems one too much and I
> >> can't come up with a use-case where you actually want that. So just a
> >> choice of one or the other or none feels cleaner.
> 
> Remember the output "delay" goes to zero if any putc has occurred prior to
> registration (see dummycon.c).
> 
> My current reason for using both is that in theory it prevents fbcon from
> taking over *earlier* than it did before, in case there was never any output.
> But I don't think there is "never any output" by the time you've tried to
> manually VT switch so maybe that's unnecessary.

Yeah, but I'm not sure that's like a choice anyone needs, just these
three:

- no delay
- wait until first output, and set debuglevel appropriately (what fedora
  and other distros do)
- wait until first vt switch (what ubuntu wants)

I don't ever expect fedora to just enable this, because they have
something that works. Plus many distros are moving away from CONFIG_VT and
all the in-kernel consoles anyway, so they want this even less.

So if just the delay to first vt-switch is enough for you, I think it's
best we just implement that. The entire vt switch/ownership rules with drm
and fbdev and all that is already really complex and in many cases it's
impossible to tell what's accidental cargo-culted behaviour and what is
actually required. That's why I'd prefer we exactly implement what you
need in this area, nothing more, nothing less.

And from the testing you discuss below it sounds like you don't need both
delays?

Cheers, Sima

> >>> If you would like to specify the preferred Kconfig design then I can implement
> >>> it. Though I don't think there is an enumeration type. It could also be a
> >>> runtime enumeration (deferred_takeover) controlled by fbcon=something.
> >>
> >> There's a choice in Kconfig, see e.g. kernel/Kconfig.hz for an example.
> 
> Thanks!
> 
> >>
> >>>> IIUC there is an "automatic" VT switch that happens with Ubuntu GRUB + Ubuntu
> >>>> kernels.
> >>>>
> >>>> Why?
> >>>>
> >>>> Couldn't this also be suppressed by just not doing that?
> >>>
> >>> I have not seen any automatic VT switches in debugging but now that you mention
> >>> it I was probably only debugging on drm-misc-next and not an Ubuntu kernel.
> >>
> >> Hm but I don't see how the output delay would paper over a race (if there
> >> is one) reliable for this case? If you do vt switch for boot splash or
> >> login screen and don't yet have drm opened for display or something like
> >> that, then fbcon can sneak in anyway ...
> 
> There is no VT switch according to my logs, so there is no race with the
> patchset. The only race that occurs is without this patchset, which is what's
> being fixed here.
> 
> > 
> > Ubuntu has had in (at least some) kernels:
> > 
> > https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=320cfac8ef31
> > 
> > I'm unsure if it's still there today, but maybe it would be best if the author
> > (Andy) could enlighten us?  Any idea why that didn't go upstream?
> > 
> > I had thought that tied with a automatic VT switch that was trying to hide
> > fbcon as well.
> 
> I checked the current Ubuntu 24.04 kernel yesterday and there is no VT switch
> (anymore). The vc_num stays at zero until you do a manual VT switch. This seems
> to be true for both drm-misc-next and Ubuntu kernels.
> 
> There is still vt.handoff=7 on the command line for Ubuntu, but I'm not sure it
> has a function anymore. Maybe it was primarily for legacy BIOS? Andy can confirm.
> 
> > 
> >>
> >> Cheers, Sima
> >>>
> >>> - Daniel
> >>>
> >>>>
> >>>>> I think you could even reuse the existing
> >>>>> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER for this, and then just
> >>>>> compile-time select which kind of notifier to register (well plus the
> >>>>> check for "splash" on the cmdline for the vt switch one I guess).
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Cheers, Sima
> >>>>>
> >>>>>
> >>>>>> +
> >>>>>>    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 63af6ab034..98155d2256 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"
> >>>>>> @@ -3358,6 +3359,26 @@ 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) {
> >>>>>> +        dummycon_unregister_switch_notifier(&fbcon_switch_nb);
> >>>>>> +        dummycon_register_output_notifier(&fbcon_output_nb);
> >>>>>> +    }
> >>>>>> +
> >>>>>> +    return NOTIFY_OK;
> >>>>>> +}
> >>>>>> +#endif
> >>>>>>    #endif
> >>>>>>      static void fbcon_start(void)
> >>>>>> @@ -3370,7 +3391,16 @@ static void fbcon_start(void)
> >>>>>>          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
> >>>>>> +            dummycon_register_output_notifier(&fbcon_output_nb);
> >>>>>> +
> >>>>>>            return;
> >>>>>>        }
> >>>>>>    #endif
> >>>>>> @@ -3417,8 +3447,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);
> >>>>>> -- 
> >>>>>> 2.43.0
> >>>>>>
> >>>>>
> >>>>
> >>
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

On 9/2/24 18:58, Daniel Vetter wrote:
> On Thu, Feb 08, 2024 at 09:16:50AM +0800, Daniel van Vugt wrote:
>> On 8/2/24 04:21, Mario Limonciello wrote:
>>> On 2/7/2024 03:51, Daniel Vetter wrote:
>>>> On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
>>>>> On 6/2/24 23:41, Mario Limonciello wrote:
>>>>>> On 2/6/2024 08:21, Daniel Vetter wrote:
>>>>>>> On Tue, Feb 06, 2024 at 06:10:51PM +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. So check the
>>>>>>>> command line for the expectation of userspace splash and if present then
>>>>>>>> extend the deferral until after the first switch.
>>>>>>>>
>>>>>>>> V2: Added Kconfig option instead of hard coding "splash".
>>>>>>>>
>>>>>>>> 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>
>>>>>>>> ---
>>>>>>>>    drivers/video/console/Kconfig    | 13 +++++++++++
>>>>>>>>    drivers/video/fbdev/core/fbcon.c | 38 ++++++++++++++++++++++++++++++--
>>>>>>>>    2 files changed, 49 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
>>>>>>>> index bc31db6ef7..a6e371bfb4 100644
>>>>>>>> --- a/drivers/video/console/Kconfig
>>>>>>>> +++ b/drivers/video/console/Kconfig
>>>>>>>> @@ -138,6 +138,19 @@ 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 "Framebuffer Console Deferred Takeover Condition"
>>>>>>>> +    depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>>>>>>> +    default "splash"
>>>>>>>> +    help
>>>>>>>> +      If enabled this defers further the framebuffer console taking over
>>>>>>>> +      until the first console switch has occurred. And even then only if
>>>>>>>> +      text has been output, and 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. "splash" is the simplest
>>>>>>>> +      distro-agnostic condition for this that Plymouth checks for.
>>>>>>>
>>>>>>> Hm this seems a bit strange since a lot of complexity that no one needs,
>>>>>>> also my impression is that it's rather distro specific how you want this
>>>>>>> to work. So why not just a Kconfig option that lets you choose how much
>>>>>>> you want to delay fbcon setup, with the following options:
>>>>>>>
>>>>>>> - no delay at all
>>>>>>> - dely until first output from the console (which then works for distros
>>>>>>>     which set a log-level to suppress unwanted stuff)
>>>>>>> - delay until first vt-switch. In that case I don't think we also need to
>>>>>>>     delay for first output, since vt switch usually means you'll get first
>>>>>>>     output right away (if it's a vt terminal) or you switch to a different
>>>>>>>     graphical console (which will keep fbcon fully suppressed on the drm
>>>>>>>     side).
>>>>>>>
>>>>>
>>>>> I had similar thoughts, and had prototyped some of this already. But in the end
>>>>> it felt like extra complexity there was no demand for.
>>>>
>>>> For me this one is a bit too complex, since if you enable the vt switch
>>>> delay you also get the output delay on top. That seems one too much and I
>>>> can't come up with a use-case where you actually want that. So just a
>>>> choice of one or the other or none feels cleaner.
>>
>> Remember the output "delay" goes to zero if any putc has occurred prior to
>> registration (see dummycon.c).
>>
>> My current reason for using both is that in theory it prevents fbcon from
>> taking over *earlier* than it did before, in case there was never any output.
>> But I don't think there is "never any output" by the time you've tried to
>> manually VT switch so maybe that's unnecessary.
> 
> Yeah, but I'm not sure that's like a choice anyone needs, just these
> three:
> 
> - no delay
> - wait until first output, and set debuglevel appropriately (what fedora
>   and other distros do)
> - wait until first vt switch (what ubuntu wants)

Come to think of it, an enum or Kconfig "choice" isn't necessary if I change
the default for CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION to
blank/disabled. Then the default behaviour is unchanged and you've still got
the choice of all three modes:

- No delay: fbcon=nodefer

- Wait until first output: Already happens when
CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION is absent from the
command line.

- Wait until first VT switch: Would only happen if compiled with
CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION and its value is present
on the command line.

P.S. I suspect Fedora and other distros are not immune to the problem, just
make it less likely by starting Plymouth super early on simpledrm. Certainly I
am finding some models of laptop emit kernel messages that would still pass
under a reduced loglevel.

> 
> I don't ever expect fedora to just enable this, because they have
> something that works. Plus many distros are moving away from CONFIG_VT and
> all the in-kernel consoles anyway, so they want this even less.
> 
> So if just the delay to first vt-switch is enough for you, I think it's
> best we just implement that. The entire vt switch/ownership rules with drm
> and fbdev and all that is already really complex and in many cases it's
> impossible to tell what's accidental cargo-culted behaviour and what is
> actually required. That's why I'd prefer we exactly implement what you
> need in this area, nothing more, nothing less.
> 
> And from the testing you discuss below it sounds like you don't need both
> delays?
> 
> Cheers, Sima
> 
>>>>> If you would like to specify the preferred Kconfig design then I can implement
>>>>> it. Though I don't think there is an enumeration type. It could also be a
>>>>> runtime enumeration (deferred_takeover) controlled by fbcon=something.
>>>>
>>>> There's a choice in Kconfig, see e.g. kernel/Kconfig.hz for an example.
>>
>> Thanks!
>>
>>>>
>>>>>> IIUC there is an "automatic" VT switch that happens with Ubuntu GRUB + Ubuntu
>>>>>> kernels.
>>>>>>
>>>>>> Why?
>>>>>>
>>>>>> Couldn't this also be suppressed by just not doing that?
>>>>>
>>>>> I have not seen any automatic VT switches in debugging but now that you mention
>>>>> it I was probably only debugging on drm-misc-next and not an Ubuntu kernel.
>>>>
>>>> Hm but I don't see how the output delay would paper over a race (if there
>>>> is one) reliable for this case? If you do vt switch for boot splash or
>>>> login screen and don't yet have drm opened for display or something like
>>>> that, then fbcon can sneak in anyway ...
>>
>> There is no VT switch according to my logs, so there is no race with the
>> patchset. The only race that occurs is without this patchset, which is what's
>> being fixed here.
>>
>>>
>>> Ubuntu has had in (at least some) kernels:
>>>
>>> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=320cfac8ef31
>>>
>>> I'm unsure if it's still there today, but maybe it would be best if the author
>>> (Andy) could enlighten us?  Any idea why that didn't go upstream?
>>>
>>> I had thought that tied with a automatic VT switch that was trying to hide
>>> fbcon as well.
>>
>> I checked the current Ubuntu 24.04 kernel yesterday and there is no VT switch
>> (anymore). The vc_num stays at zero until you do a manual VT switch. This seems
>> to be true for both drm-misc-next and Ubuntu kernels.
>>
>> There is still vt.handoff=7 on the command line for Ubuntu, but I'm not sure it
>> has a function anymore. Maybe it was primarily for legacy BIOS? Andy can confirm.
>>
>>>
>>>>
>>>> Cheers, Sima
>>>>>
>>>>> - Daniel
>>>>>
>>>>>>
>>>>>>> I think you could even reuse the existing
>>>>>>> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER for this, and then just
>>>>>>> compile-time select which kind of notifier to register (well plus the
>>>>>>> check for "splash" on the cmdline for the vt switch one I guess).
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Cheers, Sima
>>>>>>>
>>>>>>>
>>>>>>>> +
>>>>>>>>    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 63af6ab034..98155d2256 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"
>>>>>>>> @@ -3358,6 +3359,26 @@ 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) {
>>>>>>>> +        dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>>>>>> +        dummycon_register_output_notifier(&fbcon_output_nb);
>>>>>>>> +    }
>>>>>>>> +
>>>>>>>> +    return NOTIFY_OK;
>>>>>>>> +}
>>>>>>>> +#endif
>>>>>>>>    #endif
>>>>>>>>      static void fbcon_start(void)
>>>>>>>> @@ -3370,7 +3391,16 @@ static void fbcon_start(void)
>>>>>>>>          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
>>>>>>>> +            dummycon_register_output_notifier(&fbcon_output_nb);
>>>>>>>> +
>>>>>>>>            return;
>>>>>>>>        }
>>>>>>>>    #endif
>>>>>>>> @@ -3417,8 +3447,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);
>>>>>>>> -- 
>>>>>>>> 2.43.0
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
> 

[PATCH v3 1/2] dummycon: Add dummycon_(un)register_switch_notifier

[Daniel van Vugt]

To detect switch attempts before a real console exists. This will be
used for the same purpose as dummycon_(un)register_output_notifier,
for fbcon to detect a more polite time to take over.

Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
---
 drivers/video/console/dummycon.c | 35 +++++++++++++++++++++++++++-----
 include/linux/console.h          |  2 ++
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 14af5d9e13..55e9b600ce 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -83,6 +83,32 @@ static int dummycon_blank(struct vc_data *vc, int blank, int mode_switch)
 	/* Redraw, so that we get putc(s) for output done while blanked */
 	return 1;
 }
+
+/* This is protected by the console_lock */
+static RAW_NOTIFIER_HEAD(dummycon_switch_nh);
+
+void dummycon_register_switch_notifier(struct notifier_block *nb)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_chain_register(&dummycon_switch_nh, nb);
+}
+
+void dummycon_unregister_switch_notifier(struct notifier_block *nb)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_chain_unregister(&dummycon_switch_nh, nb);
+}
+
+static int dummycon_switch(struct vc_data *vc)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_call_chain(&dummycon_switch_nh, 0, vc);
+
+	return 0;
+}
 #else
 static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos) { }
 static void dummycon_putcs(struct vc_data *vc, const unsigned short *s,
@@ -91,6 +117,10 @@ static int dummycon_blank(struct vc_data *vc, int blank, int mode_switch)
 {
 	return 0;
 }
+static int dummycon_switch(struct vc_data *vc)
+{
+	return 0;
+}
 #endif
 
 static const char *dummycon_startup(void)
@@ -120,11 +150,6 @@ static bool dummycon_scroll(struct vc_data *vc, unsigned int top,
 	return false;
 }
 
-static int dummycon_switch(struct vc_data *vc)
-{
-	return 0;
-}
-
 /*
  *  The console `switch' structure for the dummy console
  *
diff --git a/include/linux/console.h b/include/linux/console.h
index 779d388af8..8fd70ae623 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -531,5 +531,7 @@ extern void console_init(void);
 /* For deferred console takeover */
 void dummycon_register_output_notifier(struct notifier_block *nb);
 void dummycon_unregister_output_notifier(struct notifier_block *nb);
+void dummycon_register_switch_notifier(struct notifier_block *nb);
+void dummycon_unregister_switch_notifier(struct notifier_block *nb);
 
 #endif /* _LINUX_CONSOLE_H */
-- 
2.43.0

[PATCH v3 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

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. So check the
command line for the expectation of userspace splash and if present then
extend the deferral until the first switch.

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.

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>
---
 drivers/video/console/Kconfig    | 12 +++++++++
 drivers/video/fbdev/core/fbcon.c | 44 +++++++++++++++++++++++++++++---
 2 files changed, 52 insertions(+), 4 deletions(-)

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);
-- 
2.43.0

Re: [PATCH v3 2/2] fbcon: Defer console takeover for splash screens to first switch

[Mario Limonciello]

On 2/13/2024 23:24, 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. So check the
> command line for the expectation of userspace splash and if present then
> extend the deferral until the first switch.

I think your comment from the earlier version that this can still happen 
on simpledrm (albeit less frequently) is very relevant here for the 
commit message.

> 
> 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.
> 

These you'll want below the cutlist (---)

Also I think you should mention in the commit message that the 
indication of a userspace splash is set by the Kconfig.

> 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>
> ---
>   drivers/video/console/Kconfig    | 12 +++++++++
>   drivers/video/fbdev/core/fbcon.c | 44 +++++++++++++++++++++++++++++---
>   2 files changed, 52 insertions(+), 4 deletions(-)
> 
> 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

Once you start adding nested #ifdef, I think it's very useful to add a 
comment on the #endif to make it easier to follow the code.

IE
#endif /* CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION */

>   
>   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);

[PATCH v4 1/2] dummycon: Add dummycon_(un)register_switch_notifier

[Daniel van Vugt]

To detect switch attempts before a real console exists. This will be
used for the same purpose as dummycon_(un)register_output_notifier,
for fbcon to detect a more polite time to take over.

Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
---
 drivers/video/console/dummycon.c | 35 +++++++++++++++++++++++++++-----
 include/linux/console.h          |  2 ++
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 14af5d9e13..55e9b600ce 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -83,6 +83,32 @@ static int dummycon_blank(struct vc_data *vc, int blank, int mode_switch)
 	/* Redraw, so that we get putc(s) for output done while blanked */
 	return 1;
 }
+
+/* This is protected by the console_lock */
+static RAW_NOTIFIER_HEAD(dummycon_switch_nh);
+
+void dummycon_register_switch_notifier(struct notifier_block *nb)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_chain_register(&dummycon_switch_nh, nb);
+}
+
+void dummycon_unregister_switch_notifier(struct notifier_block *nb)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_chain_unregister(&dummycon_switch_nh, nb);
+}
+
+static int dummycon_switch(struct vc_data *vc)
+{
+	WARN_CONSOLE_UNLOCKED();
+
+	raw_notifier_call_chain(&dummycon_switch_nh, 0, vc);
+
+	return 0;
+}
 #else
 static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos) { }
 static void dummycon_putcs(struct vc_data *vc, const unsigned short *s,
@@ -91,6 +117,10 @@ static int dummycon_blank(struct vc_data *vc, int blank, int mode_switch)
 {
 	return 0;
 }
+static int dummycon_switch(struct vc_data *vc)
+{
+	return 0;
+}
 #endif
 
 static const char *dummycon_startup(void)
@@ -120,11 +150,6 @@ static bool dummycon_scroll(struct vc_data *vc, unsigned int top,
 	return false;
 }
 
-static int dummycon_switch(struct vc_data *vc)
-{
-	return 0;
-}
-
 /*
  *  The console `switch' structure for the dummy console
  *
diff --git a/include/linux/console.h b/include/linux/console.h
index 779d388af8..8fd70ae623 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -531,5 +531,7 @@ extern void console_init(void);
 /* For deferred console takeover */
 void dummycon_register_output_notifier(struct notifier_block *nb);
 void dummycon_unregister_output_notifier(struct notifier_block *nb);
+void dummycon_register_switch_notifier(struct notifier_block *nb);
+void dummycon_unregister_switch_notifier(struct notifier_block *nb);
 
 #endif /* _LINUX_CONSOLE_H */
-- 
2.43.0

[PATCH v4 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

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(-)

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);
-- 
2.43.0

Re: [PATCH v4 2/2] fbcon: Defer console takeover for splash screens to first switch

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 2/2] fbcon: Defer console takeover for splash screens to first switch

[Mario Limonciello]

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.

Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch

[Hans de Goede]

Hi All,

On 2/2/24 09:53, 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. So check for the
> "splash" parameter (as used by Plymouth) and if present then extend the
> deferral until the first switch.

Daniel, thank you for your patch but I do not believe that this
is the right solution. Deferring fbcon takeover further then
after the first text is output means that any errors about e.g.
a corrupt initrd or the kernel erroring out / crashing will not
be visible.

When the kernel e.g. oopses or panics because of not finding
its rootfs (I tested the latter option when writing the original
deferred fbcon takeover code) then fbcon must takeover and
print the messages from the dying kernel so that the user has
some notion of what is going wrong.

And since your patch seems to delay switching till the first
vc-switch this means that e.g. even after say gdm refusing
to start because of issues there still will be no text
output. This makes debugging various issues much harder.

Moreover Fedora has been doing flickerfree boot for many
years without needing this.

The kernel itself will be quiet as long as you set
CONFIG_CONSOLE_LOGLEVEL_QUIET=3 Ubuntu atm has set this
to 4 which means any kernel pr_err() or dev_err()
messages will get through and since there are quite
a few false positives of those Ubuntu really needs
to set CONFIG_CONSOLE_LOGLEVEL_QUIET=3 to fix part of:
https://bugs.launchpad.net/bugs/1970069

After that it is "just" a matter of not making userspace
output anything unless it has errors to report.

systemd already is quiet by default (only logging
errors) when quiet is on the kernel commandline.

So any remaining issues are Ubuntu specific boot
process bits and Ubuntu really should be able to
make those by silent unless they have important
info (errors or other unexpected things) to report.

Given that this will make debugging boot issues
much harder and that there are other IMHO better
alternatives I'm nacking this patch: NACK.

FWIW I believe that I'm actually saving Ubuntu
from shooting themselves in the foot here,
hiding all sort of boot errors (like the initrd
not finding /) until the user does a magic
alt+f2 followed by alt+f1 incantation really is
not doing yourself any favors wrt debugging any
sort of boot failures.

Regards,

Hans





> 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>
> ---
>  drivers/video/fbdev/core/fbcon.c | 32 +++++++++++++++++++++++++++++---
>  1 file changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 63af6ab034..5b9f7635f7 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"
> @@ -146,6 +147,7 @@ static inline void fbcon_map_override(void)
>  
>  #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>  static bool deferred_takeover = true;
> +static int initial_console = -1;
>  #else
>  #define deferred_takeover false
>  #endif
> @@ -3341,7 +3343,7 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>  	console_unlock();
>  }
>  
> -static struct notifier_block fbcon_output_nb;
> +static struct notifier_block fbcon_output_nb, fbcon_switch_nb;
>  static DECLARE_WORK(fbcon_deferred_takeover_work, fbcon_register_existing_fbs);
>  
>  static int fbcon_output_notifier(struct notifier_block *nb,
> @@ -3358,6 +3360,21 @@ static int fbcon_output_notifier(struct notifier_block *nb,
>  
>  	return NOTIFY_OK;
>  }
> +
> +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) {
> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
> +		dummycon_register_output_notifier(&fbcon_output_nb);
> +	}
> +
> +	return NOTIFY_OK;
> +}
>  #endif
>  
>  static void fbcon_start(void)
> @@ -3370,7 +3387,14 @@ static void fbcon_start(void)
>  
>  	if (deferred_takeover) {
>  		fbcon_output_nb.notifier_call = fbcon_output_notifier;
> -		dummycon_register_output_notifier(&fbcon_output_nb);
> +		fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
> +		initial_console = fg_console;
> +
> +		if (cmdline_find_option_bool(boot_command_line, "splash"))
> +			dummycon_register_switch_notifier(&fbcon_switch_nb);
> +		else
> +			dummycon_register_output_notifier(&fbcon_output_nb);
> +
>  		return;
>  	}
>  #endif
> @@ -3417,8 +3441,10 @@ 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);
> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
> +	}
>  	console_unlock();
>  
>  	cancel_work_sync(&fbcon_deferred_takeover_work);

Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

On 27/2/24 02:23, Hans de Goede wrote:
> Hi All,
> 
> On 2/2/24 09:53, 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. So check for the
>> "splash" parameter (as used by Plymouth) and if present then extend the
>> deferral until the first switch.
> 
> Daniel, thank you for your patch but I do not believe that this
> is the right solution. Deferring fbcon takeover further then
> after the first text is output means that any errors about e.g.
> a corrupt initrd or the kernel erroring out / crashing will not
> be visible.

That's not really correct. If a boot failure has occurred after the splash then
pressing escape shows the log. If a boot failure has occurred before the splash
then it can be debugged visually by rebooting without the "splash" parameter.

> 
> When the kernel e.g. oopses or panics because of not finding
> its rootfs (I tested the latter option when writing the original
> deferred fbcon takeover code) then fbcon must takeover and
> print the messages from the dying kernel so that the user has
> some notion of what is going wrong.

Indeed, just reboot without the "splash" parameter to do that.

> 
> And since your patch seems to delay switching till the first
> vc-switch this means that e.g. even after say gdm refusing
> to start because of issues there still will be no text
> output. This makes debugging various issues much harder.

I've debugged many gdm failures and it is never useful to use the console for
those. Reboot and get the system journal instead.

> 
> Moreover Fedora has been doing flickerfree boot for many
> years without needing this.

I believe Fedora has a mostly working solution, but not totally reliable, as
mentioned in the commit message:

"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"

> 
> The kernel itself will be quiet as long as you set
> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 Ubuntu atm has set this
> to 4 which means any kernel pr_err() or dev_err()
> messages will get through and since there are quite
> a few false positives of those Ubuntu really needs
> to set CONFIG_CONSOLE_LOGLEVEL_QUIET=3 to fix part of:
> https://bugs.launchpad.net/bugs/1970069

Incorrect. In my testing some laptops needed log level as low as 2 to go quiet.
And the Ubuntu kernel team is never going to fix all those for non-sponsored
devices.

> 
> After that it is "just" a matter of not making userspace
> output anything unless it has errors to report.
> 
> systemd already is quiet by default (only logging
> errors) when quiet is on the kernel commandline.

Unfortunately not true for Ubuntu. We carry a noisy systemd patch which I'm
told we can't remove in the short term:

https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/comments/39

> 
> So any remaining issues are Ubuntu specific boot
> process bits and Ubuntu really should be able to
> make those by silent unless they have important
> info (errors or other unexpected things) to report.
> 
> Given that this will make debugging boot issues
> much harder and that there are other IMHO better
> alternatives I'm nacking this patch: NACK.
> 
> FWIW I believe that I'm actually saving Ubuntu
> from shooting themselves in the foot here,
> hiding all sort of boot errors (like the initrd
> not finding /) until the user does a magic
> alt+f2 followed by alt+f1 incantation really is
> not doing yourself any favors wrt debugging any
> sort of boot failures.
> 
> Regards,
> 
> Hans

Thanks for your input, but I respectfully disagree and did consider these
points already.

- Daniel

> 
> 
> 
> 
> 
>> 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>
>> ---
>>  drivers/video/fbdev/core/fbcon.c | 32 +++++++++++++++++++++++++++++---
>>  1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>> index 63af6ab034..5b9f7635f7 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"
>> @@ -146,6 +147,7 @@ static inline void fbcon_map_override(void)
>>  
>>  #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>  static bool deferred_takeover = true;
>> +static int initial_console = -1;
>>  #else
>>  #define deferred_takeover false
>>  #endif
>> @@ -3341,7 +3343,7 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>>  	console_unlock();
>>  }
>>  
>> -static struct notifier_block fbcon_output_nb;
>> +static struct notifier_block fbcon_output_nb, fbcon_switch_nb;
>>  static DECLARE_WORK(fbcon_deferred_takeover_work, fbcon_register_existing_fbs);
>>  
>>  static int fbcon_output_notifier(struct notifier_block *nb,
>> @@ -3358,6 +3360,21 @@ static int fbcon_output_notifier(struct notifier_block *nb,
>>  
>>  	return NOTIFY_OK;
>>  }
>> +
>> +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) {
>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>> +		dummycon_register_output_notifier(&fbcon_output_nb);
>> +	}
>> +
>> +	return NOTIFY_OK;
>> +}
>>  #endif
>>  
>>  static void fbcon_start(void)
>> @@ -3370,7 +3387,14 @@ static void fbcon_start(void)
>>  
>>  	if (deferred_takeover) {
>>  		fbcon_output_nb.notifier_call = fbcon_output_notifier;
>> -		dummycon_register_output_notifier(&fbcon_output_nb);
>> +		fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
>> +		initial_console = fg_console;
>> +
>> +		if (cmdline_find_option_bool(boot_command_line, "splash"))
>> +			dummycon_register_switch_notifier(&fbcon_switch_nb);
>> +		else
>> +			dummycon_register_output_notifier(&fbcon_output_nb);
>> +
>>  		return;
>>  	}
>>  #endif
>> @@ -3417,8 +3441,10 @@ 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);
>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>> +	}
>>  	console_unlock();
>>  
>>  	cancel_work_sync(&fbcon_deferred_takeover_work);
> 

Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch

[Hans de Goede]

Hi,

On 2/27/24 02:06, Daniel van Vugt wrote:
> On 27/2/24 02:23, Hans de Goede wrote:
>> Hi All,
>>
>> On 2/2/24 09:53, 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. So check for the
>>> "splash" parameter (as used by Plymouth) and if present then extend the
>>> deferral until the first switch.
>>
>> Daniel, thank you for your patch but I do not believe that this
>> is the right solution. Deferring fbcon takeover further then
>> after the first text is output means that any errors about e.g.
>> a corrupt initrd or the kernel erroring out / crashing will not
>> be visible.
> 
> That's not really correct. If a boot failure has occurred after the splash then
> pressing escape shows the log.

Hmm, I guess this is with the latest plymouth which has a builtin terminal
emulator for kernels without VT support ? Pressing ESC does not to a VC
switch and AFAICT that is what you are triggering on to allow fbcon takeover
after this patches.

> If a boot failure has occurred before the splash
> then it can be debugged visually by rebooting without the "splash" parameter.

Which requires the user to know this and requires the user to know how to
edit kernel cmdline parameters in e.g. grub. This is not a good user
experience. We want inexperienced users to just be able to point
a phone camera at the screen and take a picture of the errors.


>> When the kernel e.g. oopses or panics because of not finding
>> its rootfs (I tested the latter option when writing the original
>> deferred fbcon takeover code) then fbcon must takeover and
>> print the messages from the dying kernel so that the user has
>> some notion of what is going wrong.
> 
> Indeed, just reboot without the "splash" parameter to do that.

Again not something beginning Linux users will be able to do,
what happened to "Ubuntu: Linux for Human Beings" ?

>> And since your patch seems to delay switching till the first
>> vc-switch this means that e.g. even after say gdm refusing
>> to start because of issues there still will be no text
>> output. This makes debugging various issues much harder.
> 
> I've debugged many gdm failures and it is never useful to use the console for
> those. Reboot and get the system journal instead.

But users will not see any errors now, meaning they don't
even know where to begin with troubleshooting ...

>> Moreover Fedora has been doing flickerfree boot for many
>> years without needing this.
> 
> I believe Fedora has a mostly working solution, but not totally reliable, as
> mentioned in the commit message:
> 
> "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"

Only very serious kernel errors like oopses or panics will
trigger the takeover and that is *exactly* what we want.

There is a race where plymouth may hide such vary serious
messages, if plymouth does manage to start before the errors,
but that is actually an existing issue which we don't want
to make bigger by *always* hiding such errors.

>> The kernel itself will be quiet as long as you set
>> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 Ubuntu atm has set this
>> to 4 which means any kernel pr_err() or dev_err()
>> messages will get through and since there are quite
>> a few false positives of those Ubuntu really needs
>> to set CONFIG_CONSOLE_LOGLEVEL_QUIET=3 to fix part of:
>> https://bugs.launchpad.net/bugs/1970069
> 
> Incorrect. In my testing some laptops needed log level as low as 2 to go quiet.
> And the Ubuntu kernel team is never going to fix all those for non-sponsored
> devices.

Notice that atm Ubuntu's kernel is using the too high
CONFIG_CONSOLE_LOGLEVEL_QUIET=4 with
CONFIG_CONSOLE_LOGLEVEL_QUIET=3 getting any errors logged
to the console should be very very rare.

The only thing I can think of is if the kernel oopses
/ WARN()s early on but the cause is innocent enough
that the boot happily continues.

In that case actually showing the oops/WARN() is a good
thing.

For all the years Fedora has had flickerfree boot I have
seen zero bug reports about this. If you have examples
of this actually being a problem please file bugs for
them (launchpad or bugzilla.kernel.org is fine) and
then lets take a look at those bugs and fix them.

These should be so rare that I'm not worried about this
becoming a never ending list of bugs (unlike pr_err() /
dev_err() messages of which there are simply too many).

>> After that it is "just" a matter of not making userspace
>> output anything unless it has errors to report.
>>
>> systemd already is quiet by default (only logging
>> errors) when quiet is on the kernel commandline.
> 
> Unfortunately not true for Ubuntu. We carry a noisy systemd patch which I'm
> told we can't remove in the short term:
> 
> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/comments/39

Well then make the patch less noisy? Suppressing non
error message unless in debug mode should be easy
even with a downstream patch.

> Thanks for your input, but I respectfully disagree and did consider these
> points already.

Sorry, but your real problem here seems to be your
noisy downstream systemd patch. I'm not going to ack
a kernel patch which I consider a bad idea because
Ubuntu has a non standard systemd patch which is
to trigger happy with spamming the console.

So this is still a NACK from me.

Regards,

Hans





>>> 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>
>>> ---
>>>  drivers/video/fbdev/core/fbcon.c | 32 +++++++++++++++++++++++++++++---
>>>  1 file changed, 29 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>>> index 63af6ab034..5b9f7635f7 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"
>>> @@ -146,6 +147,7 @@ static inline void fbcon_map_override(void)
>>>  
>>>  #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>>  static bool deferred_takeover = true;
>>> +static int initial_console = -1;
>>>  #else
>>>  #define deferred_takeover false
>>>  #endif
>>> @@ -3341,7 +3343,7 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>>>  	console_unlock();
>>>  }
>>>  
>>> -static struct notifier_block fbcon_output_nb;
>>> +static struct notifier_block fbcon_output_nb, fbcon_switch_nb;
>>>  static DECLARE_WORK(fbcon_deferred_takeover_work, fbcon_register_existing_fbs);
>>>  
>>>  static int fbcon_output_notifier(struct notifier_block *nb,
>>> @@ -3358,6 +3360,21 @@ static int fbcon_output_notifier(struct notifier_block *nb,
>>>  
>>>  	return NOTIFY_OK;
>>>  }
>>> +
>>> +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) {
>>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>> +		dummycon_register_output_notifier(&fbcon_output_nb);
>>> +	}
>>> +
>>> +	return NOTIFY_OK;
>>> +}
>>>  #endif
>>>  
>>>  static void fbcon_start(void)
>>> @@ -3370,7 +3387,14 @@ static void fbcon_start(void)
>>>  
>>>  	if (deferred_takeover) {
>>>  		fbcon_output_nb.notifier_call = fbcon_output_notifier;
>>> -		dummycon_register_output_notifier(&fbcon_output_nb);
>>> +		fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
>>> +		initial_console = fg_console;
>>> +
>>> +		if (cmdline_find_option_bool(boot_command_line, "splash"))
>>> +			dummycon_register_switch_notifier(&fbcon_switch_nb);
>>> +		else
>>> +			dummycon_register_output_notifier(&fbcon_output_nb);
>>> +
>>>  		return;
>>>  	}
>>>  #endif
>>> @@ -3417,8 +3441,10 @@ 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);
>>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>> +	}
>>>  	console_unlock();
>>>  
>>>  	cancel_work_sync(&fbcon_deferred_takeover_work);
>>
> 

Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch

[Daniel van Vugt]

On 27/2/24 21:47, Hans de Goede wrote:
> Hi,
> 
> On 2/27/24 02:06, Daniel van Vugt wrote:
>> On 27/2/24 02:23, Hans de Goede wrote:
>>> Hi All,
>>>
>>> On 2/2/24 09:53, 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. So check for the
>>>> "splash" parameter (as used by Plymouth) and if present then extend the
>>>> deferral until the first switch.
>>>
>>> Daniel, thank you for your patch but I do not believe that this
>>> is the right solution. Deferring fbcon takeover further then
>>> after the first text is output means that any errors about e.g.
>>> a corrupt initrd or the kernel erroring out / crashing will not
>>> be visible.
>>
>> That's not really correct. If a boot failure has occurred after the splash then
>> pressing escape shows the log.
> 
> Hmm, I guess this is with the latest plymouth which has a builtin terminal
> emulator for kernels without VT support ? Pressing ESC does not to a VC
> switch and AFAICT that is what you are triggering on to allow fbcon takeover
> after this patches.
> 
>> If a boot failure has occurred before the splash
>> then it can be debugged visually by rebooting without the "splash" parameter.
> 
> Which requires the user to know this and requires the user to know how to
> edit kernel cmdline parameters in e.g. grub. This is not a good user
> experience. We want inexperienced users to just be able to point
> a phone camera at the screen and take a picture of the errors.

As the person who contributes most to Ubuntu bug triage I have a pretty good
idea of what users experience. And when they do experience boot failures it's
either with a blank screen already (because userspace, not the kernel's fault),
or they report an error message to us that's not relevant to the real failure.

In both cases our users understand (or learn quickly) the ease with which they
can reboot either to recovery mode, or a previous kernel. We then direct them
to collect the full log of the failed boot. Because even if they were booting
with a full text console, most of those bugs don't reveal themselves on the
console. If they did then they'd be visible in the system journal along with
everything else.

What is not a "good user experience" is the boot messages people are shown on
every boot.

> 
> 
>>> When the kernel e.g. oopses or panics because of not finding
>>> its rootfs (I tested the latter option when writing the original
>>> deferred fbcon takeover code) then fbcon must takeover and
>>> print the messages from the dying kernel so that the user has
>>> some notion of what is going wrong.
>>
>> Indeed, just reboot without the "splash" parameter to do that.
> 
> Again not something beginning Linux users will be able to do,
> what happened to "Ubuntu: Linux for Human Beings" ?

It is more user-friendly than it sounds. Just reboot, trigger the grub menu and
select recovery mode or an older kernel (which is always available).

I think some boot failures also take you to the grub menu automatically next time?

> 
>>> And since your patch seems to delay switching till the first
>>> vc-switch this means that e.g. even after say gdm refusing
>>> to start because of issues there still will be no text
>>> output. This makes debugging various issues much harder.
>>
>> I've debugged many gdm failures and it is never useful to use the console for
>> those. Reboot and get the system journal instead.
> 
> But users will not see any errors now, meaning they don't
> even know where to begin with troubleshooting ...

Indeed. I deal with those users every day and they log their bugs against the
wrong components, understandably. We then work with them to triage and reassign
the issue to the right place.

> 
>>> Moreover Fedora has been doing flickerfree boot for many
>>> years without needing this.
>>
>> I believe Fedora has a mostly working solution, but not totally reliable, as
>> mentioned in the commit message:
>>
>> "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"
> 
> Only very serious kernel errors like oopses or panics will
> trigger the takeover and that is *exactly* what we want.
> 
> There is a race where plymouth may hide such vary serious
> messages, if plymouth does manage to start before the errors,
> but that is actually an existing issue which we don't want
> to make bigger by *always* hiding such errors.
> 
>>> The kernel itself will be quiet as long as you set
>>> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 Ubuntu atm has set this
>>> to 4 which means any kernel pr_err() or dev_err()
>>> messages will get through and since there are quite
>>> a few false positives of those Ubuntu really needs
>>> to set CONFIG_CONSOLE_LOGLEVEL_QUIET=3 to fix part of:
>>> https://bugs.launchpad.net/bugs/1970069
>>
>> Incorrect. In my testing some laptops needed log level as low as 2 to go quiet.
>> And the Ubuntu kernel team is never going to fix all those for non-sponsored
>> devices.
> 
> Notice that atm Ubuntu's kernel is using the too high
> CONFIG_CONSOLE_LOGLEVEL_QUIET=4 with
> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 getting any errors logged
> to the console should be very very rare.
> 
> The only thing I can think of is if the kernel oopses
> / WARN()s early on but the cause is innocent enough
> that the boot happily continues.
> 
> In that case actually showing the oops/WARN() is a good
> thing.
> 
> For all the years Fedora has had flickerfree boot I have
> seen zero bug reports about this. If you have examples
> of this actually being a problem please file bugs for
> them (launchpad or bugzilla.kernel.org is fine) and
> then lets take a look at those bugs and fix them.
> 
> These should be so rare that I'm not worried about this
> becoming a never ending list of bugs (unlike pr_err() /
> dev_err() messages of which there are simply too many).

I personally own many laptops with so many different boot messages that it's
overwhelming for me already to report bugs for each of them. Hence this patch.

Also I don't own all the laptops in the world, so fixing all the errors just
for my collection wouldn't solve all cases. Whereas this patch does.

> 
>>> After that it is "just" a matter of not making userspace
>>> output anything unless it has errors to report.
>>>
>>> systemd already is quiet by default (only logging
>>> errors) when quiet is on the kernel commandline.
>>
>> Unfortunately not true for Ubuntu. We carry a noisy systemd patch which I'm
>> told we can't remove in the short term:
>>
>> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/comments/39
> 
> Well then make the patch less noisy? Suppressing non
> error message unless in debug mode should be easy
> even with a downstream patch.
> 
>> Thanks for your input, but I respectfully disagree and did consider these
>> points already.
> 
> Sorry, but your real problem here seems to be your
> noisy downstream systemd patch. I'm not going to ack
> a kernel patch which I consider a bad idea because
> Ubuntu has a non standard systemd patch which is
> to trigger happy with spamming the console.

Indeed the systemd patch is a big problem. We seem to have had it for 9 years
or so. I only just discovered it recently and would love to drop it, but was
told we can't. Its main problem is that it uses the console as a communication
pipe to plymouth. So simply making it less noisy isn't possible without
disabling its functionality. It was seemingly intended to run behind the
splash, but since it does fsck it tends to run before the splash (because DRM
startup takes a few more seconds).

> 
> So this is still a NACK from me.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
>>>> 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>
>>>> ---
>>>>  drivers/video/fbdev/core/fbcon.c | 32 +++++++++++++++++++++++++++++---
>>>>  1 file changed, 29 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>>>> index 63af6ab034..5b9f7635f7 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"
>>>> @@ -146,6 +147,7 @@ static inline void fbcon_map_override(void)
>>>>  
>>>>  #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>>>  static bool deferred_takeover = true;
>>>> +static int initial_console = -1;
>>>>  #else
>>>>  #define deferred_takeover false
>>>>  #endif
>>>> @@ -3341,7 +3343,7 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>>>>  	console_unlock();
>>>>  }
>>>>  
>>>> -static struct notifier_block fbcon_output_nb;
>>>> +static struct notifier_block fbcon_output_nb, fbcon_switch_nb;
>>>>  static DECLARE_WORK(fbcon_deferred_takeover_work, fbcon_register_existing_fbs);
>>>>  
>>>>  static int fbcon_output_notifier(struct notifier_block *nb,
>>>> @@ -3358,6 +3360,21 @@ static int fbcon_output_notifier(struct notifier_block *nb,
>>>>  
>>>>  	return NOTIFY_OK;
>>>>  }
>>>> +
>>>> +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) {
>>>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>> +		dummycon_register_output_notifier(&fbcon_output_nb);
>>>> +	}
>>>> +
>>>> +	return NOTIFY_OK;
>>>> +}
>>>>  #endif
>>>>  
>>>>  static void fbcon_start(void)
>>>> @@ -3370,7 +3387,14 @@ static void fbcon_start(void)
>>>>  
>>>>  	if (deferred_takeover) {
>>>>  		fbcon_output_nb.notifier_call = fbcon_output_notifier;
>>>> -		dummycon_register_output_notifier(&fbcon_output_nb);
>>>> +		fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
>>>> +		initial_console = fg_console;
>>>> +
>>>> +		if (cmdline_find_option_bool(boot_command_line, "splash"))
>>>> +			dummycon_register_switch_notifier(&fbcon_switch_nb);
>>>> +		else
>>>> +			dummycon_register_output_notifier(&fbcon_output_nb);
>>>> +
>>>>  		return;
>>>>  	}
>>>>  #endif
>>>> @@ -3417,8 +3441,10 @@ 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);
>>>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>> +	}
>>>>  	console_unlock();
>>>>  
>>>>  	cancel_work_sync(&fbcon_deferred_takeover_work);
>>>
>>
> 

Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch

[Hans de Goede]

Hi Daniel,

On 2/28/24 03:00, Daniel van Vugt wrote:
> On 27/2/24 21:47, Hans de Goede wrote:

<snip>

> I think some boot failures also take you to the grub menu automatically next time?

In Fedora all boot failures will unhide the grub menu on
the next boot. This unfortunately relies on downstream changes
so I don't know what Ubuntu does here.

<snip>

>>>> The kernel itself will be quiet as long as you set
>>>> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 Ubuntu atm has set this
>>>> to 4 which means any kernel pr_err() or dev_err()
>>>> messages will get through and since there are quite
>>>> a few false positives of those Ubuntu really needs
>>>> to set CONFIG_CONSOLE_LOGLEVEL_QUIET=3 to fix part of:
>>>> https://bugs.launchpad.net/bugs/1970069
>>>
>>> Incorrect. In my testing some laptops needed log level as low as 2 to go quiet.
>>> And the Ubuntu kernel team is never going to fix all those for non-sponsored
>>> devices.
>>
>> Notice that atm Ubuntu's kernel is using the too high
>> CONFIG_CONSOLE_LOGLEVEL_QUIET=4 with
>> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 getting any errors logged
>> to the console should be very very rare.
>>
>> The only thing I can think of is if the kernel oopses
>> / WARN()s early on but the cause is innocent enough
>> that the boot happily continues.
>>
>> In that case actually showing the oops/WARN() is a good
>> thing.
>>
>> For all the years Fedora has had flickerfree boot I have
>> seen zero bug reports about this. If you have examples
>> of this actually being a problem please file bugs for
>> them (launchpad or bugzilla.kernel.org is fine) and
>> then lets take a look at those bugs and fix them.
>>
>> These should be so rare that I'm not worried about this
>> becoming a never ending list of bugs (unlike pr_err() /
>> dev_err() messages of which there are simply too many).
> 
> I personally own many laptops with so many different boot messages that it's
> overwhelming for me already to report bugs for each of them. Hence this patch.
> 
> Also I don't own all the laptops in the world, so fixing all the errors just
> for my collection wouldn't solve all cases. Whereas this patch does.

Almost all of those boot messages are because Ubuntu has
set CONFIG_CONSOLE_LOGLEVEL_QUIET too high. Once that is fixed
there should be very little of not no messages left.

I too own many laptops and I'm not seeing this issue on
any of them.

You claim you are still seeing errors with
CONFIG_CONSOLE_LOGLEVEL_QUIET=3 yet you have not provided
a single example!

>> Sorry, but your real problem here seems to be your
>> noisy downstream systemd patch. I'm not going to ack
>> a kernel patch which I consider a bad idea because
>> Ubuntu has a non standard systemd patch which is
>> to trigger happy with spamming the console.
> 
> Indeed the systemd patch is a big problem. We seem to have had it for 9 years
> or so. I only just discovered it recently and would love to drop it, but was
> told we can't. Its main problem is that it uses the console as a communication
> pipe to plymouth. So simply making it less noisy isn't possible without
> disabling its functionality. It was seemingly intended to run behind the
> splash, but since it does fsck it tends to run before the splash (because DRM
> startup takes a few more seconds).

This does indeed sound like it is a non trivial problem to fix,
but that is still not a good reason to add this (IMHO) hack
to the kernel.

The issue deferred fbcon takeover was designed to fix is that
the fbcon would mess up the framebuffer contents even if
nothing was ever logged to the console.

The whole idea being that to still have the fbcon come up
as soon as there are any messages.

Actively hiding messages was never part of the design, so
this is still a NACK from me.

Also note that this matches how things work in grub
and shim when I first implemented flickerfree boot
I also had to patch shim and grub to not make EFI
text output protocol calls (including init()) until
they actually had some text to show.

So the whole design here for shim, grub and the kernel
has always been to not mess with the framebuffer until
there is some text (any text) to output and then show
that text immediately.

I do not think that deviating from this design is a good
idea.

Regards,

Hans



>>>>> 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>
>>>>> ---
>>>>>  drivers/video/fbdev/core/fbcon.c | 32 +++++++++++++++++++++++++++++---
>>>>>  1 file changed, 29 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>>>>> index 63af6ab034..5b9f7635f7 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"
>>>>> @@ -146,6 +147,7 @@ static inline void fbcon_map_override(void)
>>>>>  
>>>>>  #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>>>>  static bool deferred_takeover = true;
>>>>> +static int initial_console = -1;
>>>>>  #else
>>>>>  #define deferred_takeover false
>>>>>  #endif
>>>>> @@ -3341,7 +3343,7 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>>>>>  	console_unlock();
>>>>>  }
>>>>>  
>>>>> -static struct notifier_block fbcon_output_nb;
>>>>> +static struct notifier_block fbcon_output_nb, fbcon_switch_nb;
>>>>>  static DECLARE_WORK(fbcon_deferred_takeover_work, fbcon_register_existing_fbs);
>>>>>  
>>>>>  static int fbcon_output_notifier(struct notifier_block *nb,
>>>>> @@ -3358,6 +3360,21 @@ static int fbcon_output_notifier(struct notifier_block *nb,
>>>>>  
>>>>>  	return NOTIFY_OK;
>>>>>  }
>>>>> +
>>>>> +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) {
>>>>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>>> +		dummycon_register_output_notifier(&fbcon_output_nb);
>>>>> +	}
>>>>> +
>>>>> +	return NOTIFY_OK;
>>>>> +}
>>>>>  #endif
>>>>>  
>>>>>  static void fbcon_start(void)
>>>>> @@ -3370,7 +3387,14 @@ static void fbcon_start(void)
>>>>>  
>>>>>  	if (deferred_takeover) {
>>>>>  		fbcon_output_nb.notifier_call = fbcon_output_notifier;
>>>>> -		dummycon_register_output_notifier(&fbcon_output_nb);
>>>>> +		fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
>>>>> +		initial_console = fg_console;
>>>>> +
>>>>> +		if (cmdline_find_option_bool(boot_command_line, "splash"))
>>>>> +			dummycon_register_switch_notifier(&fbcon_switch_nb);
>>>>> +		else
>>>>> +			dummycon_register_output_notifier(&fbcon_output_nb);
>>>>> +
>>>>>  		return;
>>>>>  	}
>>>>>  #endif
>>>>> @@ -3417,8 +3441,10 @@ 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);
>>>>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>>> +	}
>>>>>  	console_unlock();
>>>>>  
>>>>>  	cancel_work_sync(&fbcon_deferred_takeover_work);
>>>>
>>>
>>
> 

Re: [PATCH 2/2] fbcon: Defer console takeover for splash screens to first switch

[Mario Limonciello]

On 2/28/2024 05:54, Hans de Goede wrote:
> Hi Daniel,
> 
> On 2/28/24 03:00, Daniel van Vugt wrote:
>> On 27/2/24 21:47, Hans de Goede wrote:
> 
> <snip>
> 
>> I think some boot failures also take you to the grub menu automatically next time?
> 
> In Fedora all boot failures will unhide the grub menu on
> the next boot. This unfortunately relies on downstream changes
> so I don't know what Ubuntu does here.
> 
> <snip>
> 
>>>>> The kernel itself will be quiet as long as you set
>>>>> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 Ubuntu atm has set this
>>>>> to 4 which means any kernel pr_err() or dev_err()
>>>>> messages will get through and since there are quite
>>>>> a few false positives of those Ubuntu really needs
>>>>> to set CONFIG_CONSOLE_LOGLEVEL_QUIET=3 to fix part of:
>>>>> https://bugs.launchpad.net/bugs/1970069
>>>>
>>>> Incorrect. In my testing some laptops needed log level as low as 2 to go quiet.
>>>> And the Ubuntu kernel team is never going to fix all those for non-sponsored
>>>> devices.
>>>
>>> Notice that atm Ubuntu's kernel is using the too high
>>> CONFIG_CONSOLE_LOGLEVEL_QUIET=4 with
>>> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 getting any errors logged
>>> to the console should be very very rare.
>>>
>>> The only thing I can think of is if the kernel oopses
>>> / WARN()s early on but the cause is innocent enough
>>> that the boot happily continues.
>>>
>>> In that case actually showing the oops/WARN() is a good
>>> thing.
>>>
>>> For all the years Fedora has had flickerfree boot I have
>>> seen zero bug reports about this. If you have examples
>>> of this actually being a problem please file bugs for
>>> them (launchpad or bugzilla.kernel.org is fine) and
>>> then lets take a look at those bugs and fix them.
>>>
>>> These should be so rare that I'm not worried about this
>>> becoming a never ending list of bugs (unlike pr_err() /
>>> dev_err() messages of which there are simply too many).
>>
>> I personally own many laptops with so many different boot messages that it's
>> overwhelming for me already to report bugs for each of them. Hence this patch.
>>
>> Also I don't own all the laptops in the world, so fixing all the errors just
>> for my collection wouldn't solve all cases. Whereas this patch does.
> 
> Almost all of those boot messages are because Ubuntu has
> set CONFIG_CONSOLE_LOGLEVEL_QUIET too high. Once that is fixed
> there should be very little of not no messages left.
> 
> I too own many laptops and I'm not seeing this issue on
> any of them.
> 
> You claim you are still seeing errors with
> CONFIG_CONSOLE_LOGLEVEL_QUIET=3 yet you have not provided
> a single example!
> 
>>> Sorry, but your real problem here seems to be your
>>> noisy downstream systemd patch. I'm not going to ack
>>> a kernel patch which I consider a bad idea because
>>> Ubuntu has a non standard systemd patch which is
>>> to trigger happy with spamming the console.
>>
>> Indeed the systemd patch is a big problem. We seem to have had it for 9 years
>> or so. I only just discovered it recently and would love to drop it, but was
>> told we can't. Its main problem is that it uses the console as a communication
>> pipe to plymouth. So simply making it less noisy isn't possible without
>> disabling its functionality. It was seemingly intended to run behind the
>> splash, but since it does fsck it tends to run before the splash (because DRM
>> startup takes a few more seconds).

This comes back to what I was saying before - Ubuntu (and anyone else 
that wants a flicker free boot for that matter) should adopt simpledrm.

When simpledrm is compiled into the kernel DRM will be up long before 
the splash screen comes up.  When drivers do fastboot (Intel) or 
seamless (AMD) handoff you /should/ be able to get the splash screen 
without a modeset.

I think between doing that and changing the default log level not to 
show console err messages will go a long way.

If there is a concern that people need to see those; how about changing 
the kernel command line for the recovery kernel so that they only come 
up in the recovery kernel?

> 
> This does indeed sound like it is a non trivial problem to fix,
> but that is still not a good reason to add this (IMHO) hack
> to the kernel.
> 
> The issue deferred fbcon takeover was designed to fix is that
> the fbcon would mess up the framebuffer contents even if
> nothing was ever logged to the console.
> 
> The whole idea being that to still have the fbcon come up
> as soon as there are any messages.
> 
> Actively hiding messages was never part of the design, so
> this is still a NACK from me.
> 
> Also note that this matches how things work in grub
> and shim when I first implemented flickerfree boot
> I also had to patch shim and grub to not make EFI
> text output protocol calls (including init()) until
> they actually had some text to show.
> 
> So the whole design here for shim, grub and the kernel
> has always been to not mess with the framebuffer until
> there is some text (any text) to output and then show
> that text immediately.
> 
> I do not think that deviating from this design is a good
> idea.
> 
> Regards,
> 
> Hans
> 
> 
> 
>>>>>> 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>
>>>>>> ---
>>>>>>   drivers/video/fbdev/core/fbcon.c | 32 +++++++++++++++++++++++++++++---
>>>>>>   1 file changed, 29 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>>>>>> index 63af6ab034..5b9f7635f7 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"
>>>>>> @@ -146,6 +147,7 @@ static inline void fbcon_map_override(void)
>>>>>>   
>>>>>>   #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
>>>>>>   static bool deferred_takeover = true;
>>>>>> +static int initial_console = -1;
>>>>>>   #else
>>>>>>   #define deferred_takeover false
>>>>>>   #endif
>>>>>> @@ -3341,7 +3343,7 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>>>>>>   	console_unlock();
>>>>>>   }
>>>>>>   
>>>>>> -static struct notifier_block fbcon_output_nb;
>>>>>> +static struct notifier_block fbcon_output_nb, fbcon_switch_nb;
>>>>>>   static DECLARE_WORK(fbcon_deferred_takeover_work, fbcon_register_existing_fbs);
>>>>>>   
>>>>>>   static int fbcon_output_notifier(struct notifier_block *nb,
>>>>>> @@ -3358,6 +3360,21 @@ static int fbcon_output_notifier(struct notifier_block *nb,
>>>>>>   
>>>>>>   	return NOTIFY_OK;
>>>>>>   }
>>>>>> +
>>>>>> +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) {
>>>>>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>>>> +		dummycon_register_output_notifier(&fbcon_output_nb);
>>>>>> +	}
>>>>>> +
>>>>>> +	return NOTIFY_OK;
>>>>>> +}
>>>>>>   #endif
>>>>>>   
>>>>>>   static void fbcon_start(void)
>>>>>> @@ -3370,7 +3387,14 @@ static void fbcon_start(void)
>>>>>>   
>>>>>>   	if (deferred_takeover) {
>>>>>>   		fbcon_output_nb.notifier_call = fbcon_output_notifier;
>>>>>> -		dummycon_register_output_notifier(&fbcon_output_nb);
>>>>>> +		fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
>>>>>> +		initial_console = fg_console;
>>>>>> +
>>>>>> +		if (cmdline_find_option_bool(boot_command_line, "splash"))
>>>>>> +			dummycon_register_switch_notifier(&fbcon_switch_nb);
>>>>>> +		else
>>>>>> +			dummycon_register_output_notifier(&fbcon_output_nb);
>>>>>> +
>>>>>>   		return;
>>>>>>   	}
>>>>>>   #endif
>>>>>> @@ -3417,8 +3441,10 @@ 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);
>>>>>> +		dummycon_unregister_switch_notifier(&fbcon_switch_nb);
>>>>>> +	}
>>>>>>   	console_unlock();
>>>>>>   
>>>>>>   	cancel_work_sync(&fbcon_deferred_takeover_work);
>>>>>
>>>>
>>>
>>
>