Re: Reasons for keeping sc(4) and libvgl ?

From: Emmanuel Vadot <manu_at_bidouilliste.com>
Date: Wed, 22 Jun 2022 02:46:16 UTC
On Tue, 21 Jun 2022 20:36:25 +0200
Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:

> W dniu 21.06.2022 o 20: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 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 <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 
> 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
> 

 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.

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>