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 BaldwinReceived on Tue Jun 21 2016 - 03:11:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC