NVIDIA Graphics Card: Plugged in HDMI cable causes ^@-characters to be printed to TTY

Originally Posted by business_kid On the lsmod: Do you really need i915? That's an intel graphics driver. Have we dual cards here? If you're not using the intel card, have you tried blacklisting it? It will want standard Mesa libGL stuff, and Nvidia wants it's own proprietary ones. The two will not work together. You can see what you have with ls -l /usr/lib(64)/libGL* The actual libraries will show a Mesa number, or a Nvidia one. What matters is which the symlinks point at

It's an Optimus card, so there is both, an nvidia card and an intel onboard card.

# ls -l /usr/lib64/libGL*
-rwxr-xr-x 1 root root  711864 15. Jun 16:52 /usr/lib64/libGLdispatch.so.0
lrwxrwxrwx 1 root root      29 15. Jun 16:52 /usr/lib64/libGLESv1_CM_nvidia.so.1 -> libGLESv1_CM_nvidia.so.390.67
-rwxr-xr-x 1 root root   60200 15. Jun 16:52 /usr/lib64/libGLESv1_CM_nvidia.so.390.67
lrwxrwxrwx 1 root root      21 15. Jun 16:52 /usr/lib64/libGLESv1_CM.so -> libGLESv1_CM.so.1.2.0
lrwxrwxrwx 1 root root      21 15. Jun 16:52 /usr/lib64/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.2.0
-rwxr-xr-x 1 root root   43696 15. Jun 16:52 /usr/lib64/libGLESv1_CM.so.1.2.0
lrwxrwxrwx 1 root root      26 15. Jun 16:52 /usr/lib64/libGLESv2_nvidia.so.2 -> libGLESv2_nvidia.so.390.67
-rwxr-xr-x 1 root root  111400 15. Jun 16:52 /usr/lib64/libGLESv2_nvidia.so.390.67
lrwxrwxrwx 1 root root      18 15. Jun 16:52 /usr/lib64/libGLESv2.so -> libGLESv2.so.2.1.0
lrwxrwxrwx 1 root root      18 15. Jun 16:52 /usr/lib64/libGLESv2.so.2 -> libGLESv2.so.2.1.0
-rwxr-xr-x 1 root root   83280 15. Jun 16:52 /usr/lib64/libGLESv2.so.2.1.0
lrwxrwxrwx 1 root root      14 15. Jun 16:52 /usr/lib64/libGL.so -> libGL.so.1.7.0
lrwxrwxrwx 1 root root      14 15. Jun 16:52 /usr/lib64/libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x 1 root root  665720 15. Jun 16:52 /usr/lib64/libGL.so.1.7.0
lrwxrwxrwx 1 root root      23 15. Jun 16:52 /usr/lib64/libGLX_indirect.so.0 -> libGLX_nvidia.so.390.67
lrwxrwxrwx 1 root root      23 15. Jun 16:52 /usr/lib64/libGLX_nvidia.so.0 -> libGLX_nvidia.so.390.67
-rwxr-xr-x 1 root root 1268112 15. Jun 16:52 /usr/lib64/libGLX_nvidia.so.390.67
lrwxrwxrwx 1 root root      11 15. Jun 16:52 /usr/lib64/libGLX.so -> libGLX.so.0
-rwxr-xr-x 1 root root   65168 15. Jun 16:52 /usr/lib64/libGLX.so.0

