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

I encountered some other bugs in vt while I used it.

Aside of the computers I am using for testing of my installer, I use
vt only in the time from installation of computers to when I get time
to configure/build a new kernel to remove vesa (and vt because it
pulls in vesa,ko) from the kernel to make suspend/resume work. So I
feel usually in some hurry when I want to get a system up and
running..

And then I am not in the mood to bother spending time making vt bug reports.
Maybe a reason that many of these bugs are not reported is that I love
to use mouse mark/paste in the console, and most of the bugs are
related to this. No idea how common it is to use mice in console mode;
if it is not common this might be why these bugs are apparently
under-reported.

Almost all my computers still have CSM support, so I use that, as I do
not use Microsoft OSes.

When time comes and I have to buy computers that do no longer support
CSM, I'll look into the sc source to add a VGA BIOS interrupt call to
change from UEFI graphics to text mode at initialization time.
This should be sufficient to support sc on UEFI machines.
Actually I do not understand why this has not yet been done.
Do you think such a patch to make sc work on UEFI systems would be
accepted into FreeBSD?


On 11/26/21, Ed Maste <emaste@freebsd.org> wrote:
> On Fri, 26 Nov 2021 at 10:45, Stefan Blachmann <sblachmann@gmail.com>
> wrote:
>>
>> - 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
>
> This issue is waiting on feedback since 2021-09-25. There is one issue
> that's still reproducible when I last tested, but "horridly buggy" is
> quite a stretch.
>