# Changes to vt(4) NewCons console in stable/10



## kpa (Jul 8, 2014)

There's quite a big change in the vt(4) NewCons implementation. You can now have both the old sc(4) and the new vt(4) console drivers in the same kernel. In fact the GENERIC kernel is now configured like this. You can select which console to use using a loader.conf(5) variable kern.vty. The default is sc in the GENERIC kernel and you can change it to vt with:


```
kern.vty=vt
```


----------



## free-and-bsd (Sep 30, 2014)

And most importantly, if I get it right, we need vt(4) in order to have console working with KMS. Which is good news!


----------



## SirDice (Sep 30, 2014)

free-and-bsd said:
			
		

> And most importantly, if I get it right, we need vt(4) in order to have console working with KMS.


Well, it worked but you could never switch back to the console because the old driver wasn't KMS aware. This should indeed be solved by the new vt(4) driver. It should also have a few other, highly wanted, features like full UTF-8 support.


----------



## free-and-bsd (Sep 30, 2014)

That'll be one more feature that makes FreeBSD an even better system to be used on laptops. I'm using it now on my Lenovo ThinkPad T61 (with KMS), and not being able to go back to console has been a somewhat weird feeling... But yesterday I read about vt(4), so now, while at work, I've built remotely the fresh STABLE release and kernel for the laptop and it will be installed as soon as I get home. Is there anything I might test specifically in order to help in this matter?


----------



## free-and-bsd (Oct 1, 2014)

kpa said:
			
		

