Date: Fri, 22 Sep 2017 13:18:53 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: Polytropon <freebsd@edvax.de>, "Steve O'Hara-Smith" <steve@sohara.org>, freebsd-questions@freebsd.org Subject: Re: Restoring sc console look and feel with vt Message-ID: <alpine.BSF.2.21.1709221312520.83552@wonkity.com> In-Reply-To: <20170923033444.Q35468@sola.nimnet.asn.au> References: <mailman.83.1505476802.36054.freebsd-questions@freebsd.org> <20170916020243.B81507@sola.nimnet.asn.au> <20170915200315.289b3fdf.freebsd@edvax.de> <20170917011446.F81507@sola.nimnet.asn.au> <20170916185812.0ccc21a1.freebsd@edvax.de> <alpine.BSF.2.21.1709221038540.83552@wonkity.com> <20170923033444.Q35468@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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@.
>
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.21.1709221312520.83552>