Solved TTY & nVidia Error

Spity

Member

Reaction score: 5
Messages: 48

Install FreeBSD 12.2 with Gnome, when installing the nvidia-driver all the tty (Control + alt + F (x) look like this
20210107_162822.jpg


my rc.conf
kld_list="nvidia-modeset"

my loader.conf
linux_load="YES"
nvidia-modeset_load="YES"
nvidia_load="YES"
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,724
Messages: 39,312

This can happen if you quit X or try to switch to the consoles with CTRL-ALT-F2, F3, etc. This happens ever since the switch to KMS. Not all NVidia cards seem to do this, I have systems that will happily switch back and forth between X and the TTY, but also some systems that do this exact thing. Nothing much you can do about it. You can try switching the console back to the old sc(4) driver, that sometimes helps. Add kern.vty=sc to loader.conf if you want to try that.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,724
Messages: 39,312

Additional note, use kld_load in rc.conf OR load the modules in loader.conf. Don't do both. Put drivers that are absolutely crucial to booting the system in loader.conf, everything else should go in kld_list.
 
OP
Spity

Spity

Member

Reaction score: 5
Messages: 48

Thank you! It is exactly what I was looking for. Even better than before! I'm learning to solve various problems. Thanks a lot!
 

pboehmer

Active Member

Reaction score: 36
Messages: 150

I'd like to add that I found that if you set the VT resolution the same as your X11 resolution, this seems to fix the switching issue.
 

olli@

Daemon
Developer

Reaction score: 1,262
Messages: 1,140

That’s interesting. My VT resolution is set to 1024×768, and I don’t seem to be able to change it.
This is from my dmesg(8):
Code:
VT(efifb): resolution 1024x768
Apparently, the tunable kern.vt.fb.default_mode only works with KMS drivers, so it does not support Nvidia. (I have an Nvidia Geforce GT 1030.)

Of course, X11 runs at the native resolution of my monitor, that’s 3440×1440. Fortunately I can switch between X11 and sc(4)-based VTYs without problems, even though the resolutions are very different.
 

shkhln

Daemon

Reaction score: 990
Messages: 2,274

I'd like to add that I found that if you set the VT resolution the same as your X11 resolution, this seems to fix the switching issue.
Did you experience this yourself or just read about it somewhere?

Apparently, the tunable kern.vt.fb.default_mode only works with KMS drivers, so it does not support Nvidia. (I have an Nvidia Geforce GT 1030.)
That is entirely correct.

Of course, X11 runs at the native resolution of my monitor, that’s 3440×1440. Fortunately I can switch between X11 and sc(4)-based VTYs without problems, even though the resolutions are very different.
This issue happens with VGA either due VT missing a fix similar to the one in PR 237050 or os_get_screen_info (see src/nvidia/nvidia_os.c in the driver) not handling VT+VGA.
 

pboehmer

Active Member

Reaction score: 36
Messages: 150

I have a couple of terminals using ASRock Q1900B-ITX boards (Intel ATOM E3800) that couldn't switch between console and X since early 10.x (guessing??). As soon as X was started, going back to console mode would result in blank screen. Only way to recover was to either ssh into the terminal and reboot or physically reset the hardware.
 

Jaekelsson

New Member

Reaction score: 6
Messages: 14

With Nvidia driver >=390 i have to put hw.vga.textmode=1 in /boot/loader.conf for VT work well.

Still use VT console instead SC.
Dont need kern.vty=sc
 

Snurg

Daemon

Reaction score: 595
Messages: 1,349

That’s interesting. My VT resolution is set to 1024×768, and I don’t seem to be able to change it.
[...]
Of course, X11 runs at the native resolution of my monitor, that’s 3440×1440. Fortunately I can switch between X11 and sc(4)-based VTYs without problems, even though the resolutions are very different.
Couldn't this be done automatically via the vesa driver?
I mean, there is some way (EDID, DisplayID, ...) that xorg uses to find out the monitor's native resolution.
And then simply use this?

However, combining this with appropriately larger-sized fonts would probably be a must!

Imagine the today's resolutions with a 1980s circa 7x8 pixel character box on a todays display.
I mean, a monster screen with a 150-line console, 800 chars wide, with tiny chars, as in Linux, thats just disgusting (at least to my eyes)...
 

olli@

Daemon
Developer

Reaction score: 1,262
Messages: 1,140

Couldn't this be done automatically via the vesa driver?
You mean VBE (VESA BIOS Extension)? No, unfortunately not. VBE is relatively useless nowadays.

VBE is a very old standard, dating back to the middle of the 90s of the previous century. It was created in order to have a common API when (literally) hundreds of graphics card manufacturers started selling cards that were incompatible with each other. In particular, this was an issue for 16bit DOS software because DOS didn’t have its own graphics interface, so every piece of software had to ship its own drivers for all kinds of graphics hardware. Thanks to VBE, they had to ship only one driver. Later, the standard was improved to incorporate functions for “protected mode” and 32bit software, but operating systems like Windows or Mac-OS provide their own graphics API (DirectX, OpenGL, …), so applications don’t use VBE anymore.

So, with the decline of DOS, the VESA standard became mostly superfluous, and graphics hardware vendors started neglecting it. Today, many graphics cards don’t have a VBE anymore, so the “vesa driver” doesn’t work. That’s the case for my Nvidia 1030, for example.

Apart from that, the list of video modes supported by VBE is usually a fixed list (hardcoded in the graphics hardware’s BIOS ROM), i.e. it does not dynamically adapt to the monitor that is connected. For this reason, it supports only a certain set of standard resolutions, usually not including things like UWQHD displays like mine (3440×1440).

I mean, there is some way (EDID, DisplayID, ...) that xorg uses to find out the monitor's native resolution.
And then simply use this?
That’s not possible for Nvidia GPUs because they’re not KMS-based.

However, combining this with appropriately larger-sized fonts would probably be a must!
Yes, of course, FreeBSD already has a selection of fonts, including larger ones (32 pixels) for screens with high DPI. You can use the vidfont(1) command to select a font from a list.

You can also create your own font files for use with vt(4): Either export an existing X11 font with x11/fstobdf or x11-fonts/pcf2bdf, or use one of the various X11 font editors to modify an existing font or create your own one from scratch, then save it in BDF format. Once you have a BDF file, you can convert it to a *.fnt file usable with vt(4) with FreeBSD’s vtfontcvt(8) tool. Then you can load the font with the vidcontrol(1) command. In order to have it in the selection list of the vidfont(1) tool, put the *.fnt file in the /usr/share/vt/fonts directory and add an entry to the INDEX.fonts file (it’s an ASCII file, so you can use a standard text editor). By the way, BDF files are also ASCII files, so you can look at them with less(1), for example, if you’re curious.
 

shkhln

Daemon

Reaction score: 990
Messages: 2,274

Today, many graphics cards don’t have a VBE anymore, so the “vesa driver” doesn’t work. That’s the case for my Nvidia 1030, for example.
My impression is that VESA works with legacy BIOS / UEFI CSM boot while GOP is available with pure UEFI boot (with 7xx and later cards).
 

judd

Active Member

Reaction score: 206
Messages: 237

My impression is that VESA works with legacy BIOS / UEFI CSM boot while GOP is available with pure UEFI boot (with 7xx and later cards).
Same here, in my Nvidia GTX 1650 there is no way to make it work in TTy.
 

Snurg

Daemon

Reaction score: 595
Messages: 1,349

You mean VBE (VESA BIOS Extension)? No, unfortunately not. VBE is relatively useless nowadays.

Apart from that, the list of video modes supported by VBE is usually a fixed list (hardcoded in the graphics hardware’s BIOS ROM), i.e. it does not dynamically adapt to the monitor that is connected. For this reason, it supports only a certain set of standard resolutions, usually not including things like UWQHD displays like mine (3440×1440).
Yes, I mentioned that EDID thing because the more modern standards (which I do not know) apparently get the resolution information via the EDID hardware.
I guess the actual thing is very simple, some CRT register write and then read the serial data from the monitor, need to look into the xorg sources to learn how to do this.

The VESA standard insofar has one useful legacy, as practically all modern monitors eat 1024x768 without problem.
So one can take that resolution as "personal default value" if there are no really old monitors to support.

Yes, of course, FreeBSD already has a selection of fonts, including larger ones (32 pixels) for screens with high DPI. You can use the vidfont(1) command to select a font from a list.
The 32-lines-fonts could be ideal for 1024x768!
However, when I attempt to list the available fonts using vidfont -p it shows no fonts larger than 16 lines :(
I wonder whether this is because of "BUGS: The kbdmap and vidfont utilities work only on a (virtual) console and not with X11."?
Or maybe I need to install some non-default font package?

You can also create your own font files for use with vt(4): Either export an existing X11 font with x11/fstobdf or x11-fonts/pcf2bdf, or use one of the various X11 font editors to modify an existing font or create your own one from scratch, then save it in BDF format. Once you have a BDF file, you can convert it to a *.fnt file usable with vt(4) with FreeBSD’s vtfontcvt(8) tool. Then you can load the font with the vidcontrol(1) command. In order to have it in the selection list of the vidfont(1) tool, put the *.fnt file in the /usr/share/vt/fonts directory and add an entry to the INDEX.fonts file (it’s an ASCII file, so you can use a standard text editor). By the way, BDF files are also ASCII files, so you can look at them with less(1), for example, if you’re curious.
Cool!
I bookmarked this to try it out soon!
There are some really nice monospaced fonts I would love to use if I may have to abandon sc on a more modern UEFI system soon...

Edit: Found this link with more info in another thread: Newcons (Thanks SirDice )
 

olli@

Daemon
Developer

Reaction score: 1,262
Messages: 1,140

The 32-lines-fonts could be ideal for 1024x768!
Well, that depends on the display’s DPI, not on the pixel resolution.
For example, a 17″ monitor with 1024×768 pixels has 75 DPI. In this case I would select a 16px font – it might be small, but should still be well readable, and you can have a good amount of information on the screen.
However, a 10″ display (typical tablet size) with 1024×768 pixels has 128 DPI. For this, a 16px font would be too small. In this case a 32px font might be appropriate, indeed.

However, when I attempt to list the available fonts using vidfont -p it shows no fonts larger than 16 lines :(
I wonder whether this is because of "BUGS: The kbdmap and vidfont utilities work only on a (virtual) console and not with X11."?
Yes, of course, the vidfont(1) tool tries to connect to the TTY driver, so it doesn’t work inside an X11 window. However, the -p option is special, because it only prints the contents of the index file, so it doesn’t actually have to connect with the TTY driver in that case (you still get a warning, though).

Note that vidfont(1) uses file descriptor 0 (standard input) to access the TTY driver, so you can still use it inside an X11 window if you use an appropriate input redirection from a virtual TTY, like this:
Code:
vidfont < /dev/ttyv0
Note that you must have permission to access that TTY. That means you must either be logged in onto that virtual terminal (so you are the owner of the TTY), or you must run the command with root privileges.

On my machine (FreeBSD amd64 stable/12) I get the following output from vidfont -p:
Code:
lang_default = en
dialect = de_...UTF-8
lang_abk = de
gallant
terminus-b32
tom-thumb
vgarom-16x32
vgarom-8x8
vgarom-8x14
vgarom-8x16
vgarom-thin-8x8
vgarom-thin-8x16
From that list, the terminus-b32 and the vgarom-16x32 fonts have a height of 32 pixels. Personally I think both of them are dead ugly and not very well readable, but I usually work with X11, so I don’t care much about the virtual terminals. :)
 
Top