From nobody Tue Jun 21 18:36:25 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 B56808698E4 for ; Tue, 21 Jun 2022 18:36:39 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSFbV56m3z4TpG for ; Tue, 21 Jun 2022 18:36:38 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2a02:22e0:cf00:1ff:cd4c:3200:7d9e:558f] (mzar@[IPv6:2a02:22e0:cf00:1ff:cd4c:3200:7d9e:558f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 25LIaQIZ041762 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 21 Jun 2022 20:36:27 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1655836588; bh=5atfAyZabxMShuCpFejQLOojtwGf//fIRaaWSRe9mx8=; h=Date:Subject:To:References:From:In-Reply-To; b=CbtgqlQ2B5s9k0An+AE8G7dOokMlnYt9PY7tESY3Af3QENToUnLA9kqJNRYefsFGv x+dB+cL0uCY8SPeFG6UM2gxIL3VJn1nN8tR52DF1YuQWV6NqJxaZu3jD18694TZI2L rl6JY3eVpydAXiqClz5t7DYrN9QPIRpmgIDpn050F+O0wVuaZMiGpyVRvbgd235Fsi SujxNrUkcKW8DWH4WarYSLmm0CLCFGsLqShEG4DqjKzMnTfA+O5WJDtML/3e/PHJ9m mNTcZX2D6j+hRODqHJP4soHYejBTYFC7zI9acGhoi7XYtgAsOKTC97iyeSk50hqcO+ ADNctlQU3lUIw== Message-ID: <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> Date: Tue, 21 Jun 2022 20:36:25 +0200 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Reasons for keeping sc(4) and libvgl ? Content-Language: en-US To: Emmanuel Vadot , freebsd-hackers@freebsd.org References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> From: Marek Zarychta In-Reply-To: <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4LSFbV56m3z4TpG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=CbtgqlQ2; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N W dniu 21.06.2022 o 20:19, Emmanuel Vadot pisze: > 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, > Thanks for heads up. Unfortunately, it will be a great loss. The waste of power resources might increase since vt(4) still doesn't support VESA Display Power Management Signaling which some of the servers are heavily relying on. It's a step backward in terms of green computing and amidst the power crisis, we are heading in Europe. -- Marek Zarychta