From nobody Wed Jun 22 02:47:14 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 9618E86DB45 for ; Wed, 22 Jun 2022 02:47:16 +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 4LSSTb3rK2z4l6y for ; Wed, 22 Jun 2022 02:47:15 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1655866034; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1r0HkLggGafeVSvs3t9Hu2FInQE5HRTKKox7u1xR9cg=; b=HTb6ysGX3Tqm5HCGHt7wuvEpu5C+UYQ8Ym9Z7HLmv6iInuWhsPolzIsjmGs4G5V/OPHqez h/KQh13pRtjI0hllFhWGBqZQ5xRfW4PHVtDJnw1PenH/W2BO0CL5cF1zdmNcX/B/vnuHWx /gCPiDbWPCuaWCtvpPFPFEAm9ZhWpFw= Received: from amy (lfbn-idf2-1-1159-38.w90-92.abo.wanadoo.fr [90.92.219.38]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 22284139 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 22 Jun 2022 02:47:14 +0000 (UTC) Date: Wed, 22 Jun 2022 04:47:14 +0200 From: Emmanuel Vadot To: Chris Cc: Marek Zarychta , freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20220622044714.c1cf644ae8f34d6ea4b863cb@bidouilliste.com> In-Reply-To: <5812d9bb3a577fdd76fd58d2dd61a9cd@bsdforge.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <5812d9bb3a577fdd76fd58d2dd61a9cd@bsdforge.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4LSSTb3rK2z4l6y X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=HTb6ysGX; 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.24 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.77)[-0.771]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; 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 On Tue, 21 Jun 2022 13:51:17 -0700 Chris wrote: > On 2022-06-21 11:36, Marek Zarychta wrote: > > W dniu 21.06.2022 o=A020:19, Emmanuel Vadot pisze: > >> Hello, > >>=20 > >> On Fri, 26 Nov 2021 16:04:54 +0100 > >> Emmanuel Vadot wrote: > >>=20 > >>> Hello all, > >>>=20 > >>> 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. > >>>=20 > >>> So I looked at what sc could do and vt couldn't and vice-versa. > >>>=20 > >>> What sc(4) can't do : > >>>=20 > >>> - Work with EFI firmware. > >>> - Support UTF-8 > >>> - Maybe other things but everything here is EFI-based so let me kno= w. > >>>=20 > >>> What vt(4) can't do : > >>>=20 > >>> - 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 rea= son > >>> 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 m= ake > >>> 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. > >>>=20 > >>> For libvgl it probably made sense back in the 90s but does it now ?? > >>>=20 > >>> 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. > >>>=20 > >>> 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. > >>>=20 > >>> Cheers, > >>>=20 > >>> -- Emmanuel Vadot > >>>=20 > >> I've put up in phab removing sc(4) from GENERIC and MINIMAL : > >>=20 > >> https://reviews.freebsd.org/D35538 > >> https://reviews.freebsd.org/D35539 > >>=20 > >> 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. > >>=20 > >> Cheers, > >>=20 > > Thanks for heads up. Unfortunately, it will be a great loss. The waste = of=20 > > power > > resources might increase since vt(4) still doesn't support VESA Display= =20 > > Power > > Management Signaling which some of the servers are heavily relying on. = It's=20 > > a step > > backward in terms of green computing and amidst the power crisis, we ar= e=20 > > heading > > in Europe. > My only objection is that I can NOT get textmode or very stable X on any = of=20 > the NVIDIA > cards I use unless I build against sc. Does sc(4) use so much space that= =20 > current kernels > become too big with it's presence? I vote against it's removal. >=20 > Chris I'm sure that other people uses nvidia cards with vt(4), did you opened a PR about this ? --=20 Emmanuel Vadot