Re: console in 11.0-ALPHA4

From: Chris H <bsd-lists_at_bsdforge.com>
Date: Mon, 20 Jun 2016 22:11:52 -0700
On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin <jhb_at_freebsd.org> wrote

> On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote:
> > Ed Maste wrote:
> > > On 20 June 2016 at 14:29, Ernie Luzar <luzar722_at_gmail.com> wrote:
> > >> I found the cause of this boot time message
> > >> "vicontrol: setting cursor type: Inappropriate ioctl for device"
> > >>
> > >> In my rc.conf I had this statement
> > >> vidcontrol -c blink -h 250
> > >> From testing it seems that vt does not handle the "blink" option for
> > >> causing the cursor to blink. Is there a vt option to enable cursor 
> > >> blinking > > 
> > > I've submitted two PRs for the issues you reported here:
> > > Bug 210413 - vidcontrol -c <normal|blink|destructive> does not work with
> > > vt(4) Bug 210415 - vidcontrol -h <history size> does not work with vt(4)
> > > (edit) 
> > > There is currently no option to enable cursor blinking.
> > 
> > 
> > Further testing shows that:
> > 
> > 1. The rc.conf option screen saver "saver= " and the "blanktime= " 
> > options work in vt for both text and graph modes.
> > 
> > 2. The cursor copy/paste does not work in vt text mode. It only works in 
> > vt graph mode. vt needs to be fixed so copy/paste function also works in 
> > text mode.
> > 
> > 3. Boot time splash screen does not work in vt at all no matter which 
> > mode is enabled. Using this in loader.conf
> > splash_bmp_load="YES"
> > bitmap_name="/boot/splash.bmp"
> > bitload_load="YES"
> > 
> > This works in 10.x. The splash screen function can not be allowed to be 
> > removed from the base system just because vt can not handle it. This 
> > also means any vt changes need to updated in the handbook section on 
> > splash screen.
> > 
> > In conclusion, vt is not ready to replace the sc console driver yet. vt 
> > needs to be fixed before becoming the default in 11.0. Using vt as the 
> > default console driver effects every user. It completely changes the 
> > FreeBSD experience. It's detrimental to the public relations and the 
> > professional image of FreeBSD to publish the 11.0-RELEASE using vt in 
> > its current condition. If time doesn't permit to get these vt things 
> > fixed before publishing 11.0 then vt should not become the default 
> > console driver.
> 
> OTOH, if you use EFI, then you can't use sc(4).  You get no working console
> with EFI (which is becoming more popular) if you use sc(4).  You also do
> not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable
> console if you use sc(4).  You also do not have a working console after
> loading the KMS drivers (either by starting X or via explicit kldload) when
> using sc(4).  This affects just about every modern Intel system using an
> Intel GPU (so more widespread than EFI even).
> 
> There are tradeoffs in both directions.  Neither console is a subset of the
> other.  However, sc(4) is not really extendable to support the things it is
> missing.  vt(4) is actively worked on, and patches for the features it lacks
> that you need are certainly welcomed.
AMD, and ATI are also quite popular, as well as nVidia. In the case of
nVidia, vt(4) is nearly as good as sc(4) on/in [U]EFI.

I think the [original] point here was; for all that vt(4) intends to
provide, it's just not ready for prime time, and as such, shouldn't
be made default, just yet. :-)

--Chris
> 
> -- 
> John Baldwin
Received on Tue Jun 21 2016 - 03:11:28 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC