Date: Mon, 20 Jun 2016 22:11:52 -0700 From: "Chris H" <bsd-lists@bsdforge.com> To: <freebsd-current@freebsd.org> Subject: Re: console in 11.0-ALPHA4 Message-ID: <f2215f16e22982ed7a0dfdd9ad421960@ultimatedns.net> In-Reply-To: <31205295.d0H0JTrSWj@ralph.baldwin.cx> References: <57680D69.7030309@gmail.com> <CAPyFy2Cyx%2BsAUa8cqvdEWFqLWJ36Zo_tLri57pKFH7MZvWK4Uw@mail.gmail.com> <576857F3.5040102@gmail.com>, <31205295.d0H0JTrSWj@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin <jhb@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f2215f16e22982ed7a0dfdd9ad421960>