From nobody Sun Mar 19 01:01:49 2023 X-Original-To: freebsd-hackers@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 4PfKMV04Ycz40FM8 for ; Sun, 19 Mar 2023 01:01:58 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PfKMS38Pjz4HZd for ; Sun, 19 Mar 2023 01:01:55 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 32J11oxT003717 for ; Sun, 19 Mar 2023 10:01:51 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 19 Mar 2023 10:01:49 +0900 From: Tomoaki AOKI To: freebsd-hackers@freebsd.org Subject: Re: splash(4) support in vt Message-Id: <20230319100149.df3c27607af87db372011c92@dec.sakura.ne.jp> In-Reply-To: References: <20230316092007.6a2695e995f5e4c589140886@bidouilliste.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.59 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PfKMS38Pjz4HZd X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Sat, 18 Mar 2023 22:56:09 +0300 Gleb Popov wrote: > Thanks for the pointers! > > It just occurred to me that splash only hides kernel messages, but > after init(8) starts the image disappears and the textual boot > sequence is resumed. What are the approaches to solve this? Should we > handoff rendering to some usermode program? Would that be seamless? So maybe a R/W tunable that enables/disables screen output is needed. And init(8) SHALL not change it (leave it for rc.d script or something). If admins/vendors wants splash kept until desktop environment (mate or anything admins/vendors want), disable it on /boot/loader.conf and enable it after DE starts up (and/or X/Wayland is terminated). Possibly, switching between vtys to forcibly enable the writable tunable would help. This way, users can use vtys (including console [vty1]) after startup finishes or crashes, as X is historically tied to vty9. (Not sure for Wayland, though.) Without something like that, users cannot see console/vtys after logging out from DE or switching to any vty while DE is running, if no serial console is available. Note that sc worked as expected because sc doesn't touch graphic flamebuffers at all (pure, hardware text mode), but vt (including underlying efifb) renders texts to graphics FB, thus breaks splash on any screen output. And maybe some changes would be needed to log currently not logged console outputs. (Driver errors?) Without it, admins has no way to check such outputs when any error happenes. -- Tomoaki AOKI