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

On Fri, 26 Nov 2021 16:45:17 +0100
Stefan Blachmann <sblachmann@gmail.com> wrote:

> Main technical reasons why I consider sc(4) essential:
> 
> - vt/vesa.ko break suspend/resume on nvidia cards. To make
> suspend/resume work on computers with nvidia, it is necessary to build
> a kernel *without* vt/vesa modules. See
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253733

 I'm not sure I understand your report, does the system suspend/resume
fine if you use vt or not ?
 To me it seems that the problem is when you have vt(4) in the kernel
but uses sc(4).

> - vt is so horridly buggy that it is no fun to use it at all if one is
> accustomed to well-working, bugfree sc(4). Just one example:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211922

 Oh yes, one scroll bug that I even can't reproduce locally clearly
makes vt(4) 'horridly buggy'.

> 
> The hate and disregard against sc(4) and against nvidia and the
> arrogance that can be observed from some FreeBSD core guys amazes me
> again and again.
> I often wonder why Nvidia has not already dropped FreeBSD support due
> to such attitudes.
> 
> 
> On 11/26/21, 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>
> >
> >


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