From: Hans de Goede <hdegoede@redhat.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: "open list:EFIFB FRAMEBUFFER DRIVER" <linux-fbdev@vger.kernel.org>, linux-efi <linux-efi@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Subject: Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer Date: Mon, 18 Jun 2018 10:30:08 +0200 [thread overview] Message-ID: <08e59509-d790-b33d-99f4-20410726279f@redhat.com> (raw) In-Reply-To: <CAKv+Gu8xHTtHGi=WXHchk+avwResQR2sWgTWw-PyOD8ewkCV_w@mail.gmail.com> Hi, On 18-06-18 09:36, Ard Biesheuvel wrote: > Hallo Hans, > > On 17 June 2018 at 17:32, Hans de Goede <hdegoede@redhat.com> wrote: >> On systems where fbcon is configured for deferred console takeover, the >> intend is for the framebuffer to show the boot graphics (e.g a vendor >> logo) until some message (e.g. an error) is printed or a graphical >> session takes over. >> >> Some firmware however relies on the OS to show the boot graphics >> (indicated by bgrt_tab.status being 0) and the boot graphics may have >> been destroyed by e.g. the grub boot menu. >> >> This patch adds support to efifb to show the boot graphics and >> automatically enables this when fbcon is configured for deferred >> console takeover. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > I have tested this code on ARM QEMU/mach-virt, and with a little tweak > (which I will post separately), the code works as expected, i.e., it > redraws the boot logo based on the contents of the BGRT table. That is great. > However, what it doesn't do is clear the screen, which means the logo > is drawn on top of whatever the boot environment left behind, and I > end up with something like this. > > http://people.linaro.org/~ard.biesheuvel/mach-virt-bgrt-logo-redrawn.png Hmm, less great. I'm not sure how to deal with this, on x86 it is more or less guaranteed that the screen is already cleared when we load and clearing a 4k screen means writing about 32MB, which I guess with modern RAM speeds is not that bad actually. I see that you got this picture by manual booting from the EFI shell, in what state does the firmware / bootloader normally leave the framebuffer? I'm asking because if normally it is either cleared to black, or already showing the logo I wonder if we should take the (small) penalty of clearing ? Given that we are talking about only 32 MB I could do a v2 which just memsets the rest of the screen to 0. So we get: for (y= 0; y < height; y++) { if (line_part_of_bgrt) { memset(left-of-bgrt); draw_bgrt_line(y); memset(right-of-bgrt); } else { memset(line); } } Note I've deliberately done the if on a per line base to keep the actual blit part of the loop efficient and without any extra conditionals in there. I also don't simply first memset the entire fb to 0 to avoid a flash / tearing if the bgrt image is already in place (which happens often on x86). Implementing this is easy and as said the extra execution time should be quite small, still I wonder what others think about this? I'm leaning towards doing the clearing / memsets since I've seen some firmwares leave some artifacts from not completely clearing things like a "Press F2 to enter setup" message, missing a few pixels and leaving those on screen. Regards, Hans _______________________________________________ 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: Hans de Goede <hdegoede@redhat.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: "open list:EFIFB FRAMEBUFFER DRIVER" <linux-fbdev@vger.kernel.org>, linux-efi <linux-efi@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Subject: Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer Date: Mon, 18 Jun 2018 08:30:08 +0000 [thread overview] Message-ID: <08e59509-d790-b33d-99f4-20410726279f@redhat.com> (raw) In-Reply-To: <CAKv+Gu8xHTtHGi=WXHchk+avwResQR2sWgTWw-PyOD8ewkCV_w@mail.gmail.com> Hi, On 18-06-18 09:36, Ard Biesheuvel wrote: > Hallo Hans, > > On 17 June 2018 at 17:32, Hans de Goede <hdegoede@redhat.com> wrote: >> On systems where fbcon is configured for deferred console takeover, the >> intend is for the framebuffer to show the boot graphics (e.g a vendor >> logo) until some message (e.g. an error) is printed or a graphical >> session takes over. >> >> Some firmware however relies on the OS to show the boot graphics >> (indicated by bgrt_tab.status being 0) and the boot graphics may have >> been destroyed by e.g. the grub boot menu. >> >> This patch adds support to efifb to show the boot graphics and >> automatically enables this when fbcon is configured for deferred >> console takeover. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > I have tested this code on ARM QEMU/mach-virt, and with a little tweak > (which I will post separately), the code works as expected, i.e., it > redraws the boot logo based on the contents of the BGRT table. That is great. > However, what it doesn't do is clear the screen, which means the logo > is drawn on top of whatever the boot environment left behind, and I > end up with something like this. > > http://people.linaro.org/~ard.biesheuvel/mach-virt-bgrt-logo-redrawn.png Hmm, less great. I'm not sure how to deal with this, on x86 it is more or less guaranteed that the screen is already cleared when we load and clearing a 4k screen means writing about 32MB, which I guess with modern RAM speeds is not that bad actually. I see that you got this picture by manual booting from the EFI shell, in what state does the firmware / bootloader normally leave the framebuffer? I'm asking because if normally it is either cleared to black, or already showing the logo I wonder if we should take the (small) penalty of clearing ? Given that we are talking about only 32 MB I could do a v2 which just memsets the rest of the screen to 0. So we get: for (y= 0; y < height; y++) { if (line_part_of_bgrt) { memset(left-of-bgrt); draw_bgrt_line(y); memset(right-of-bgrt); } else { memset(line); } } Note I've deliberately done the if on a per line base to keep the actual blit part of the loop efficient and without any extra conditionals in there. I also don't simply first memset the entire fb to 0 to avoid a flash / tearing if the bgrt image is already in place (which happens often on x86). Implementing this is easy and as said the extra execution time should be quite small, still I wonder what others think about this? I'm leaning towards doing the clearing / memsets since I've seen some firmwares leave some artifacts from not completely clearing things like a "Press F2 to enter setup" message, missing a few pixels and leaving those on screen. Regards, Hans
next prev parent reply other threads:[~2018-06-18 8:30 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 [this message] 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 ` [PATCH 0/2] efifb: Copy the ACPI BGRT boot graphics to the Daniel Vetter 2018-06-18 9:23 ` 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=08e59509-d790-b33d-99f4-20410726279f@redhat.com \ --to=hdegoede@redhat.com \ --cc=ard.biesheuvel@linaro.org \ --cc=b.zolnierkie@samsung.com \ --cc=dri-devel@lists.freedesktop.org \ --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: linkBe 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.