# ls -l /usr/lib/libGL*
-rwxr-xr-x 1 root root  711864 15. Jun 16:52 /usr/lib/libGLdispatch.so.0
lrwxrwxrwx 1 root root      29 15. Jun 16:52 /usr/lib/libGLESv1_CM_nvidia.so.1 -> libGLESv1_CM_nvidia.so.390.67
-rwxr-xr-x 1 root root   60200 15. Jun 16:52 /usr/lib/libGLESv1_CM_nvidia.so.390.67
lrwxrwxrwx 1 root root      21 15. Jun 16:52 /usr/lib/libGLESv1_CM.so -> libGLESv1_CM.so.1.2.0
lrwxrwxrwx 1 root root      21 15. Jun 16:52 /usr/lib/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.2.0
-rwxr-xr-x 1 root root   43696 15. Jun 16:52 /usr/lib/libGLESv1_CM.so.1.2.0
lrwxrwxrwx 1 root root      26 15. Jun 16:52 /usr/lib/libGLESv2_nvidia.so.2 -> libGLESv2_nvidia.so.390.67
-rwxr-xr-x 1 root root  111400 15. Jun 16:52 /usr/lib/libGLESv2_nvidia.so.390.67
lrwxrwxrwx 1 root root      18 15. Jun 16:52 /usr/lib/libGLESv2.so -> libGLESv2.so.2.1.0
lrwxrwxrwx 1 root root      18 15. Jun 16:52 /usr/lib/libGLESv2.so.2 -> libGLESv2.so.2.1.0
-rwxr-xr-x 1 root root   83280 15. Jun 16:52 /usr/lib/libGLESv2.so.2.1.0
lrwxrwxrwx 1 root root      14 15. Jun 16:52 /usr/lib/libGL.so -> libGL.so.1.7.0
lrwxrwxrwx 1 root root      14 15. Jun 16:52 /usr/lib/libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x 1 root root  665720 15. Jun 16:52 /usr/lib/libGL.so.1.7.0
lrwxrwxrwx 1 root root      23 15. Jun 16:52 /usr/lib/libGLX_indirect.so.0 -> libGLX_nvidia.so.390.67
lrwxrwxrwx 1 root root      23 15. Jun 16:52 /usr/lib/libGLX_nvidia.so.0 -> libGLX_nvidia.so.390.67
-rwxr-xr-x 1 root root 1268112 15. Jun 16:52 /usr/lib/libGLX_nvidia.so.390.67
lrwxrwxrwx 1 root root      11 15. Jun 16:52 /usr/lib/libGLX.so -> libGLX.so.0
-rwxr-xr-x 1 root root   65168 15. Jun 16:52 /usr/lib/libGLX.so.0

On the symlinks:

That's interesting - it appears Nvidia have renamed their libGL stuff since I last installed a Nvidia binary blob to coexist with Mesa stuff and allow the dual card scenario. I'm surprised it works, because Mesa will call it's own libs. . .

I'll go quiet now, because I don't have any more ideas for you, unless you log in on the Intel card or something. When I last bought a pc, dual graphics and UEFI were new and support for either was non existent or flaky, and I shopped accordingly.

What do you mean by "log in on the intel card"?
During boot and log in the hdmi display (i.e. the one wired to the nvidia card) stays dark...

EDIT: ...the obvious reason being that my xrandr scripts are running after login...

EDIT2: or maybe not so obvious after all? Maybe I should expect the console output to be duplicated to thehdmi display like it is to the vga display?

I know little of your setup. I presume 2 cards means 2 monitors. I am set up to run 3 monitors with three different resolutions displaying 2 screens (Left & Right) on one Intel card. If you have a nvidia card, I find it hard to imagine you needing the services of an intel gpu unless they're forced on you by plug wiring or the like.

The improvement you seek may be in carefully setting things up in /etc/X11/xorg.conf.d, with something like a '20-video.conf' file. Look at 'man xorg.conf' for the syntax. I never touch xrandr to get the above.

On edit2, you can configure it that way as I suggested.

Originally Posted by business_kid I know little of your setup. I presume 2 cards means 2 monitors. I am set up to run 3 monitors with three different resolutions displaying 2 screens (Left & Right) on one Intel card. If you have a nvidia card, I find it hard to imagine you needing the services of an intel gpu unless they're forced on you by plug wiring or the like. The improvement you seek may be in carefully setting things up in /etc/X11/xorg.conf.d, with something like a '20-video.conf' file. Look at 'man xorg.conf' for the syntax. I never touch xrandr to get the above. On edit2, you can configure it that way as I suggested.

The setup is simple. Its an Notebook with an nvidia optimus card. That implies the additional intel card. The nvidia is wired to the hdmi port and the intel is wired to the vga port. If I want to use both ports to get a 3-monitors setup (including the laptop screen) I must use both cards. As stupid as this may sound.
(This is definitely my last nvidia graphics laptop ever.)
I still do not understand why xorg related config is supposed to address any of this and on edit2 I wouldn't know where to configure this. This is before X as previously stated...

X is fairly intelligent about configuring itself. For pre-X console level, you have kernel module options, which are limited, and which I never had to read up on extensively. I know they exist, but how productive they are is another matter. But a search for 'nvidia kernel module options' produced plenty of hits, and I presume the same would go for intel.

You could probably use boot options also to define your default screen, set modes, and suchlike. Is it worth it to get rid of a few stray characters? That's up to you.

It's common issue since last year, caused by specific kernel & Nvidia driver combination. Try reverting kernel to 4.9 or 4.14, or updating it to 4.18, all while keeping Nvidia drivers updated. Alternatively, blacklist modules as specified here: https://unix.stackexchange.com/q/396192/231541

Originally Posted by pzmarzly It's common issue since last year, caused by specific kernel & Nvidia driver combination. Try reverting kernel to 4.9 or 4.14, or updating it to 4.18, all while keeping Nvidia drivers updated. Alternatively, blacklist modules as specified here: https://unix.stackexchange.com/q/396192/231541

Thanks a lot pzmarzly for this input, and welcome to LQ.

So I already am on 4.9 for sometime ... I recently had to downgrade because of another NVIDIA related issue (which I can't remember the details right now). So I am now running the LTS of my distro (void):

~# uname -r
4.9.119_1

Although I presumed that this would not help much on 4.9 I tried blacklisting as advised anyways:

~# cat /etc/modprobe.d/input_polldev.conf 
blacklist input_polldev

After reboot I doublechecked with

lsmod | grep poll

which returned no output.

Sadly, the problem persists. Any further ideas?

Originally Posted by business_kid X is fairly intelligent about configuring itself. For pre-X console level, you have kernel module options, which are limited, and which I never had to read up on extensively. I know they exist, but how productive they are is another matter. But a search for 'nvidia kernel module options' produced plenty of hits, and I presume the same would go for intel. You could probably use boot options also to define your default screen, set modes, and suchlike. Is it worth it to get rid of a few stray characters? That's up to you.

Some more data: adding the kernel parameter "nomodeset" makes the problem go away but leads to the LVDS and VGA displays not being recognized after X startup. (This might require tweaking in the xorg.conf...?)

Following the arch wiki article on modesetting under https://wiki.archlinux.org/index.php...ng_modesetting I tried various combinations of nomodeset, i915.modeset=0 and nouveau.modeset=0, but the only one that made a difference was plain nomodeset. I was surprised there is no nvidia.modeset parameter... (I am not using the nouveau driver).

Currently looking into the video= parameter but it's all very much trial and error at this point...

And one more finding: It is enough to switch off the monitor that is connected via HDMI to make the problem go away. I thought maybe it is a problem with the monitor and swapped the two devices. I.e. I connected the other display (which is normally attached via VGA) to the HDMI port and vice versa. Still the problem persists.

If it helps, here is my kernel cmdline:

cat /proc/cmdline
\\vmlinuz-4.18-x86_64 rw i915.enable_rc6=0 i915.enable_psr=0 i915.preliminary_hw_support=1 i915.enable_hd_vgaarb=1 intel_idle.max_cstate=1 root=LABEL=Manjaro initrd=\initramfs-4.18-x86_64.img

Both 4.14 and 4.18 kernels seem to work fine.

Originally Posted by pzmarzly If it helps, here is my kernel cmdline: cat /proc/cmdline \\vmlinuz-4.18-x86_64 rw i915.enable_rc6=0 i915.enable_psr=0 i915.preliminary_hw_support=1 i915.enable_hd_vgaarb=1 intel_idle.max_cstate=1 root=LABEL=Manjaro initrd=\initramfs-4.18-x86_64.img Both 4.14 and 4.18 kernels seem to work fine.

These params are all intel related, aren't they? Do you have an nvidia optimus card?

Those boot options seem top cement your intel card to the primary monitor. Ok, if that's what you want. With a nvidia card onboard, I'd be looking for an i915-disable boot option :P

Originally Posted by business_kid Those boot options seem top cement your intel card to the primary monitor. Ok, if that's what you want. With a nvidia card onboard, I'd be looking for an i915-disable boot option :P

Huh?!? Why would I want to disable the intel card?!?
Not sure if you overlooked that these are not my kernel params but pzmarzly's.
What I really want is to stop the nvidia card from spamming to tty... So I'd expect to have to use an nvidia kernel param...