Project

General

Profile

Actions

Feature #500

closed

coreboot bootsplash only supports jpeg and does not support extended resolutions

Added by Thierry Laurion about 1 year ago. Updated 11 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
coreboot common code
Target version:
Start date:
07/13/2023
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
All using coreboot display init + bootsplash
Affected OS:
n/a

Description

For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtTc0IEVgQDycUJmB7PLulE?via=libera.chat&via=matrix.org&via=matrix.zerodao.gg

Short version:

  • libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768)
  • libgfxinit bootsplash through jpeg.c doesn't support native resolutions (1366x768)
  • libgfxinit bootsplash image creation requires voodoo skills explained at https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017
  • Basically, I do not think libgfxinit bootsplash is currently used otherwise there would be way more bug reports. Seabios is mostly used.
  • Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP and JPEG and is not 13yo.
  • Coreboot should permit stiching of compressed bmp by default and deprecate old jpeg.c in tree
  • By doing so, more people could promote coreboot directly from coreboot raminit (Heads currently does that)

Longer version:

  • OSes are attacking legacy BIOS mode for a while now, and the next steps are to deprecate DRM drivers in initrd
    • To phase DRM out, simplefb and simpledrm are promoted instead where final OS will be in charge of deploying bigger unified kernels containing/initrd which will contain the accelerated DRM and fb drivers
    • Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU requires to include i915drmfb, coreboot linux command lines hacks to have the FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb address to next kernel (see https://github.com/osresearch/heads/pull/1378)
    • Doing currently adds more then 500kb of in-kernel drivers, which bloats the firmware. In case of measured boot, that bigger payload needs to be measured prior of being read and jumped into (8-10 seconds under 5.10 kernel compared to 4-6 seconds under 4.14)
    • To have legacy BIOS survive this ecosystem attack against legacy boot, coreboot needs to push for a more generic way to provide a framebuffer (GOP/Native unified approach)
    • With libgfxinit/GOP/native gfx init and the kernel config adapted, linux can efficiently be used as a bootloader and be enabled by simplefb (https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3)
  • The part missing is having coreboot drive the framebuffer with a native size bootsplash as everyone else does so that the waiting time to boot in kernel/payload is not a scary moment, and that the bootsplash doesn't restrict the size of the framebuffer configured under coreboot nor limit the UX.

Actual state:

  • libgfxinit needs to have jpeg supported resolution to bootsplash (CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024)
  • libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg (https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg)
  • Problem is that doing so, the whole console is limited to that resolution showing black borders on each side of the screen to compensate (1366 != 1024, so (1366-1024)/2 is the loss pixel width on each side of the screen for 1366x764, same applying to all other resolutions since needs to be 4x4 for jpeg.c to do its job.

Desired state:

  • flat bmp support in native format just like seabios support, where coreboot compressed them prior of adding it into CBFS.
  • support for all crazy resolutions we currently have, not being stuck in 2000.
  • Be able to promote coreboot from raminit code.

Files

signal-2023-07-13-164022.jpeg (269 KB) signal-2023-07-13-164022.jpeg Thierry Laurion, 07/13/2023 10:46 PM
signal-2023-07-13-164047.jpeg (416 KB) signal-2023-07-13-164047.jpeg Thierry Laurion, 07/13/2023 10:46 PM
VID_20230713_154446.mp4 (3.78 MB) VID_20230713_154446.mp4 UX being limited Thierry Laurion, 07/13/2023 10:48 PM
signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171757.jpeg Thierry Laurion, 07/13/2023 11:18 PM
signal-2023-07-13-171801.jpeg (350 KB) signal-2023-07-13-171801.jpeg Thierry Laurion, 07/13/2023 11:18 PM
Actions #1

Updated by Thierry Laurion about 1 year ago

https://paste.debian.net/1285804/ was proposed by alpernebbi

This created the same screen tearing I observed with fbwhiptail at the moment of drawing bootsplash then when trying to draw to fb when not under 1024x76 resolution.

My coreboot config changed to support native resolution:
diff --git a/config/coreboot-x230-maximized.config b/config/coreboot-x230-maximized.config
index 13e6cfa8..5f9efab4 100644
--- a/config/coreboot-x230-maximized.config
+++ b/config/coreboot-x230-maximized.config
@@ -112,7 +112,7 @@ CONFIG_NO_POST=y
CONFIG_MAINBOARD_VENDOR="LENOVO"
CONFIG_CBFS_SIZE=0xBE4FFF
CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768
-CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024
+CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1366
CONFIG_MAX_CPUS=8
CONFIG_ONBOARD_VGA_IS_PRIMARY=y
CONFIG_DEVICETREE="devicetree.cb"

Updated by Thierry Laurion about 1 year ago

Here are screen tearing when under native 1366x768. bootsplash and fbwhiptail output

Actions #3

Updated by Thierry Laurion about 1 year ago

icon says

needs to use bytes_per_line / 4 instead of x_resolution when calculating the address

from snippet above. Will try again tomorrow.

Actions #4

Updated by Matt DeVillier about 1 year ago

  • Subject changed from libgfxinit bootsplash only supports jpeg and does not support extended resolutions to coreboot bootsplash only supports jpeg and does not support extended resolutions
  • Affected hardware changed from iGPU driven by libgfxinit to All using coreboot display init + bootsplash
  • Affected OS changed from All to n/a
Actions #5

Updated by Matt DeVillier about 1 year ago

editing the bug subject, affected hardware since there is no dependency on a specific GPU or display init method, only the framebuffer resolution

Actions #6

Updated by Martin Roth about 1 year ago

  • Tracker changed from Bug to Feature
  • Assignee deleted (Patrick Georgi)

Changing to a feature request and unassigning from Patrick.

I believe this is currently working as designed. It could definitely be extended, but I don't believe that the lack of those features should be considered a "bug".

If anyone wants to take on this work, please feel free to assign it to yourself.

Actions #7

Updated by Nico Huber about 1 year ago

  • Related links updated (diff)

I don't think there is a limitation to legacy resolutions. At least, I've never heard of one. So far the resolution had to match the .jpg and that had to be a multiple of 16 pixels, AIUI.

Until somebody takes on integrating any new decoder (SeaBIOS' doesn't seem to be compatible license wise), this patch might help with the existing JPEG decoder. It probably needs some tuning, but could work in theory. Anyone with a compatible .jpg, please test :)

Actions #8

Updated by Nico Huber about 1 year ago

  • Related links updated (diff)

Nico Huber wrote in #note-7:

It probably needs some tuning, but could work in theory. Anyone with a compatible .jpg, please test :)

