Arch Linux User Repository

Color profiles (to be pinned)

If, like me, you have been affected by a degrading in the quality of colors, the following procedure can help (source). The result affects all applications, but especially Chrome-based browsers and Electron-based applications will benefit.

Extract

Chrome retrieves the color profile to use from the _ICC_PROFILE atom on the root window.

• Step 1: Within your Desktop settings, visit the Color management properties editor
• Step 2: For each monitor, expand the monitor’s profiles, select each profile, and click “Remove profile” until no profiles remain
• Step 3: Restart Chrome

Using colormgr from the command line

To persistently set the colord default color space from the command line, copy-paste the following block into a terminal

SRGB_PATH=$(colormgr get-standard-space srgb | grep "Object Path:" | cut -d: -f2);
for DISPLAY_PATH in $(colormgr get-devices display | grep "Object Path:" | cut -d: -f2)
do
  colormgr device-add-profile $DISPLAY_PATH $SRGB_PATH;
  colormgr device-make-profile-default $DISPLAY_PATH $SRGB_PATH;
done

or follow the below steps:

Step 1: Get the object path for the sRGB colorspace. Do this by running: colormgr get-standard-space srgb Note down the “Object Path” (it will be something like /org/freedesktop/…). We’ll refer to this path as SRGB_PATH in future steps.

Step 2: Get the object paths for the devices for which you want to reset. Do this by running colormgr get-devices Note down the “Object Path” of each device you want to set the color profile for (again it will be something like /org/freedesktop/…). We’ll refer to each of these paths as DISPLAY_PATH in future steps.

Step 3: For each device, register the sRGB color profile with the device. Do this by running: colormgr device-add-profile DISPLAY_PATH SRGB_PATH Where SRGB_PATH is the path obtained in step 1 and DISPLAY_PATH is the path for each device obtained in step 2. Note that you may ignore error reports saying “profile object path … has already been added”.

Step 4: For each device, set the default color profile to be the sRGB color profile. Do this by running: colormgr device-make-profile-default DISPLAY_PATH SRGB_PATH Again, here SRGB_PATH is the path obtained in step 1 and DISPLAY_PATH is the path for each device obtained in step 2.

Step 5: Restart Chrome

Using xprop (current session only)

To remove the color profile for the current session only, run xprop -root -remove _ICC_PROFILE You’ll need to restart Chrome for us to re-read the property.

Note that this will only apply to the current session.

Color profiles (to be pinned)

If, like me, you have been affected by a degrading in the quality of colors, the following procedure can help (source). The result affects all applications, but especially Chrome-based browsers and Electron-based applications will benefit.

Extract

Chrome retrieves the color profile to use from the _ICC_PROFILE atom on the root window.

• Step 1: Within your Desktop settings, visit the Color management properties editor
• Step 2: For each monitor, expand the monitor’s profiles, select each profile, and click “Remove profile” until no profiles remain
• Step 3: Restart Chrome

Using colormgr from the command line

To persistently set the colord default color space from the command line, copy-paste the following block into a terminal

SRGB_PATH=$(colormgr get-standard-space srgb | grep "Object Path:" | cut -d: -f2);
for DISPLAY_PATH in $(colormgr get-devices display | grep "Object Path:" | cut -d: -f2)
do
  colormgr device-add-profile $DISPLAY_PATH $SRGB_PATH;
  colormgr device-make-profile-default $DISPLAY_PATH $SRGB_PATH;
done

or follow the below steps:

Step 1: Get the object path for the sRGB colorspace. Do this by running: colormgr get-standard-space srgb Note down the “Object Path” (it will be something like /org/freedesktop/…). We’ll refer to this path as SRGB_PATH in future steps.

Step 2: Get the object paths for the devices for which you want to reset. Do this by running colormgr get-devices Note down the “Object Path” of each device you want to set the color profile for (again it will be something like /org/freedesktop/…). We’ll refer to each of these paths as DISPLAY_PATH in future steps.

Step 3: For each device, register the sRGB color profile with the device. Do this by running: colormgr device-add-profile DISPLAY_PATH SRGB_PATH Where SRGB_PATH is the path obtained in step 1 and DISPLAY_PATH is the path for each device obtained in step 2. Note that you may ignore error reports saying “profile object path … has already been added”.

Step 4: For each device, set the default color profile to be the sRGB color profile. Do this by running: colormgr device-make-profile-default DISPLAY_PATH SRGB_PATH Again, here SRGB_PATH is the path obtained in step 1 and DISPLAY_PATH is the path for each device obtained in step 2.

Step 5: Restart Chrome

Using xprop (current session only)

To remove the color profile for the current session only, run xprop -root -remove _ICC_PROFILE You’ll need to restart Chrome for us to re-read the property.

Note that this will only apply to the current session.

@FishBoneEK this is intentional, linux-headers should not be included as a dependency in dkms packages. Wiki link: DKMS guidelines

Installing this package requires building kernel module, which requires linux-headers to make successful build. Add linux-headers to dependency?

@ogarcia

same here for some reason its just happens with the gdm display manager but if i initialize with sddm display manager and select the same desktop with gnome/wayland it will work fine i dont know why its happening

@ogarcia. exactly the same issue here ! Same workaround. Very strange indeed...

Edit : problem solved (just workaround ?) by adding the "nvidia_drm.modeset=1" option to my grub. (Note: I use x11 and not wayland)

Hi! I don't know if this has happened to anyone but with the latest driver update a second monitor has appeared (connected to None-1-1) which makes me that the desktop is displayed twice as wide as normal and as I approach the mouse pointer to the corners it moves, ie, my resolution is 1680x1050 but I have a desktop of 3360x1050.

I have this card:

[   822.146] (II) NVIDIA(0): NVIDIA GPU NVIDIA GeForce GTX 660 (GK106) at PCI:15:0:0
[   822.146] (II) NVIDIA(0):     (GPU-0)
[   822.146] (--) NVIDIA(0): Memory: 2097152 kBytes
[   822.146] (--) NVIDIA(0): VideoBIOS: 80.06.58.00.09
[   822.146] (II) NVIDIA(0): Detected PCI Express Link width: 16X

I have solved it with the GNOME monitor configuration telling it to mirror the real monitor but it is something strange and it has never happened to me before. Any idea? Has it happened to anyone else?

@caiotbc, I have a similar hardware setup, with a similar problem, almost 6 months ago with windows giving me error 43, then I migrated to an arch VM, and these last months even the arch VM won't boot anymore, I was using already linux-lts510, but as the kernel versions keep getting updated and not many people are testing on this card the problems keep piling, I suggest trying some older kernels to see if any of them work for you. But as you have said, there are not many users of this hardware around, specially people working with GPU Passthrough. But this is a kernel problem and arch kernel and dkms are not exactly easy to bisect and report as regressions upstream, but if you have the time and know-how to report it, I would be glad to go back to VM's.

@benjarobin, I believe the nvidia enabled some support for it: https://nvidia.custhelp.com/app/answers/detail/a_id/5173/~/geforce-gpu-passthrough-for-windows-virtual-machine-%28beta%29

@caiotbc Just for information, GPU passthrough is (was?) blocked by Nvidia on Windows. It is only allowed with Quadro cards. So maybe this is the reason...

@Sinyria and @SoftExpert sorry for replying late, just got around to trying it again. So, it seems the culprit is something to do with OVMF GPU Passthrough after all. Yesterday when I tried installing it on the bare metal arch install and it failed I incorrectly assumed it was the same error I had described on the comments below, however investigating further revealed it was some sort of conflict with the VFIO drivers loading before the nvidia ones. After messing around in mkinipcio.conf I have now successfully installed the nvidia-470xx-dkms on bare metal, it is running fine. It still refuses to install inside the arch virtual machine, I guess maybe I should seek help on the various GPU passthrough forums, or maybe just give up getting this old GPU to work on this rather specific configuration. I tried both of your suggestions inside the VM but it did not change the errors.

In any case, thank you all for your help, I would appreciate if you guys had further suggestions but I understand that it is almost 100% certainly not a fault of this package and the error has something to do with the virtual machine setup, sorry for the confusion!