> There's quite a big change in the vt(4) NewCons implementation. You can now have both the old sc(4) and the new vt(4) console drivers in the same kernel. In fact the GENERIC kernel is now configured like this. You can select which console to use using a loader.conf(5) variable kern.vty. The default is sc in the GENERIC kernel and you can change it to vt with:
> 
> 
> ```
> ...


Small correction is due: this ONLY works when both sc and vga are commented out in kernel config. If they are not, the system console defaults to sc and the above line in loader.conf avails to nothing.
And an overall impression from this new system console, once I made it work, is quite decent. It defaults to some sort of "gprahics" mode instead of text mode. But after the launching of my DE and switching back VT goes into framebuffer mode, which looks much nicer. Scrollback works all right. Is it, perchance, possible to make it use framebuffer mode from the start?


----------



## kpa (Oct 1, 2014)

free-and-bsd said:
			
		

> kpa said:
> 
> 
> 
> ...



Not on my stable/10 system. I'm using the GENERIC config and I can switch the console driver using that exact setting without troubles. Are you on GENERIC or using your own kernel config?

The GENERIC kernel does have both vga(4) and sc(4) drivers included if you're wondering:


```
freebsd10 ~ % sysctl kern.conftxt | grep vga
device  vga
device  vt_vga
freebsd10 ~ % sysctl kern.conftxt | grep sc 
device  isci
device  scbus
device  sc
device  virtio_scsi
```


----------



## free-and-bsd (Oct 1, 2014)

No, I'm not "wondering", I wouldn't have posted this without having previously checked the matter carefully .

And yes, mine is as GENERIC as they come with the STABLE svn code. Tells me something in boot message about kern.vty=vt being "read-only tunable". Besides, tried setting i915kms_load="YES" in /boot/loader.conf, but it complains about the driver having no dependency or something... Anyways, with or without the latter setting in loader.conf, it works now that I've disabled vga and sc. But of course, I like best the framebuffer console, to which it switches back when I terminate my fvwm. Wold be nice to make it boot into framebuffer right away.


----------



## jb_fvwm2 (Oct 1, 2014)

Maybe instead of someone authoring a flowchart of the vt usage process, it would be easier to put a " if-then skipto " formulated sequence of steps regarding "everyting vt" here on in the wiki.


----------



## wblock@ (Oct 1, 2014)

1. Build a kernel with vt(4).  It can also have sc(4).
2. If both vt(4) and sc(4) are in the kernel, select one by setting kern.vty= in /boot/loader.conf.
3. Profit!


----------



## phoenix (Oct 1, 2014)

free-and-bsd said:
			
		

> No, I'm not "wondering", I wouldn't have posted this without having previously checked the matter carefully .
> 
> And yes, mine is as GENERIC as they come with the STABLE svn code. Tells me something in boot message about kern.vty=vt being "read-only tunable". Besides, tried setting i915kms_load="YES" in /boot/loader.conf, but it complains about the driver having no dependency or something... Anyways, with or without the latter setting in loader.conf, it works now that I've disabled vga and sc. But of course, I like best the framebuffer console, to which it switches back when I terminate my fvwm. Wold be nice to make it boot into framebuffer right away.



If you are getting "read-only tunable" error messages, then you are setting it in the wrong file.  That error messages usually comes when you set it in /etc/sysctl.conf and not in /boot/loader.conf.  You need to set the *kern.vty* in /boot/loader.conf.


----------



## free-and-bsd (Oct 2, 2014)

phoenix said:
			
		

> free-and-bsd said:
> 
> 
> 
> ...


Right, this is what the message means. Because I put it also in sysctl.conf when it didn't work in /boot/loader.conf, hence the message. But finally I had to remove it altogether from kernel config to make it work. For some reason system insisted on using sc for console as long as it was enabled in kernel.


----------



## free-and-bsd (Dec 6, 2014)

Hm, the 
	
	



```
kern.vty=vt
```
 may not be working for me because I use GRUB2 to boot, and it doesn't use /boot/zfsloader to boot the kernel, but loads every needed module and parameter directly from grub.cfg. While /boot/loader.conf is used by /boot/(zfs)loader, is it not?


----------



## kpa (Dec 6, 2014)

free-and-bsd said:


> Hm, the kern.vty=vt may not be working for me because I use GRUB2 to boot, and it doesn't use /boot/zfsloader to boot the kernel, but loads every needed module and parameter directly from grub.cfg. While /boot/loader.conf is used by /boot/(zfs)loader, is it not?



Yes, the loader.conf(5) is only read by loader(8) and its variants if they are used. Is there a way in GRUB2 to set the loader(8) variables?


----------



## jrm@ (Dec 6, 2014)

If you are using the sysutils/grub2-pcbsd, just set the variables as usual in loader.conf, then run `grub-mkconfig -o /boot/grub/grub.cfg`.


----------



## free-and-bsd (Dec 7, 2014)

jrm said:


> If you are using the sysutils/grub2-pcbsd, just set the variables as usual in loader.conf, then run `grub-mkconfig -o /boot/grub/grub.cfg`.


No, I'm using sysutils/grub2. But I know how to make it use /boot/loader.conf:

```
....
kfreebsd /boot/(zfs)loader
}
```
Just for several reasons I'm loading everything directly from grub.cfg.


----------



## free-and-bsd (Feb 8, 2015)

kpa said:


> Yes, the loader.conf(5) is only read by loader(8) and its variants if they are used. Is there a way in GRUB2 to set the loader(8) variables?


Yes there _is_ a way to set these variables in /boot/grub/grub.cfg:

```
set kFreeBSD.kern.vty=vt
set kFreeBSD.your.other.variable=your_value
```
I'm posting it now that I've tested it.

Just keep in mind, please, that even the most recent GRUB2 built from the freshest git sources (under linux) will not recognize/access the upgraded version of zpool.

So, for a fresh ZFS-based installation with GRUB2 bootloader using the above syntax the safest would be to use a 9-RELEASE installation media, because the more recent 9.x and 10.x releases will have updated ZFS  and it'll create an up-to-date zpool -- that is, inaccessible to GRUB2.


----------



## free-and-bsd (Dec 13, 2018)

free-and-bsd said:


> Just keep in mind, please, that even the most recent GRUB2 built from the freshest git sources (under linux) will not recognize/access the upgraded version of zpool.
> 
> So, for a fresh ZFS-based installation with GRUB2 bootloader using the above syntax the safest would be to use a 9-RELEASE installation media, because the more recent 9.x and 10.x releases will have updated ZFS  and it'll create an up-to-date zpool -- that is, inaccessible to GRUB2.


Well, I don't know how correct this is right now. They don't add new features in bunches, and the old ones are all supported by GRUB2 or get supported soon enough. 

Then you can always use the `zpool create -d` command line to have all features disabled at the installation time. That'll put you on the supersafe side .


----------

