[coreboot - Bug #500] (New) libgfxinit bootsplash only supports jpeg and does not support extended resolutions
Issue #500 has been reported by Thierry Laurion.
---------------------------------------- Bug #500: libgfxinit bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500
* Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
WiP PoC: https://github.com/osresearch/heads/pull/1403
* Affected hardware: iGPU driven by libgfxinit * Affected OS: All ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB)
Issue #500 has been updated by Thierry Laurion.
https://paste.debian.net/1285804/ was proposed by alpernebbi
This created the same rear tearing I observed with fbwhiptail at the moment of drawing bootsplash then when trying to draw to fb when not under 1024x768.
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"`
---------------------------------------- Bug #500: libgfxinit bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1602
* Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
WiP PoC: https://github.com/osresearch/heads/pull/1403
* Affected hardware: iGPU driven by libgfxinit * Affected OS: All ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB)
Issue #500 has been updated by Thierry Laurion.
File signal-2023-07-13-171801.jpeg added File signal-2023-07-13-171757.jpeg added
Here are screen tearing when under native 1366x768. bootsplash and fbwhiptail output
---------------------------------------- Bug #500: libgfxinit bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1603
* Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
WiP PoC: https://github.com/osresearch/heads/pull/1403
* Affected hardware: iGPU driven by libgfxinit * Affected OS: All ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
Issue #500 has been updated by Thierry Laurion.
icon says
needs to use `bytes_per_line / 4` instead of `x_resolution` when calculating the address
from snippet above. Will try again tomorrow.
---------------------------------------- Bug #500: libgfxinit bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1604
* Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
WiP PoC: https://github.com/osresearch/heads/pull/1403
* Affected hardware: iGPU driven by libgfxinit * Affected OS: All ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
Issue #500 has been updated by Matt DeVillier.
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
---------------------------------------- Bug #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1605
* Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
WiP PoC: https://github.com/osresearch/heads/pull/1403
* Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
Issue #500 has been updated by Matt DeVillier.
editing the bug subject, affected hardware since there is no dependency on a specific GPU or display init method, only the framebuffer resolution
---------------------------------------- Bug #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1606
* Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
WiP PoC: https://github.com/osresearch/heads/pull/1403
* Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
Issue #500 has been updated by Martin Roth.
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.
---------------------------------------- Feature #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1607
* Author: Thierry Laurion * Status: New * Priority: Normal * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
WiP PoC: https://github.com/osresearch/heads/pull/1403
* Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
Issue #500 has been updated by Nico Huber.
Related links updated
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](https://review.coreboot.org/c/coreboot/+/76424) might help with the existing JPEG decoder. It probably needs some tuning, but could work in theory. Anyone with a compatible .jpg, please test :)
---------------------------------------- Feature #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1609
* Author: Thierry Laurion * Status: New * Priority: Normal * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
WiP PoC: https://github.com/osresearch/heads/pull/1403
Potential enhancement of the existing JPEG decoder: https://review.coreboot.org/c/coreboot/+/76424 * Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
Issue #500 has been updated by Nico Huber.
Related links updated
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](https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1...) 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)
---------------------------------------- Feature #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1610
* Author: Thierry Laurion * Status: New * Priority: Normal * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
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-1... * Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
Issue #500 has been updated by Thierry Laurion.
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.
@icon 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.
---------------------------------------- Feature #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1613
* Author: Thierry Laurion * Status: New * Priority: Normal * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
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-1... * Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
Issue #500 has been updated by Martin Roth.
Status changed from New to Resolved
---------------------------------------- Feature #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1694
* Author: Thierry Laurion * Status: Resolved * Priority: Normal * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * 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/659308eff53f39633ffad7...
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-1... * Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtT...
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/659308eff53f39633ffad7...) - 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-1...) - 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-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801.jpeg (350 KB)
-
Martin Roth -
Matt DeVillier
-
Nico Huber
-
Thierry Laurion