Re: console in 11.0-ALPHA4

On Mon, 20 Jun 2016 22:11:52 -0700
"Chris H" <bsd-lists_at_bsdforge.com> wrote:

> 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.

most recent nVidia BLOBs (starting with the separation of the kernel module in
nvidia-modset.ko and nvidia.ko kernel object modules) do not work properly
nor with sc(4), neither vt(4) on most recent CURRENT! See 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201340

With non-UEFI, die console is unusable due to some weird 1980s blocky-coloured
signs in 80x25 col/rows, with UEFI there is simply black screen when switching
to console - this is the fact as long the nvidia-modeset.ko is loaded. After
unloading, the problems disappear.

And by the way: at the moment nVidia's offering of a BLOB is the only, and THE
only way to provide acceptable support and performnce for recent and modern
GPUs. Since many people or those making decissions are not inclined to purchase
"old" but working stuff for a perspective of 3-5 years, a working console
seemes to me to be important.
 
> 
> 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  
> 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"