# Artifacts / tearing in text terminal with tty1-tty7



## Truculent_Freddi (Feb 13, 2021)

system FreeBSD localhost 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC amd64, graph shell gdm 3, driver nvidia-driver-440.100_1 OpenGL rendering video card gtx 1070, monique full hd 32 '
------------
/etc/rc.conf the following is written

```
kld_list = "linux nvidia"
gnome_enable = "YES"
moused_enable = "YES"
dbus_enable = "YES"
hald_enable = "YES"
gdm_enable = "YES"
```
in /etc/fstab

```
proc / proc procfs w 0 0
```
in /boot/loader.conf

```
linux_load = "YES"
nvidia_load = "YES"
nvidia_name = "nvidia"
nvidia_modeset_load = "YES"
nvidia_modeset_name = "nvidia-modeset"
```

/etc/X11/xorg.conf did not use handles, did it through nvidia-xconfig - it was automatically registered accordingly


----------



## the3ajm (Feb 13, 2021)

Did you install the port x11/nvidia-driver, can you also paste your xorg.conf? Alternatively you can configure your driver from the following port: x11/nvidia-xconfig and x11/nvidia-settings


----------



## Snurg (Feb 13, 2021)

This is a known bug with the vt console.
If there are no reasons that force you to use the vt console, just work around it by using the sc console. This also makes suspend/resume (sleep) work.


----------



## SirDice (Feb 13, 2021)

Truculent_Freddi said:


> ```
> kld_list = "linux nvidia"
> ```


Use `nvidia-modeset`, not `nvidia`. And to make sure this is not a copy/paste error, do NOT put a space before the `=`.



Truculent_Freddi said:


