Re: Reasons for keeping sc(4) and libvgl ?
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 22 Jun 2022 04:05:50 UTC
W dniu 21.06.2022 o 23:34, Tomoaki AOKI pisze: > On Tue, 21 Jun 2022 20:36:25 +0200 > Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> 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. >> >> -- >> Marek Zarychta > > And IIUC, sc doesn't built as module at least by default. > > If something like sc.ko (incorporating libvgl?) is built as module BY > DEFAULT and sanely loadable via /boot/loder.conf (hopefully kldload'able > and supercedes vt in such cases) and runs OK, I have no objection. > Users who need sc like Marek can load it in such situation. > > Maybe, to do so, vt would be better buildable / loadable as > module, too. (Would not be mandatory, as kern.vty=sc > in /boot/loader.conf would disable vt. Preferrably, kern.vty=[sc|vt] > invokes auto-loading of (now nonexistent) corresponding .ko if not > loaded nor built in kernel. > > One thing to add. > vt doesn't support console screen savers yet. > Good point. Kernel loadable module of sc(4) would be probably the best temporary solution, at least until vt(4) gains DMPS support and conflict with Nvidia drivers gets resolved. -- Marek Zarychta