[REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"

[REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"

[David Herrmann]

Hey

Since this commit:

    34db50e55656 efifb: Copy the ACPI BGRT

the kernel will override boot-splashs unasked. This breaks the
graphical boot-process on our setups. In particular, we have a setup
where an efi-boot-entry draws the early boot-splash on-screen, then
hands-over to the linux-kernel + initrd. The boot-splash daemon in the
initrd then takes over control of possible animations.

With the mentioned commit compiled in, the kernel will redraw the
firmware logo on screen at a random time without any way to intervene.

What is the intention of this commit? Why is the kernel re-drawing the
firmware logo unasked? If someone during the boot-process draws
content on the screen, I would prefer if the kernel does not clear
that on driver load.

Can we either provide an option to disable this feature, or revert the commit?

Thanks
David

Re: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"

[Bartlomiej Zolnierkiewicz]

Hi,

On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
> Hey
> 
> Since this commit:
> 
>     34db50e55656 efifb: Copy the ACPI BGRT
> 
> the kernel will override boot-splashs unasked. This breaks the
> graphical boot-process on our setups. In particular, we have a setup
> where an efi-boot-entry draws the early boot-splash on-screen, then
> hands-over to the linux-kernel + initrd. The boot-splash daemon in the
> initrd then takes over control of possible animations.
> 
> With the mentioned commit compiled in, the kernel will redraw the
> firmware logo on screen at a random time without any way to intervene.

You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred
console takeover support introduced in v4,19-rc1). I assume that this
is intended?

> What is the intention of this commit? Why is the kernel re-drawing the
> firmware logo unasked? If someone during the boot-process draws
> content on the screen, I would prefer if the kernel does not clear
> that on driver load.

+/*
+ * If fbcon deffered console takeover is configured, the intent is for the
+ * framebuffer to show the boot graphics (e.g. vendor logo) until there is some
+ * (error) message to display. But the boot graphics may have been destroyed by
+ * e.g. option ROM output, detect this and restore the boot graphics.
+ */
+#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
+    defined CONFIG_ACPI_BGRT
...
+static void efifb_show_boot_graphics(struct fb_info *info)
...
+#else
+static inline void efifb_show_boot_graphics(struct fb_info *info) {}
+#endif

> Can we either provide an option to disable this feature, or revert the commit?

Hans?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"

[Hans de Goede]

Hi,

On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
>> Hey
>>
>> Since this commit:
>>
>>      34db50e55656 efifb: Copy the ACPI BGRT
>>
>> the kernel will override boot-splashs unasked. This breaks the
>> graphical boot-process on our setups. In particular, we have a setup
>> where an efi-boot-entry draws the early boot-splash on-screen, then
>> hands-over to the linux-kernel + initrd. The boot-splash daemon in the
>> initrd then takes over control of possible animations.
>>
>> With the mentioned commit compiled in, the kernel will redraw the
>> firmware logo on screen at a random time without any way to intervene.
> 
> You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred
> console takeover support introduced in v4,19-rc1). I assume that this
> is intended?
> 
>> What is the intention of this commit? Why is the kernel re-drawing the
>> firmware logo unasked? If someone during the boot-process draws
>> content on the screen, I would prefer if the kernel does not clear
>> that on driver load.
> 
> +/*
> + * If fbcon deffered console takeover is configured, the intent is for the
> + * framebuffer to show the boot graphics (e.g. vendor logo) until there is some
> + * (error) message to display. But the boot graphics may have been destroyed by
> + * e.g. option ROM output, detect this and restore the boot graphics.
> + */
> +#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
> +    defined CONFIG_ACPI_BGRT
> ...
> +static void efifb_show_boot_graphics(struct fb_info *info)
> ...
> +#else
> +static inline void efifb_show_boot_graphics(struct fb_info *info) {}
> +#endif
> 
>> Can we either provide an option to disable this feature, or revert the commit?
> 
> Hans?

We use the ACPI bgrt extension to get the logo to draw and then
draw it since some devices rely on the OS to draw it and otherwise we
just end up with a blackscreen when doing silent / flickerfree boot.

Ideally you would be able to get your vendor to put the logo in firmware
in the ACPI bgrt extension, then you also do not need to play any tricks
with an EFI binary drawing your own logo. But I can understand if you don't
have control over this, so you need to do this with the EFI binary trick.

I can also understand that you want to use deferred console takeover
in a setup like yours to avoid fbcon messing up what is on the display
during boot, that is exactly what it is for. So I think a reasonable
approach here is to add a kernel commandline option, say:

videoïifb:nobgrt

David, would that work for you?

Regards,

Hans

Re: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"

[David Herrmann]

Hey

