All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-efi@vger.kernel.org, linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	dri-devel@lists.freedesktop.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH 0/2] efifb: Copy the ACPI BGRT boot graphics to the
Date: Mon, 18 Jun 2018 11:23:06 +0200	[thread overview]
Message-ID: <20180618092306.GF22478@phenom.ffwll.local> (raw)
In-Reply-To: <20180617153235.16219-1-hdegoede@redhat.com>

On Sun, Jun 17, 2018 at 05:32:33PM +0200, Hans de Goede wrote:
> Hi All,
> 
> Here is a patch-set to make sure that the efifb contains the boot
> graphics from the ACPI BGRT extension when the kernel is configured
> to use the (new) deferred fbcon console takeover support.
> 
> Let me explain why this is desirable (same reason as for the deferred
> fbcon console takeover support itself):
> 
> Various (desktop oriented) Linux distributions have spend a lot of time
> to not show way too technial boot messages to end users during bootup.
> What we would really like for the boot experience is something like
> MacOS X / Windows 10 do. The (EFI) firmware boots up a logo and we
> leave that in place until the login-manager (e.g. gdm) starts and then
> the login-manager takes over the framebuffer including the current logo
> contents and fades that into the login screen.
> 
> The deferred fbcon console takeover (combined with shim and grub)
> patches makes the desired boot experience possible, but this assumes
> that the firmware starts shim with the framebuffer containing the
> boot graphics. This is not always the case, this patch ensures that the
> boot graphics are in place.
> 
> Since the bgrt.status field is not exactly reliable, this commit simply
> always copies over the bootgraphics. If they are already there this
> effectively is a no-op.
> 
> The first patch in this series makes a trivial change to
> drivers/firmware/efi/efi-bgrt.c, dropping __initdata from bgrt_image_size.
> 
> Ard, since the second patch depends on the first and the change is
> really trivial, can we please have your ack for merging the efi-bgrt.c
> change through the fbdev tree?

Random side-comment ... plans to roll out the same for drm drivers? With
the client infrastructure Noralf is working on doing that should be fairly
straight-forward. Interim step would be to add it to the shared fbdev
emulation layer (but that's a bit a hack, and precludes the use of this on
fbcon-less systems).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-efi@vger.kernel.org, linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	dri-devel@lists.freedesktop.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH 0/2] efifb: Copy the ACPI BGRT boot graphics to the
Date: Mon, 18 Jun 2018 09:23:06 +0000	[thread overview]
Message-ID: <20180618092306.GF22478@phenom.ffwll.local> (raw)
In-Reply-To: <20180617153235.16219-1-hdegoede@redhat.com>

On Sun, Jun 17, 2018 at 05:32:33PM +0200, Hans de Goede wrote:
> Hi All,
> 
> Here is a patch-set to make sure that the efifb contains the boot
> graphics from the ACPI BGRT extension when the kernel is configured
> to use the (new) deferred fbcon console takeover support.
> 
> Let me explain why this is desirable (same reason as for the deferred
> fbcon console takeover support itself):
> 
> Various (desktop oriented) Linux distributions have spend a lot of time
> to not show way too technial boot messages to end users during bootup.
> What we would really like for the boot experience is something like
> MacOS X / Windows 10 do. The (EFI) firmware boots up a logo and we
> leave that in place until the login-manager (e.g. gdm) starts and then
> the login-manager takes over the framebuffer including the current logo
> contents and fades that into the login screen.
> 
> The deferred fbcon console takeover (combined with shim and grub)
> patches makes the desired boot experience possible, but this assumes
> that the firmware starts shim with the framebuffer containing the
> boot graphics. This is not always the case, this patch ensures that the
> boot graphics are in place.
> 
> Since the bgrt.status field is not exactly reliable, this commit simply
> always copies over the bootgraphics. If they are already there this
> effectively is a no-op.
> 
> The first patch in this series makes a trivial change to
> drivers/firmware/efi/efi-bgrt.c, dropping __initdata from bgrt_image_size.
> 
> Ard, since the second patch depends on the first and the change is
> really trivial, can we please have your ack for merging the efi-bgrt.c
> change through the fbdev tree?

Random side-comment ... plans to roll out the same for drm drivers? With
the client infrastructure Noralf is working on doing that should be fairly
straight-forward. Interim step would be to add it to the shared fbdev
emulation layer (but that's a bit a hack, and precludes the use of this on
fbcon-less systems).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  parent reply	other threads:[~2018-06-18  9:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-17 15:32 [PATCH 0/2] efifb: Copy the ACPI BGRT boot graphics to the Hans de Goede
2018-06-17 15:32 ` Hans de Goede
2018-06-17 15:32 ` [PATCH 1/2] efi/bgrt: Drop __initdata from bgrt_image_size Hans de Goede
2018-06-17 15:32   ` Hans de Goede
2018-06-18  6:42   ` Ard Biesheuvel
2018-06-18  6:42     ` Ard Biesheuvel
2018-06-17 15:32 ` [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer Hans de Goede
2018-06-17 15:32   ` Hans de Goede
2018-06-18  7:36   ` Ard Biesheuvel
2018-06-18  7:36     ` Ard Biesheuvel
2018-06-18  8:30     ` Hans de Goede
2018-06-18  8:30       ` Hans de Goede
2018-06-18  8:43       ` Ard Biesheuvel
2018-06-18  8:43         ` Ard Biesheuvel
2018-06-18  9:13         ` Hans de Goede
2018-06-18  9:13           ` Hans de Goede
2018-06-18 10:43           ` Ard Biesheuvel
2018-06-18 10:43             ` Ard Biesheuvel
2018-06-18  8:53   ` Môshe van der Sterre
2018-06-18  8:53     ` Môshe van der Sterre
2018-06-18  9:08     ` Hans de Goede
2018-06-18  9:08       ` Hans de Goede
2018-06-18  9:23 ` Daniel Vetter [this message]
2018-06-18  9:23   ` [PATCH 0/2] efifb: Copy the ACPI BGRT boot graphics to the Daniel Vetter
2018-06-18  9:30   ` Hans de Goede
2018-06-18  9:30     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180618092306.GF22478@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ard.biesheuvel@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.