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

On 2022-06-21 19:47, Emmanuel Vadot wrote:
> 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),
I'm *know* they do. I've assisted others by responding to threads on the
mailing lists, pr(1)'s && the FreeBSD forums, in fact I've also talked with
Toomas on the OpenIndiana mailing lists regarding this on OI. Not a huge 
deal.
But another obstacle/hurdle in order to obtain reasonable graphics.
> did you opened a PR about this ?
See above.

Thanks for taking the time to respond.

Chris