console in 11.0-ALPHA4
Chris H
bsd-lists at bsdforge.com
Tue Jun 21 05:11:28 UTC 2016
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
More information about the freebsd-current
mailing list