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

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