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

On Tue, 21 Jun 2022 13:51:17 -0700
Chris <bsd-lists@bsdforge.com> wrote:

> On 2022-06-21 11:36, Marek Zarychta 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.
> My only objection is that I can NOT get textmode or very stable X on any of 
> the NVIDIA
> cards I use unless I build against sc. Does sc(4) use so much space that 
> current kernels
> become too big with it's presence? I vote against it's removal.
> 
> Chris

 I'm sure that other people uses nvidia cards with vt(4), did you
opened a PR about this ?

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