> ```
> nvidia_load = "YES"
> nvidia_name = "nvidia"
> nvidia_modeset_load = "YES"
> ...


Where do people get this from? I've seen this so many times now. It's wrong. The only thing that works here is the `nvidia_load`, everything else is a no-op.


----------



## Snurg (Feb 13, 2021)

SirDice said:


> *Where do people get this from?* I've seen this so many times now. It's wrong. The only thing that works here is the `nvidia_load`, everything else is a no-op.


To answer your question, this is what the nvidia driver installs.
More precisely, this is installed by `nvidia-xconfig` of the original nvidia driver, as I _never_ use the driver in ports. (I am currently using 389.something.)

The current nvidia driver furthermore _does not_ add itself to a `kld_list`. It only adds `linux_enable="YES"` to /etc/rc.conf.
Do not ask me why, I have no idea.

I can only say, I did not touch these settings.
They just work perfectly, without any problem (i.e., using sc, and neither vt nor vesa in kernel).

*I guess the drivers in ports and the driver from the Nvidia website (currently ~390 something) differ, leading to much confusion, pain and frustration finding the correct setting method.*
So I'd generally recommend _not_ to change the settings made by `nvidia-xconfig` and instead first try whether the problem goes away by disabling vt and vesa, as in this case, the search for the problems' cause can be narrowed down by ruling out the nvidia driver and its settings as the culprit.


----------



## fraxamo (Feb 13, 2021)

SirDice said:


> Use `nvidia-modeset`, not `nvidia`


I have `kld_list="nvidia"` in my /etc/rc.conf and it works perfectly. I'm using the x11/nvidia-driver-340 driver. I understand that you can put either `kld_list="nvidia"` or `kld_list="nvidia-modeset"` in your /etc/rc.conf file depending on your NVidia graphics card. But is there a way to work out which one it is without experimenting? Is it documented anywhere?


----------



## Snurg (Feb 13, 2021)

fraxamo said:


> But is there a way to work out which one it is without experimenting? Is it documented anywhere?


Long ago, I believe having read in an old nvidia driver README that nvidia-modeset belongs into /boot/loader.conf.


----------



## shkhln (Feb 13, 2021)

fraxamo said:


> But is there a way to work out which one it is without experimenting? Is it documented anywhere?


In the source code of a non-blob wrapper part of the driver:


```
x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.39 % grep MODULE_DEPEND -r src | grep orig
src/nvidia/nvidia_pci.c.orig:MODULE_DEPEND(nvidia, mem, 1, 1, 1);
src/nvidia/nvidia_pci.c.orig:MODULE_DEPEND(nvidia, io, 1, 1, 1);
src/nvidia/nvidia_pci.c.orig:MODULE_DEPEND(nvidia, linux, 1, 1, 1);
src/nvidia/nvidia_pci.c.orig:MODULE_DEPEND(nvidia, linux_common, 1, 1, 1);
src/nvidia-modeset/nvidia-modeset-freebsd.c.orig:MODULE_DEPEND(nvidia_modeset,               /* module name */
src/nvidia-modeset/nvidia-modeset-freebsd.c.orig:MODULE_DEPEND(nvidia_modeset,               /* module name */
x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.39 % grep "MODULE_DEPEND(nvidia_modeset" src/nvidia-modeset/nvidia-modeset-freebsd.c.orig -A 5
MODULE_DEPEND(nvidia_modeset,               /* module name */
              nvidia,                       /* prerequisite module */
              1, 1, 1);                     /* vmin, vpref, vmax */

#if defined(NVKMS_SUPPORT_LINUX_COMPAT)
MODULE_DEPEND(nvidia_modeset,               /* module name */
              linux,                        /* prerequisite module */
              1, 1, 1);                     /* vmin, vpref, vmax */
#endif
```


----------



## Truculent_Freddi (Feb 14, 2021)

SirDice said:


> Where do people get this from? I've seen this so many times now. It's wrong. The only thing that works here is the nvidia_load, everything else is a no-op.






_View: https://www.youtube.com/watch?v=Q6KxMUY2aTU_
 - i used this method, and, i've seen it too many time on different russian forum(I am Russian). i changed nvidia-modeset and it doesn't work. P:S I only left nvidia_load as you told me. i still have this problem[/icode]
[/QUOTE]


----------



## Truculent_Freddi (Feb 14, 2021)

the3ajm said:


> Did you install the port x11/nvidia-driver, can you also paste your xorg.conf? Alternatively you can configure your driver from the following port: x11/nvidia-xconfig and x11/nvidia-settings


I've already used nvidia-xconfig, I think it's not because of this

```
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig: version 440.100

Section "ServerLayout"
    Identifier "Layout0"
    Screen 0 "Screen0"
    InputDevice "Keyboard0" "CoreKeyboard"
    InputDevice "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"
    # generated from default
    Identifier "Mouse0"
    Driver "mouse"
    Option "Protocol" "auto"
    Option "Device" "/dev/sysmouse"
    Option "Emulate3Buttons" "no"
    Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier "Keyboard0"
    Driver "keyboard"
EndSection

Section "Monitor"
    Identifier "Monitor0"
    VendorName "Unknown"
    ModelName "Unknown"
    Option "DPMS"
EndSection

Section "Device"
    Identifier "Device0"
    Driver "nvidia"
    VendorName "NVIDIA Corporation"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device "Device0"
    Monitor "Monitor0"
    DefaultDepth 24
    SubSection "Display"
        Depth 24
    EndSubSection
EndSection
```


----------



## Truculent_Freddi (Feb 14, 2021)

Snurg said:


> This is a known bug with the vt console.
> If there are no reasons that force you to use the vt console, just work around it by using the sc console. This also makes suspend/resume (sleep) work.


it's work, i used  kern.vty="sc". And 
however, I am deprived of the ability to use vidcontrol, although it did not work before "vidcontrol mode -i
vidcontrol: getting active vty: Inappropriate ioctl for device "
------------------------
it is written in the kernel GENERIC configuration ----- 
device          vga                     # VGA video card driver
options         VESA                    # Add support for VESA BIOS Extensions >

device          splash                  # Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device          sc
options         SC_PIXEL_MODE           # add support for the raster text mode

# vt is the new video console driver
device          vt
device          vt_vga
device          vt_efifb
_______


----------



## Snurg (Feb 14, 2021)

`vidcontrol` only works when used from a console.
(Use Ctrl-Alt0-F1-F8, and F9 for going back to X)
If it is used from a xterm, that error message is normal.


----------



## Truculent_Freddi (Feb 15, 2021)

Snurg said:


> `vidcontrol` only works when used from a console.
> (Use Ctrl-Alt0-F1-F8, and F9 for going back to X)
> If it is used from a xterm, that error message is normal.


i used it from a console tty0, and then i use any mods with option G(graphic, not T - text), i get the error which i mentioned earlier(artifacts). In addition, the whole system starts to lag


----------



## SirDice (Feb 15, 2021)

The old sc(4) terminal is terribly slow, especially in graphics modes. But why bother with the console if you have a high-resolution GUI desktop?

`pkg install nvidia-driver`
In rc.conf:

```
kld_list="nvidia-modeset"
```

Create a /usr/local/etc/X11/xorg.conf.d/driver-nvidia.conf:

```
Section "Device"
        Identifier "Card0"
        Driver     "nvidia"
EndSection
```

That's all the configuration you need to do to get the NVidia driver working.


----------



## Truculent_Freddi (Feb 18, 2021)

SirDice said:


> The old sc(4) terminal is terribly slow, especially in graphics modes. But why bother with the console if you have a high-resolution GUI desktop?
> 
> `pkg install nvidia-driver`
> In rc.conf:
> ...



the nvidia driver is already working, I added everything you need to work gdm, I suppose if it did not work, the resolution would be 4: 3, not 16: 9. Sometimes I have to use the system console, when I edit something wrong somewhere and cannot use the graphical shell. In addition, I am researching freebsd and this kind of problem should be fixed if it occurs, in my opinion it helps to better understand the system.


----------



## Truculent_Freddi (Feb 18, 2021)

Snurg said:


> If it is used from a xterm, that error message is normal.


and then what to use instead xterm of in the file /etc/ttys?


----------



## SirDice (Feb 18, 2021)

Truculent_Freddi said:


> I am researching freebsd and this kind of problem should be fixed if it occurs, in my opinion it helps to better understand the system.


The old sc(4) console was replaced with vt(4) because there were many more problems with it. The biggest reason for example was the lack of UTF-8 support, a second reason was the lack of KMS support. 



			Newcons - FreeBSD Wiki


----------



## Snurg (Feb 18, 2021)

Truculent_Freddi said:


> and then what to use instead xterm of in the file /etc/ttys?


Switch to the console (ALT-CTRL plus one of F1...F8).
su to root.
Then the vidcontrol program notices, "ahh this is a console I can control and I have the permission to do so also".



SirDice said:


> The old sc(4) console was replaced with vt(4) because there were many more problems with it. The biggest reason for example was the lack of UTF-8 support, a second reason was the lack of KMS support.


But what if one does not care about KMS, does not need UTF-8 on console, wants a working text mode console (i.e. no graphics mode), and wants suspend/resume work on Nvidia cards?
I tried `vt` 5 years ago, and then 2 years ago again, and again in December last year, and the bugs I PRed 5 years ago are still there, rendering work with `vt` no fun for me.
Admittedly there is no much incentive for fixing these bugs that affect only the text mode `vt`, which very few people use, as there are many things of higher priority.

So my personal opinion is that `sc` should be valued and preserved as mission-saving fallback when `vt` fails, like in Truculent_Freddi 's case.

As there are reasons why some people need vt, there is also some kind of forced lock-in, as this reveals:


> Me: Couldn't the VT console be put back to experimental status until its issues are fixed?
> Ed Maste: No, because sc(4) does not work with UEFI or with KMS graphics drivers, leaving many users with no console at all.


So I believe there are quite some people to which `vt` does not feel like an improvement, and have legit reasons to stick with `sc`.


----------



## shkhln (Feb 18, 2021)

Snurg said:


> But what if one does not care about KMS, does not need UTF-8 on console, wants a working text mode console (i.e. no graphics mode), and wants suspend/resume work on Nvidia cards?




```
% cat /boot/loader.conf | grep text
hw.vga.textmode=1
```


----------



## Snurg (Feb 18, 2021)

shkhln I wish you would read more thoroughly. Then you would have known that the problem is not finding out how to switch to text mode, but the deficiencies in `vt`, both in graphics and text modes.


----------



## shkhln (Feb 18, 2021)

I'm only replying in the context of OP's issue.


----------



## Mjölnir (Feb 18, 2021)

SirDice said:


> The old sc(4) console was replaced with vt(4) because there were many more problems with it. The biggest reason for example was the lack of UTF-8 support, a second reason was the lack of KMS support.
> 
> 
> 
> Newcons - FreeBSD Wiki


syscons(4) has an experimental UTF-8 addon: put `options TEKEN_UTF8` in the kernel config.  I had that running back in the syscons(4) days, it was ok for me.  But I can't tell how complete that implementation is, since the code points >7-bit ascii(7) I use in the german alphabet are only a handful, and additionally these are equal in UTF-8 & iso-latin1.  Maybe for greek or kyrillic and others, the story is different.


----------



## chrbr (Feb 18, 2021)

Before vt(4) has been introduced it has been possibe to run applications as mail readers in a x11/luit environment. The tool converted for example UTF-8 mails to be presented in a ISO8859-1 capable terminal. The man page says it has been designed for X11. It has been around FreeBSD-9.x times when I have used it. I do not remember for sure if it worked on the console, too. If yes, then it could be a workaround for some use cases with syscons(4).


----------

