Color management, Nvidia, X11 issues

I’ve recently switched from Fedora 36 to F38 by completely reinstalling it and now the color management doesn’t work as it did anymore. I’m at my whits’ end so I was hoping someone could help.

I’ve already had it before on F36 that for some reason, sometimes when I boot up this same PC, the colors were abnormal which could be seen by overly saturated colors. A reboot would always fix it though, so I never investigated any further.

Now on my F38 re-install, I can’t get the colors to look as they used to anymore at all. They’re always wrong, just like when I had to reboot before. I’m using the same color profile as before (made with DisplayCal in 2020) since I’m using the same user profile (/home dir) as on F36 and there’s only 1 monitor connected. But something’s off.

For one, switching the color management toggle in Gnome Settings off does nothing, but activating different profiles does have an effect on the image. So there seems to be a bug there.

Then the colors are way overblown. Except for in color managed applications like Firefox with that same ICC profile configured. There, colors look correct. But the Gnome GUI looks like a candy store - which it didn’t used to. I read that this is supposedly normal, but I swear by my life it wasn’t like that before. I work in media production so I’m not a complete layman when it comes to color management.

So does anyone have any hints on what the issue may be? I still have the full F36 installation to compare, but I don’t know what to look for.

The gnome settings has this panel which says that color profiles need to be up to date.

image

I don’t know what your devices are, and you did say nvidia, so I need to ask if you are using the nvidia drivers from rpmfusion?

If on the nouveau drivers or with older GPUs things may need to be tweaked.

Please post the output of dnf list installed '*nvidia*' and lspci -nnv | grep -A2 -i VGA so we may see the devices and drivers in use

I am using the RPMFusion driver.

akmod-nvidia.x86_64                                         3:530.41.03-1.fc38                    @rpmfusion-nonfree-nvidia-driver
kmod-nvidia-6.2.15-300.fc38.x86_64.x86_64                   3:530.41.03-1.fc38                    @@commandline                   
kmod-nvidia-6.3.4-201.fc38.x86_64.x86_64                    3:530.41.03-1.fc38                    @@commandline                   
nvidia-gpu-firmware.noarch                                  20230515-150.fc38                     @updates                        
nvidia-settings.x86_64                                      3:530.41.03-1.fc38                    @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia.x86_64                                  3:530.41.03-1.fc38                    @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda-libs.x86_64                        3:530.41.03-1.fc38                    @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-kmodsrc.x86_64                          3:530.41.03-1.fc38                    @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-libs.i686                               3:530.41.03-1.fc38                    @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-libs.x86_64                             3:530.41.03-1.fc38                    @rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-power.x86_64                            3:530.41.03-1.fc38                    @rpmfusion-nonfree-nvidia-driver

$ lspci -nnv | grep -A2 -i VGA
09:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3060 Ti Lite Hash Rate] [10de:2489] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:405b]
	Flags: bus master, fast devsel, latency 0, IRQ 107

I’d be surprised if the problem was an outdated profile. It sure didn’t complain about it when adding it, neither did colormgr when I removed and re-added it from the terminal.

It seems possible that you have something in the user config that could interfere with colors. I have a rather generic user config with an RTX 3050 GPU and have not seen any issues with colors.

Have you tried creating another new user then log in with that user and see if there is a difference? That may aid to identify if it is a user config issue that causes it.

I’ve just tried it in a new user account under X11 and didn’t seem to make a difference. I noticed that my F36 install had a nvidia-drm.modeset=1 param in the kernel line in Grub, but that didn’t make a difference either when I tried it out.

Could this have something to do with Fedora defaulting to Wayland even on Nvidia? Maybe something was changed that now results in overly saturated colors?

Unfortunately I can’t boot the F36 install anymore, because I moved from BIOS/MBR to UEFI/GPT.

To me it seems like a race condition issue, because of how the colors could be overly saturated even before and how a reboot always fixed it. But what exactly could it have been?

I had DisplayCAL installed natively which isn’t available on F38 anymore because it doesn’t ship Python2 anymore so I’m using it via Flatpak now. Maybe that did something? It comes with its own ICC loader after all. Maybe that one did it better? And maybe the Gnome loader sometimes got in first (last?), which was when the colors were overly saturated?

I wonder if it still may be related to the kernel command line.

Please post the output of cat /proc/cmdline so we may see exactly what is set.

On my latest kernel upgrades, to 6.3.4 & 6.3.5 I had a system with a perfectly good boot that failed as a result of a command line option that worked with all kernels up thru 6.2.X but caused failure with the 6.3 kernels. Once the command line option was identified and fixed then booting worked again.

BOOT_IMAGE=(hd4,gpt3)/vmlinuz-6.3.4-201.fc38.x86_64 root=UUID=e83257b4-6884-45bd-a01a-141d707e9a7c ro rootflags=subvol=root rd.driver.blacklist=nouveau modprobe.blacklist=nouveau rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau video=None-1-1:d resume=UUID=ae10a61e-256c-4275-8416-021bd67029e8

One thing I see there is the video=None-1-1:d option. One might try editing the command line during boot from the grub menu edit feature and remove that from the command line and see if there is a difference. I also note that it seems you are using nvidia, so adding nvidia-drm.modeset=1 might also have an effect. Maybe try first removing the one option and if that does not work then try adding the other, and work with different combinations of those 2 options until it either works properly or all have been tried.

Editing the grub command line during boot is not permanent, but once you know what works properly then we can make the change permanent.

I put the video parameter there myself because after switching to UEFI, a phantom display showed up and that’s how I got rid of it.

Isn’t it nvidia-drm.modeset=1 ? (. instead of -) Like I said, I already tried that with 0 and 1, neither changed anything.

Correct that was a typo and I fixed it. Thanks for catching it.

I just looked in the latest nvidia xsettings and found this

Settings there for your monitor may affect things as well.

The icon for the Nvidia X Server Settings opens that up.

I’m aware of that. It’s set to defaults. I could turn down the digital vibrancy knob on the controls tab, but that would make the colors wrong in actually color managed programs like Gimp, wouldn’t it?

Btw. thanks for trying to help.

It’s weird seen these other threads in here about colors being to dull. I wish that was the case.