Date: Wed, 22 Jun 2022 04:46:16 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-ID: <20220622044616.b44bf8bed156940a3a67f05d@bidouilliste.com> In-Reply-To: <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Jun 2022 20:36:25 +0200 Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote: > W dniu 21.06.2022 o=A020:19, Emmanuel Vadot pisze: > > Hello, > > > > On Fri, 26 Nov 2021 16:04:54 +0100 > > Emmanuel Vadot <manu@bidouilliste.com> 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 reas= on > >> 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 ma= ke > >> 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, > >> > >> --=20 > >> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > >> > > 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=20 > of power resources might increase since vt(4) still doesn't support VESA= =20 > Display Power Management Signaling which some of the servers are heavily= =20 > relying on. It's a step backward in terms of green computing and amidst=20 > the power crisis, we are heading in Europe. >=20 > --=20 > Marek Zarychta >=20 Does that make sense nowadays ? You don't plug screen into servers, you have BMCs and even if I guess that some BMC "support" DPMS I'm not sure if it actually saves power. --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220622044616.b44bf8bed156940a3a67f05d>