From nobody Sat Mar 22 16:02:34 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZKkc75Fr5z5qf8V for ; Sat, 22 Mar 2025 16:02:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZKkc73PbYz3xkV for ; Sat, 22 Mar 2025 16:02:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-301918a4e3bso5562905a91.3 for ; Sat, 22 Mar 2025 09:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1742659366; x=1743264166; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kEKK4HbkkB5Mp1w4JgnYTRqa0iTjOXQD9CVDbufGdqo=; b=tIrBnSueZELvvvNKAM58H5F4OLOGu/p/NnqZcYKLg6/jA61lQ9ZCBNb95yavyEBE2D 8ZIYmj/wzsqI6kodzQsDHlfnoeswxKJ1KXGSTeyRkHhsB1juePKGjQYgPsuVaN8gR2Ka OLQyw7g+akeRMdraNqxpw94izB208uIFMVEAi6qinEb+AgTq8R/Lt3eUbQ32sEYBBUCj Ssq4LIe30auCS4h5lALvRWg1SPlFGPqUTWKF2BOvzApHFq9yW08whNc7Xxj/DvtiWSq3 cF+0cUo5B60RUnG54khBm+wlE2l+J/y81SihWIrRdCX+4VLCtJuSgDrMdJX8IfiZpG1N ii6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742659366; x=1743264166; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kEKK4HbkkB5Mp1w4JgnYTRqa0iTjOXQD9CVDbufGdqo=; b=YsrYuGkTp+P22shE1JOC+DKVIuKfhPo+Ue5ouKk5CCkfKZWyh9+dcagQbp3r2Uo1z5 F1pS5CdBjB5srj0RJH656PH8B/Mru5wtNnCLQHzkBvAGcBJN5/DJjvZgGy8xawwy3HLl 62MRpSGhaaI9nCYDVPyLNm1ZPC4Hh5hcvCBZG47tt7aSOJ8zUd13mkbudI2hnUMUvncJ 3tk0QCEbWafjt47tAkf7JzKwVOwrs67SerXN11DQpBXTkO6nHB45bi11bzw3MB8m1pUg rPOhRXgim//XenWo9sA/KqCw2YJIkIeHfxUXUEghoukSusykDxqLKqFkzP49sqykRp2u TOiQ== X-Forwarded-Encrypted: i=1; AJvYcCVsASLDKD3J1g6Epe0Hkzr/73dgei4zStEaoPuiKUrZi2ImxU929HpVlofLxItvtWdFRO/wfa+yfVcK4LteL/Y=@freebsd.org X-Gm-Message-State: AOJu0Yw+SYBlxopvk3auRD4Su2vF4Db/sPjFharfc+F8kgZ4MCQufePd iDeRCyCd4GBEuwGBnDxaUaxiOTl+Hf19aVhkE6tHfOi0AY5xN4rCtqFjT0Tm3Uhb1jStssiFNRS K3YCl2Wt3adqC7uvwgJrGW4CFUv+nl+pH9GhI4w== X-Gm-Gg: ASbGnctxZzf4wnZbDdhz2I4QHalB9fpqoJY5320nJLuVZR9jPQYMnfgwvsj71AVZS1f HwyRSrCzlp/BynLeROt4cXAHLC182ELq3+NWu/x1YLxJeQNGwklZAW2KcgAr7TbYRbpXvrF/C3y bADqaK2I4+orW51/ZVpV0+n+CdUWVi1NbONILC X-Google-Smtp-Source: AGHT+IHaJ04dwxunr7D0XcLZ2ACMkTcvWd2slbzLejMrykwNf+bwhNTLYd+0w5kbjl5vhahxgleycSTb9ihSQxMZrnU= X-Received: by 2002:a17:90b:2247:b0:2ff:64c3:3bd4 with SMTP id 98e67ed59e1d1-3030ff046fdmr10584894a91.31.1742659365801; Sat, 22 Mar 2025 09:02:45 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <20250322080212.0fe0e090d8e942105e9feb65@bidouilliste.com> In-Reply-To: From: Warner Losh Date: Sat, 22 Mar 2025 10:02:34 -0600 X-Gm-Features: AQ5f1JrWzKMQFtI3jWz8KMRrUl0T7pXJ7Dw6TKOjtSAFu1hTDZoKSQPEEjyftpY Message-ID: Subject: Re: Confused by boot_mute documentation, terminal systems, and goals To: "Steven Harms (High-Security Mail)" Cc: Emmanuel Vadot , "freebsd-current@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000076b0d80630f080bf" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZKkc73PbYz3xkV X-Spamd-Bar: ---- --00000000000076b0d80630f080bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 22, 2025 at 8:40=E2=80=AFAM Steven Harms (High-Security Mail) < sgharms@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=E2= =80=99t > care about kernel problems screen output OR RC startup output. > > I do my kernel builds on old hardware =E2=80=94 using FreeBSD to help wit= h 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=E2= =80=99t > 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 > wrote: > > > Hi, > > On Fri, 21 Mar 2025 22:13:29 +0000 > "Steven Harms (High-Security Mail)" 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 a= n > 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 tha= t > the overlay image can be controlled through configuration of the [splash] > value implying that instead of using the encoded array of unsigned char i= n > the kernel at > https://github.com/freebsd/freebsd-src/blob/main/sys/dev/vt/logo/logo_bea= stie.c. > Whoa! A nice configurable option? Nice. Looking at the git history on tha= t > file it appears to be part of splash(4). And /that/ document says ..."wor= k > 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 on= e > that's being shown? Seems like it. There's also quite a bit of logic insi= de > of sys/dev/vt/vt_cpulogos.c[3] that suggests that it's trying to use arra= ys > 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 arr= ay > 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.co= nf.5 > > [2]: > https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867e4084bafe3= 68c47f6c038/stand/defaults/loader.conf#L134 > > [splash]: > https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867e4084bafe3= 68c47f6c038/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 > > --00000000000076b0d80630f080bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Mar 22,= 2025 at 8:40=E2=80=AFAM Steven Harms (High-Security Mail) <sgharms@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.=C2=A0

