From owner-freebsd-current@freebsd.org Tue Jun 21 05:11:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3214AC430A for ; Tue, 21 Jun 2016 05:11:28 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8889318E3 for ; Tue, 21 Jun 2016 05:11:27 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u5L5Biin079033 for ; Mon, 20 Jun 2016 22:11:52 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <31205295.d0H0JTrSWj@ralph.baldwin.cx> References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com>, <31205295.d0H0JTrSWj@ralph.baldwin.cx> From: "Chris H" Subject: Re: console in 11.0-ALPHA4 Date: Mon, 20 Jun 2016 22:11:52 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-Milter: Spamilter (Reciever: udns.ultimatedns.net; Sender-ip: 127.0.0.1; Sender-helo: ultimatedns.net; ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 05:11:28 -0000 On Mon, 20 Jun 2016 16:22:53 -0700 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 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 does not work with > > > vt(4) Bug 210415 - vidcontrol -h 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