Artifacts / tearing in text terminal with tty1-tty7

[Truculent_Freddi]

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

Code:

kld_list = "linux nvidia"
gnome_enable = "YES"
moused_enable = "YES"
dbus_enable = "YES"
hald_enable = "YES"
gdm_enable = "YES"

in /etc/fstab

Code:

proc / proc procfs w 0 0

in /boot/loader.conf

Code:

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]

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]

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]

Code:

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 =.

Code:

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

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]

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]

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]

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]

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:

Code:

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]

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]

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

Code:

# 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]

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]

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]

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]

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:

Code:

kld_list="nvidia-modeset"

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

Code:

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

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

 

[Truculent_Freddi]

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:

Code:

kld_list="nvidia-modeset"

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

Code:

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

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

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]

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]

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]

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".

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 [USER=65398]Truculent_Freddi[/USER] '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]

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?

Code:

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

 

[Snurg]

[USER=54069]shkhln[/USER] 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]

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

 

[Mjölnir]

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]

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).