Horrible green background in tty on HDMI

Hello, I recently changed my monitor from DVI to HDMI. After that in tty the background is a horrible green color, which is very difficult to work with the terminal.

In the X11 based session there were color problems, but I fixed it by adjusting the configuration file, now everything is fine. The wayland based session also works fine, so this problem only shows up in tty .

Does anyone have any idea how to fix this ? I tried to find the answer on the internet and on this forum, but only found an old thread with no answer.
I am using a nvidia 1650 video card, driver version 530.41.03. All kernel modules are loaded and work correctly

inxi --display -x -G -S
System:
Host: pc Kernel: 6.3.7-1-MANJARO arch: x86_64 bits: 64 compiler: gcc
v: 13.1.1 Desktop: KDE Plasma v: 5.27.5 Distro: Manjaro Linux
base: Arch Linux
Graphics:
Device-1: NVIDIA TU117 [GeForce GTX 1650] vendor: Micro-Star MSI
driver: nvidia v: 530.41.03 arch: Turing bus-ID: 29:00.0
Display: wayland server: X.org v: 1.21.1.8 with: Xwayland v: 23.1.2
compositor: kwin_wayland driver: X: loaded: nvidia gpu: nvidia
resolution: 1920x1080
API: OpenGL v: 4.6.0 NVIDIA 530.41.03 renderer: NVIDIA GeForce GTX
1650/PCIe/SSE2 direct-render: Yes

I added the picture under a spoiler for clarity, sorry for the quality.

Спойлер

Thanks !

Hello @Metam0rph0sis :wink:

  1. Nvidia + Wayland is considered experimental, has bugs and since it needs KMS, note that NVIDIA has limited and experimental support here. Plus, it is in heavy development.
  2. Since KMS is involved, you can only change that behavior (if possible) by module parameters, everything else is made to be detected automatically.

So at the end: If it doesn’t work, ask NVIDIA.

1 Like

Hi,I am not considering a wayland implementation because tty does not use wayland as far as I know. Also, everything worked fine with my previous DVI monitor

Sure, but TTY uses KMS aswell as Wayland, and there comes NVIDIA into play.

Maybe the cable/port? A loose contact? DVI and VGA are famous for it, since it is an analog signal. Other than that no idea. :man_shrugging:

I thought it might be a problem with the cable, but then the distortion would be everywhere, not just in the tty, isn’t that right?

Yeah that is right. I remember a Problem with amdgpu, where you get a greenish screen when you switch from DVI to HDMI: no color format choice in amdgpu (#476) · Issues · drm / amd · GitLab It seems to prefer YCrCb instead of RGB, but when you screen runs in RGB and driver runs in YCrCb then you get such a greenish screen. There is a parameter for the amdgpu module now, but no idea about NVIDIA.

So the issue seems to be the color profile?!

Maybe, I read the section in arch wiki , it says that colord.service is not compatible with the nvidia driver. I have added some profiles via colormgr device-add-profile but I cannot switch them. I tried colord-kde (no visible effect) and dispwin gives an error Dispwin: Error - file name.icc is not a valid ICC profile or Argyll .cal file. I’m even thinking of installing windows 11 on an external drive and taking the profile from there.

I did some tests with video drivers, including installing windows 11 to go on my external drive. This problem does not show up on open drivers, it seems to be a problem specifically with the nvidia drivers, but I have no idea how to fix it. If anyone has any ideas I would love to know.

@Metam0rph0sis

Does it happen with NVIDIA module and without nvidia-drm.modeset=1 ? So does it happen when the NVIDIA doesn’t run in KMS mode?

You used Xorg and fixed it by a Configuration. What have you applied?

Anyway… that would be rather a question for the NVIDIA developers.

what’s the output of

echo $XDG_SESSION_TYPE

wayland ? if so then forget it. wayland does not work with nvidia and this won’t change in the near/middle future.

I tried :

nvidia-drm.modeset=1 nvidia-drm.modeset=0 nvidia_drm.modeset=1 nomodeset and not use modeset

at all.
in case I do not use

modeset or nvidia-drm.modeset=0 , nomodeset

. There is no problem with displaying tty in the terminal. This can be used as a workaround, but I want to understand the cause of the problem.
I tried disabling framebuffer in grub and adding variables

GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia

to force the use of GBM, but this had no effect.

Truth is, I ran monitor autodetection in nvidia-settings and specified the refresh rate, then saved the new settings and restarted the session, that was enough.

as previously discussed, the problem only occurs in the tty console BEFORE starting the graphical shell, in X11/wayland everything is fine.

And that is the default for Nvidia: No modeset or KMS. Again: Nvidia has limited and experimental support for KMS thus it is disabled by default.

Well, you can also test the open source module from NVIDIA: GitHub - NVIDIA/open-gpu-kernel-modules: NVIDIA Linux open GPU kernel module source and your GPU seems to be supported. Anyway… at this moment it has also a lot of bugs regarding KMS.

If you have programming skills, then take a look here:

KMS could be better supported on the open module, but no guarantee.

I thought about using open source kernel modules, but at the moment that seems redundant to me and they still have beta status. Unfortunately, I don’t know the C language well enough to understand the driver’s device. I heard that nvidia is planning to move away from proprietary modules and go for open source implementation, that would be a good solution but it might take years.

I will create a thread in nvidia forum , maybe they will come up with some solution , if an acceptable solution is found i think i will post in this thread .

Thank you for your time anyway.

Well, for all the time on the nvidia forum I have not received an answer, it seems that no one simply does not care. I found a questionable solution to replace getty with kmscon for tty starting from 3. It’s not a perfect solution, but it works for me.

Note: don’t use this as @tty1.service.

By default, you can’t login as root, but you can use su

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.