You want to load an image in the loader, have the ke= rnel not disturb it (or at least re-load it) and then have X11/Wayland star= t? With syscons/splash, you could switch the virtual video terminal from th= e splash screen to the kernel / rc output if things were taking too long. I= f 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 opti= on to enable. It doesn't go to the console exactly (in the same sense= =C2=A0as kernel messages go to the console), so it shouldn't be control= led by RB_MUTE. If you want to head in this direction, I'd think it wou= ld be better to just have a real /dev/null console rather than trying to fa= ke it with RB_MUTE which has some unfortunate historical baggage.

If you rarely=C2=A0want silence to the login prompt, we lik= ely 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 al= l 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/co= nsole connected to all the consoles together.

Alternatively sa= id, I want nothing of beastie or beastie orb. And I don=E2=80=99t care abou= t kernel problems screen output OR RC startup output.

I do my kernel builds on old hardware =E2=80= =94 using FreeBSD to help with giving old machines new life / longer life i= s a contribution I can make to reducing electronic waste. I have a build ru= nning right now so I can=E2=80=99t double check the language / versioning i= n the man pages, but will update later today after I install the world.

Yea, there be dragons here, and there= 9;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 w= ere under documented and/or ignored from ignorance (the bell frequency is a= nother example we had crop up recently). It would be good=C2=A0
= =C2=A0
On Sat, Mar 22, 2025 at 03:02, Emmanuel Vadot <manu@bidouilliste.com> wrote:

Hi,

On Fri, 21 Mar 2025 22:13:29 +0000
"Steven Harms (High-Security Mail)" <sgharms@stevengharms.com> w= rote:

> 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 e= xpect.
>
> - 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 control= led
by kern.vt.splash_cpu which defaults to 0

> - The only other mention of boot_mute is on the line that specifie= s that the overlay image can be controlled through configuration of the [sp= lash] value implying that instead of using the encoded array of unsigned ch= ar in the kernel at https://github.com/f= reebsd/freebsd-src/blob/main/sys/dev/vt/logo/logo_beastie.c. Whoa! A ni= ce configurable option? Nice. Looking at the git history on that file it ap= pears to be part of splash(4). And /that/ document says ..."work with = syscons(4) only". OK so maybe that comment in defaults also needs upda= ting? 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 boo= t_mute? I really don't understand the image packing as chars well enoug= h 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&= #39;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-/mi= s-documented loader.conf flags, and two places where images are defined: in= the vt device directory and the images/ directory. Question: Can anyone co= nfirm / deny my assessment?

Looks correct yes.

> After all that I'm still a bit confused as to what the expecte= d/desired behavior is. Can anyone help me figure out what the desired behav= ior is (and maybe I can update the comments)? My current plan is to turn th= e 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/f= reebsd-src/blob/main/stand/defaults/loader.conf.5
> [2]: https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867= e4084bafe368c47f6c038/stand/defaults/loader.conf#L134
> [splash]: https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f= 867e4084bafe368c47f6c038/stand/defaults/loader.conf#L30
> [3]: https://github.com/freeb= sd/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 mos= t 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 <manu@bidouilliste.com> <manu@freebsd.org>
--00000000000076b0d80630f080bf--