On Mon, Sep 3, 2018 at 4:47 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
> >> Hey
> >>
> >> Since this commit:
> >>
> >>      34db50e55656 efifb: Copy the ACPI BGRT
> >>
> >> the kernel will override boot-splashs unasked. This breaks the
> >> graphical boot-process on our setups. In particular, we have a setup
> >> where an efi-boot-entry draws the early boot-splash on-screen, then
> >> hands-over to the linux-kernel + initrd. The boot-splash daemon in the
> >> initrd then takes over control of possible animations.
> >>
> >> With the mentioned commit compiled in, the kernel will redraw the
> >> firmware logo on screen at a random time without any way to intervene.
> >
> > You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred
> > console takeover support introduced in v4,19-rc1). I assume that this
> > is intended?
> >
> >> What is the intention of this commit? Why is the kernel re-drawing the
> >> firmware logo unasked? If someone during the boot-process draws
> >> content on the screen, I would prefer if the kernel does not clear
> >> that on driver load.
> >
> > +/*
> > + * If fbcon deffered console takeover is configured, the intent is for the
> > + * framebuffer to show the boot graphics (e.g. vendor logo) until there is some
> > + * (error) message to display. But the boot graphics may have been destroyed by
> > + * e.g. option ROM output, detect this and restore the boot graphics.
> > + */
> > +#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
> > +    defined CONFIG_ACPI_BGRT
> > ...
> > +static void efifb_show_boot_graphics(struct fb_info *info)
> > ...
> > +#else
> > +static inline void efifb_show_boot_graphics(struct fb_info *info) {}
> > +#endif
> >
> >> Can we either provide an option to disable this feature, or revert the commit?
> >
> > Hans?
>
> We use the ACPI bgrt extension to get the logo to draw and then
> draw it since some devices rely on the OS to draw it and otherwise we
> just end up with a blackscreen when doing silent / flickerfree boot.
>
> Ideally you would be able to get your vendor to put the logo in firmware
> in the ACPI bgrt extension, then you also do not need to play any tricks
> with an EFI binary drawing your own logo. But I can understand if you don't
> have control over this, so you need to do this with the EFI binary trick.
>
> I can also understand that you want to use deferred console takeover
> in a setup like yours to avoid fbcon messing up what is on the display
> during boot, that is exactly what it is for. So I think a reasonable
> approach here is to add a kernel commandline option, say:
>
> videoïifb:nobgrt
>
> David, would that work for you?

That would be perfect!

Thanks
David

Re: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"

[Hans de Goede]

Hi,

On 03-09-18 17:11, David Herrmann wrote:
> Hey
> 
> On Mon, Sep 3, 2018 at 4:47 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi,
>>>
>>> On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
>>>> Hey
>>>>
>>>> Since this commit:
>>>>
>>>>       34db50e55656 efifb: Copy the ACPI BGRT
>>>>
>>>> the kernel will override boot-splashs unasked. This breaks the
>>>> graphical boot-process on our setups. In particular, we have a setup
>>>> where an efi-boot-entry draws the early boot-splash on-screen, then
>>>> hands-over to the linux-kernel + initrd. The boot-splash daemon in the
>>>> initrd then takes over control of possible animations.
>>>>
>>>> With the mentioned commit compiled in, the kernel will redraw the
>>>> firmware logo on screen at a random time without any way to intervene.
>>>
>>> You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred
>>> console takeover support introduced in v4,19-rc1). I assume that this
>>> is intended?
>>>
>>>> What is the intention of this commit? Why is the kernel re-drawing the
>>>> firmware logo unasked? If someone during the boot-process draws
>>>> content on the screen, I would prefer if the kernel does not clear
>>>> that on driver load.
>>>
>>> +/*
>>> + * If fbcon deffered console takeover is configured, the intent is for the
>>> + * framebuffer to show the boot graphics (e.g. vendor logo) until there is some
>>> + * (error) message to display. But the boot graphics may have been destroyed by
>>> + * e.g. option ROM output, detect this and restore the boot graphics.
>>> + */
>>> +#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
>>> +    defined CONFIG_ACPI_BGRT
>>> ...
>>> +static void efifb_show_boot_graphics(struct fb_info *info)
>>> ...
>>> +#else
>>> +static inline void efifb_show_boot_graphics(struct fb_info *info) {}
>>> +#endif
>>>
>>>> Can we either provide an option to disable this feature, or revert the commit?
>>>
>>> Hans?
>>
>> We use the ACPI bgrt extension to get the logo to draw and then
>> draw it since some devices rely on the OS to draw it and otherwise we
>> just end up with a blackscreen when doing silent / flickerfree boot.
>>
>> Ideally you would be able to get your vendor to put the logo in firmware
>> in the ACPI bgrt extension, then you also do not need to play any tricks
>> with an EFI binary drawing your own logo. But I can understand if you don't
>> have control over this, so you need to do this with the EFI binary trick.
>>
>> I can also understand that you want to use deferred console takeover
>> in a setup like yours to avoid fbcon messing up what is on the display
>> during boot, that is exactly what it is for. So I think a reasonable
>> approach here is to add a kernel commandline option, say:
>>
>> videoïifb:nobgrt
>>
>> David, would that work for you?
> 
> That would be perfect!

Ok, I just send out a patch for this with you in the Cc.

Sorry for taking a bit long to write the patch.

Regards,

Hans