Boot time splash screen does not work in vt at all no matter which vt mode is enabled. Seems that these splash screen options are ignored by vt. These work just fine in 10.X releases. Using this in loader.conf splash_bmp_load="YES" bitmap_name="/boot/splash.bmp" bitload_load="YES"
I think that Adrian Chadd was working on something related to this issue, but I don't know what sort of state it's in ATM.
I was just wondering if there has been any work done on this in the last year. Boot splash hasn't worked since the 10.x series, and 12.0-RELEASE is due out soon. I noticed that a lot of vt(4) work is planned for the 13-CURRENT series (according to bug 231027). Is it possible this bug could get some renewed attention along with the other vt work for 13?
I've started working on this feature. I'm happy to listen to your suggestions & ideas. Project's wiki: https://wiki.freebsd.org/MateuszPiotrowski/ImproveVtSplashScreenSupport
(In reply to Mateusz Piotrowski from comment #3) Re: the wiki page, vt has some support for colors, and vt cpu-count logos work on current (logo_beastie.c, kern.vt.splash_cpu="1"). I don't know about the full-screen splash screen (logo_freebsd.c, DEV_SPLASH + !TEXTMODE). It's possible the logo is rendered correctly and then immediately overwritten? I don't see any logic to prevent that. The cpu logos use an RLE scheme to compress slightly from uncompressed bitmap. They use a 8-color VGA palette and draw using the vd_setpixel routine (which takes a modified VGA color index).
*** Bug 233355 has been marked as a duplicate of this bug. ***
I am not working on this feature currently. Return to the pool.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/doc/commit/?id=ecc2b1a6a0c0979474f6bdb2c59cafbaa33dd958 commit ecc2b1a6a0c0979474f6bdb2c59cafbaa33dd958 Author: Chris Rees <crees@FreeBSD.org> AuthorDate: 2021-03-17 17:00:03 +0000 Commit: Chris Rees <crees@FreeBSD.org> CommitDate: 2021-03-17 17:00:03 +0000 Remove instructions on boot splash screens They haven't worked for years in the way described, and following further advice online to enable VESA results in an unbootable system! It can be put back when vt(4) supports them. PR: kern/210432 .../content/en/books/handbook/boot/_index.adoc | 47 ---------------------- 1 file changed, 47 deletions(-)
^Triage: assign to committer that resolved.
As this is a removed feature rather than a bug, this shouldn't remain open. Discussion of adding this again is on the -current mailing list.