From nobody Tue Jun 21 18:19:24 2022 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 AB99586558D for ; Tue, 21 Jun 2022 18:19:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSFCr43L4z3tTL for ; Tue, 21 Jun 2022 18:19:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1655835568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=spf73J6O/AvWdnDkc4N1wvenL6oAzAUFXhy332aCVOA=; b=qufaY5Cl/ued2ohaHxb0XGPOQ6wy4hAFcZz5uLjf3EDZUtYT2ilVFPxAm37ee8Lil1Bm9D 34cSDYTzURgi50SQDHdhnSc5djd6as2ireNNECQcDjTDBbp7wOyZar7QvFt/+j4tlX1PCJ xiyhqYce4tD1q3D7x6NLhSNENThRVjw= Received: from skull.home.blih.net (lfbn-idf2-1-899-227.w86-238.abo.wanadoo.fr [86.238.130.227]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 53056a60 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Tue, 21 Jun 2022 18:19:28 +0000 (UTC) Date: Tue, 21 Jun 2022 20:19:24 +0200 From: Emmanuel Vadot To: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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-Rspamd-Queue-Id: 4LSFCr43L4z3tTL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=qufaY5Cl; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, On Fri, 26 Nov 2021 16:04:54 +0100 Emmanuel Vadot wrote: > > Hello all, > > I'm currently re-implementing the framebuffer code in linuxkpi for > drm-kmod and this made me look at sc(4), vt(4) and friends. > > So I looked at what sc could do and vt couldn't and vice-versa. > > What sc(4) can't do : > > - Work with EFI firmware. > - Support UTF-8 > - Maybe other things but everything here is EFI-based so let me know. > > What vt(4) can't do : > > - You can't get the modes or adapter info with vidcontrol. > vidcontrol -i mode is really made for anything vesa based as it > iterates on all the modes and display them if present. > In the modern world (EFI), we don't have that, EFI GOP doesn't > support changing resolution after ExitBootService was called so there > is only one "mode". I could possibly hack some patch so vidcontrol -i > mode/adapter would work and display the current framebuffer info if > people wants (but I honestly doubt that vidcontrol is useful at all in > an EFI world). > - "Blanking" screen doesn't do what you think it does. For some reason > in vt(4) we just write black colors on the screen and ignore the blank > mode passed in the ioctl. > Now again, blanking/dpms/blah isn't possible with efi_fb but it make > sense to fix vt(4) and drm-kmod so it calls the drm module blanking > function, I'll work on that next week. > - There is no screensaver, again see notes above for dpms but do > people still use sc(4) just for the screensaver ?? > - Maybe other things, please let me know. > > For libvgl it probably made sense back in the 90s but does it now ?? > > Based on my small list I don't see any good reason to keep sc(4) but > maybe I've missed something bigger so please let me know. > > P.S.: I'm really not interested by people saying stuff like > "I've always used sc(4), it works for me don't touch it" > without some technical argument. > > Cheers, > > -- > Emmanuel Vadot > I've put up in phab removing sc(4) from GENERIC and MINIMAL : https://reviews.freebsd.org/D35538 https://reviews.freebsd.org/D35539 If you have any good reason that sc(4) should be included in those kernel config for amd64 (no other arches was touched) please provide some argument on the reviews. Cheers, -- Emmanuel Vadot