On Sat, Mar 22, 2025 at 8:40 AM Steven Harms (High-Security Mail) < sgha...@stevengharms.com> wrote:
> Thanks for the reply and its consideration. My most-desired outcome would > be to boot my system: bios screen -> boot_mute screen (either of custom > choice, solid black, FreeBSD word-logo) -> login. > You want to load an image in the loader, have the kernel not disturb it (or at least re-load it) and then have X11/Wayland start? With syscons/splash, you could switch the virtual video terminal from the splash screen to the kernel / rc output if things were taking too long. If vt isn't doing that yet, we should see what's in the way... Or do you really want a login: prompt on ttyv0? Muting rc output is different, and needs a different option to enable. It doesn't go to the console exactly (in the same sense as kernel messages go to the console), so it shouldn't be controlled by RB_MUTE. If you want to head in this direction, I'd think it would be better to just have a real /dev/null console rather than trying to fake it with RB_MUTE which has some unfortunate historical baggage. If you rarely want silence to the login prompt, we likely need to find a way to redirect the console output to a second screen or something. I thought we had a null console, but that appears to be only in the boot loader. The rc output goes to the first console in the list of all the consoles since that's what /dev/console is connected to. One much wanted, often started but not finished project is to actually make /dev/console connected to all the consoles together. Alternatively said, I want nothing of beastie or beastie orb. And I don’t > care about kernel problems screen output OR RC startup output. > > I do my kernel builds on old hardware — using FreeBSD to help with giving > old machines new life / longer life is a contribution I can make to > reducing electronic waste. I have a build running right now so I can’t > double check the language / versioning in the man pages, but will update > later today after I install the world. > Yea, there be dragons here, and there's a very long history that was imperfectly replicated with vt when it it went in due to the size of rewriting the console and lots of details that were under documented and/or ignored from ignorance (the bell frequency is another example we had crop up recently). It would be good > On Sat, Mar 22, 2025 at 03:02, Emmanuel Vadot <m...@bidouilliste.com > <On+Sat,+Mar+22,+2025+at+03:02,+Emmanuel+Vadot+%3C%3Ca+href=>> wrote: > > > Hi, > > On Fri, 21 Mar 2025 22:13:29 +0000 > "Steven Harms (High-Security Mail)" <sgha...@stevengharms.com> wrote: > > > Folks, > > > > I am attempting to figure out what boot_mute wants me to do. I'm trying > to make a "laptop guide" and I'm confused. I'm not a C programmer at this > scale of sophistication so there's a decent chance I'm foolishly making an > error, but current is not doing what I expect. > > > > - boot_mute doesn't appear in [loader.conf(8)][1] > > Indeed, this sould be fixed :) > > > - In the defaults/loader.conf file it [appears][2] and says: that it > exists to mute the console. I daresay that it's doing more than that, > because activating it puts a logo + beastie orb on the screen. Question: > Should the comment be updated? > > It shouldn't put the orb on the top of the screen, this is controlled > by kern.vt.splash_cpu which defaults to 0 > > > - The only other mention of boot_mute is on the line that specifies that > the overlay image can be controlled through configuration of the [splash] > value implying that instead of using the encoded array of unsigned char in > the kernel at > https://github.com/freebsd/freebsd-src/blob/main/sys/dev/vt/logo/logo_beastie.c. > Whoa! A nice configurable option? Nice. Looking at the git history on that > file it appears to be part of splash(4). And /that/ document says ..."work > with syscons(4) only". OK so maybe that comment in defaults also needs > updating? Because... > > The splash(4) man pages was updated to reflect this, are you looking > at an older revision of the man page ? > > > - My impression is that vt(4) is the way forward at present which means > that I was following a bad path and we're /back/ to using the [in-kernel > defined image][3] for the splash screen that's triggered by boot_mute? I > really don't understand the image packing as chars well enough to reverse > how to create a BMP from an array of hex values, but, eh...is this the one > that's being shown? Seems like it. There's also quite a bit of logic inside > of sys/dev/vt/vt_cpulogos.c[3] that suggests that it's trying to use arrays > of chars as overlay. > > No need to create an image embedded in kernel, with vt(4) you can load > a png image. > > > OK, so AFAICT, there are two terminal rendering systems, > under-/mis-documented loader.conf flags, and two places where images are > defined: in the vt device directory and the images/ directory. Question: > Can anyone confirm / deny my assessment? > > Looks correct yes. > > > After all that I'm still a bit confused as to what the expected/desired > behavior is. Can anyone help me figure out what the desired behavior is > (and maybe I can update the comments)? My current plan is to turn the array > into 0x00 and see what happens, but I'd like to know how I can turn the > results of that experiment into a patch. > > What are you trying to do exactly ? > > > Best, > > > > Steven > > > > [1]: > https://github.com/freebsd/freebsd-src/blob/main/stand/defaults/loader.conf.5 > > [2]: > https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867e4084bafe368c47f6c038/stand/defaults/loader.conf#L134 > > [splash]: > https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867e4084bafe368c47f6c038/stand/defaults/loader.conf#L30 > > [3]: > https://github.com/freebsd/freebsd-src/blob/main/sys/dev/vt/vt_cpulogos.c#L79-L91 > > --- > > > > Public Key: 22BE39E2FA68D8BA8DC4B43A55A16D8CE2B036DE > > > > Messages from this account are considered the best-secured and most > reliable. Send information regarding health, wealth, or requiring higher > standards of security to this address. > > > > Sent with [Proton Mail](https://proton.me/mail/home) secure email. > > Cheers, > > -- > Emmanuel Vadot <m...@bidouilliste.com> <m...@freebsd.org> > >
