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

K

kpa

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:

Code: 
kern.vty=vt
 
free-and-bsd said:
And most importantly, if I get it right, we need vt(4) in order to have console working with KMS.
Click to expand...
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.
 
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?
 
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:

Code: 
kern.vty=vt
Click to expand...
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?
 
free-and-bsd said:
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:

Code: 
kern.vty=vt
Click to expand...
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?
Click to expand...

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:

Code: 
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
 
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.
 
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.
 
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.
Click to expand...

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.
 
phoenix said:
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.
Click to expand...

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.
Click to expand...
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.
 
Hm, the
Code: 
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?
 
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?
Click to expand...

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?
 
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?
Click to expand...
Yes there is a way to set these variables in /boot/grub/grub.cfg:
Code: 
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 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.
Click to expand...
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 :).
 
You must log in or register to reply here.
Back
Top