Found ThePlexus in the description. Seems to work fine in QEMU :) (as far as the coreboot framebuffer driver works, odd resolutions like 1366x768 don't work, not sure if a bug in coreboot or QEMU or if the emulated hardware is not supposed to support it)

Actions #9

Updated by Thierry Laurion about 1 year ago

This is fixed with https://review.coreboot.org/c/coreboot/+/76424

Tested with native 1366x768 resolution under x230 and 1024x768 referred jpeg about created following https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/ guide.

@Nico Huber also suggested fix to fbwhiptail to https://source.puri.sm/firmware/fbwhiptail/-/commits/simplefb_shadow/ which also fixed the screen tearing:

user@heads-tests-deb12:~/heads$ cat patches/fbwhiptail-90125e76c887c87ef4eee02f857e482cd6320195.patch 
--- ./cairo_linuxfb.c   2023-07-07 09:57:43.000000000 -0400
+++ ./cairo_linuxfb.c   2023-07-14 10:18:16.541000000 -0400
@@ -183,8 +183,7 @@
       CAIRO_FORMAT_RGB24,
       device->fb_vinfo.xres,
       device->fb_vinfo.yres_virtual,
-      cairo_format_stride_for_width(CAIRO_FORMAT_ARGB32,
-          device->fb_vinfo.xres));
+      device->fb_finfo.line_length);
   cairo_surface_set_user_data(surface, &user_data_key, device,
       &cairo_linuxfb_surface_destroy);

Thanks a bunch! You are amazing guys.
Added those in PoC for Heads + simplefb here https://github.com/osresearch/heads/pull/1403

will keep looking for efifb changes.

Actions #10

Updated by Martin Roth 11 months ago

  • Status changed from New to Resolved
Actions

Also available in: Atom PDF