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

From: Mark Millard via freebsd-hackers <freebsd-hackers_at_freebsd.org>
Date: Fri, 26 Nov 2021 17:29:24 UTC
[This is a resend after joining freebsd-hackers (again?).]

This is just a history FYI. I no longer have access to powerpc* systems.
When I did they were all old PowerMacs. I can not test the current
status any more.

> What vt(4) can't do :
. . .

Well, what vt(4) didn't (doesn't?) do on some powerpc systems . . .

But there were also the other direction: ones where vt
worked but sc did not. So I used a mix on powerpc systems.

The contexts were basic video console use, not X11 or such.

Of, course, tier 2 breakage on old PowerMac hardware may not
be enough to drive the choice about keeping sc, even if vt
could not be made to work.

I looked up some of my old list messages and back on 2021-Jan-13
I reported to Warner:

PowerMac7,2 G5: vt worked, sc hang just after "Kernel entry at 0x100580 ...".

iMac G3 (PowerMac4,1): sc worked, vt failed (showing a blank screen).

However in that time frame the old old 2-socket-/2-cores-each G5
with the Radeon X1950 was dead and untestable. It used to be that
vt mishandled a 2560x1440 display for this context and caused a
boot-crash. The smaller displays worked fine. But I do know that
in the 2021-Jan-13 the GeForce 7800 GT based 2-socket-/2-cores-each
G5 handled the same display just fine. (That machine died since then.)
So the vt issue involved here might have been fixed.

Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)