John Baldwin 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 <luzar...@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 trade offs in both directions. Neither console is a subset of the
other. However, sc(4) is not really expendable 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.
This sounds like a integration design error. From your description of
the hardware that vt is designed for and sc is designed for indicates
the need for some code to be added to the boot process that inspects the
hardware and decides whether vt or sc is to be launched. Or maybe
bsdinstall should inspect the hardware and give the installer the option
to select what console is best for his hardware. Just forcing this
version of vt that lacks long time functions as the default console
driver is not the professional way to handle such conflicts.
I am at a lost to understand how any development administrator would
approve making vt the default console driver in light of the standard
functions missing from it. And furthermore what kind of vt testing was
done that these problems were missed. Any one of these problems is
enough cause to reverse the decision to make vt the default console
driver for 11.0. This would give time for these problems to be address
and correctly tested and when ready then be paced in some other 11.x
release.
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
