[PATCH v4 2/2] fbcon: Defer console takeover for splash screens to first switch
Mario Limonciello
mario.limonciello at amd.com
Thu Feb 22 16:25:27 UTC 2024
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 at amd.com>
>> Signed-off-by: Daniel van Vugt <daniel.van.vugt at 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 at 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.
More information about the dri-devel
mailing list