Restoring sc console look and feel with vt

[Simon Maurice]

  Original Message  
From: Warren Block
Sent: Saturday, 23 September 2017 05:19‎
To: Ian Smith
Cc: Steve O'Hara-Smith; Polytropon; freebsd-questions at freebsd.org
Subject: Re: Restoring sc console look and feel with vt

On Sat, 23 Sep 2017, Ian Smith wrote:

> On Fri, 22 Sep 2017 11:14:13 -0600, Warren Block wrote:
>
> > On Sat, 16 Sep 2017, Polytropon wrote:
> >
> > > On Sun, 17 Sep 2017 02:21:51 +1000 (EST), Ian Smith wrote:
> > > > Are you sure there's no way to use sc(4) with X on 10.3?
> > >
> > > The reason why I switched to vt was exactly that reason: with sc
> > > in place, X wouldn't start anymore. This happened at some point
> > > during the "updating trail" of 10.1 -> 10.3 with ports updated
> > > (via pkg). Something that worked for months suddenly stopped
> > > working, which always is a terrible experience. When I switched
> > > to vt in the loader, X worked again as it did before.
> >
> > I'm fairly sure that is due to KMS video. vt(4) supports it, sc(4) was out
> > decades before anyone thought of it.
> >
> > > From another channel, I've been told that persistently setting the gop
> > command in the loader is either not implemented or must be done in one of the
> > Forth loader files. I tried some things with no success yet, and have
> > inquiries to dteske at .
>
> Have you tried on an i386 system? My explore indicated that gop(0) only
> exists in /usr/src/sys/boot/efi/loader/arch/amd64/framebuffer.c on 10.3,
> 11.1 and head. Apparently nothing similar for the i386 loader.
>
> Polytropon's system also is BIOS|ACPI not EFI, though it wasn't clear to
> me that this code position in hierarchy necessarily implies EFI-booting?

I don't know. 32-bit i386 had a long, distinguished run, but it's a 
dying breed, and I have not spent any time on it in quite a while.

> > > > We saw lots
> > > > about getting proper console switching going (again) using vt and X on
> > > > the stable@ list on earlier 10.x, but I can't recall any details, since
> > > > sc still works fine on my 9.3 (amd64) system, where vt(4) first became
> > > > available, including proper suspend/resume support from ttyvN or from X.
>
> Again, that's an older system; core2duo, no EFI, no KMS (GM4500 graphics
> as I recall). So there's a complicated web of older systems being left
> behind fairly unceremoniously (with nobody to blame :) at an increasing
> rate .. or so it looks to we old farts who value stability over novelty.

There's stability. There is also being left behind by an 
increasingly-distant herd and finding yourself surrounded by 
metaphorical wolves and alligators. Or literal ones.

> > > That is a different problem. Until you start X, sc works perfectly
> > > fine. Even in a setting where "sc + startx" is working, shutting
> > > down the X session or switching using e. g. Ctrl+Alt+F1 leaves you
> > > with a console that works, but without visible text ("blind console").
> > > With vt, at least this problem is gone, even though the console now
> > > is visible only with the tiniest letters.
> >
> > I just tested this on a Haswell notebook with 11-stable. The mode setting is
> > either lost after leaving X, or it just keeps the resolution chosen in X.
> >
> >
> > However, vidfont and vidcontrol work to select a larger font.
> >
> > vidfont -p
> >
> > to print available font names. Then
> >
> > vidcontrol -f vgarom-16x32
> >
> > to choose one of them. This can be set in /etc/rc.conf with
> >
> > allscreens_flags="-f vgarom-16x13"
> >
> > It does not take effect until late in the startup, so the boot messages are
> > in the default or gop-set mode.
>
> Does 'uga' command also in mentioned MFC work at your loader prompt?

It says:

uga: UGA Protocol not present (error=14)

> > I'm not sure where this should be documented in the Handbook.
>
> Seems it would by now need distinguishing between architectures, classes
> of graphics and perhaps whether and where EFI boot or support is needed?

Maybe a separate article, then. I'm not sure whether any of this 
applies to newer architectures like ARM.
_______________________________________________
freebsd-questions at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

.