Date: Fri, 26 Nov 2021 23:06:10 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Emmanuel Vadot <manu@bidouilliste.com>, freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-ID: <f0033d7b-9c41-2e3f-b7ef-c7d1cb1ec63f@grosbein.net> In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
26.11.2021 22:04, Emmanuel Vadot 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 : > > - Support UTF-8 This is not true. I tested UTF-8 support with sc(4) in FreeBSD 8 and it worked fine. It required some kernel options: options SC_PIXEL_MODE options VESA options TEKEN_XTERM options TEKEN_UTF8 And optionally for /boot/device.hints: hint.sc.0.flags="0x180" # switch to graphics mode at boot time hint.sc.0.vesa_mode="0x1F0" # preferred framebuffer video mode code And the port sysutils/jfbterm to render fonts.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f0033d7b-9c41-2e3f-b7ef-c7d1cb1ec63f>