Feature #500
closedcoreboot bootsplash only supports jpeg and does not support extended resolutions
0%
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
Related links
https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c
https://git.seabios.org/seabios.git/
https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3#diff-816b79cd9a1192fa8cf78b9737f0d3fed5a943a0d2c952da591f8a2446edc1db
WiP PoC: https://github.com/osresearch/heads/pull/1403
Potential enhancement of the existing JPEG decoder:
https://review.coreboot.org/c/coreboot/+/76424
Image compatible with coreboot's current JPEG decoder:
https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg
Updated by Thierry Laurion over 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 over 1 year ago
- File signal-2023-07-13-171801.jpeg signal-2023-07-13-171801.jpeg added
- File signal-2023-07-13-171757.jpeg signal-2023-07-13-171757.jpeg added
Here are screen tearing when under native 1366x768. bootsplash and fbwhiptail output
Updated by Thierry Laurion over 1 year ago
icon says
needs to use
bytes_per_line / 4instead ofx_resolutionwhen calculating the address
from snippet above. Will try again tomorrow.
Updated by Matt DeVillier over 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
Updated by Matt DeVillier over 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
Updated by Martin Roth over 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.
Updated by Nico Huber over 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 :)
Updated by Nico Huber over 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)
Updated by Thierry Laurion over 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.