Story opener
You switch to Fedora for a clean desktop, but the late-night coding session leaves your eyes strained. You look for a Night Light toggle and find nothing. Or worse, you follow an outdated guide, install a third-party daemon, and your screen starts flickering between warm and cool tones. The confusion usually comes from mixing GNOME's built-in color management with legacy temperature shifters. Fedora ships with everything you need. You just need to know where the controls live and how to wire them to your workflow.
What's actually happening
Display color adjustment runs on two separate pipelines. The first pipeline shifts the gamma curve in real time. It tells the compositor or X server to reduce blue light output by remapping pixel values before they hit the screen. The second pipeline applies ICC color profiles. It uses hardware calibration data to correct white balance, contrast, and color accuracy at the driver level. GNOME uses the first pipeline for Night Light and the second pipeline for the built-in Color settings. Both pipelines rely on the colord daemon to cache profiles and communicate with the display server.
When you install an older recommendation like redshift, you introduce a second process that fights the desktop environment for control of the same output. The race condition manifests as screen flickering, ignored temperature sliders, or tray icons that report the wrong state. The fix is to pick one pipeline and stick to it. Native integration avoids compositor conflicts and respects Wayland security boundaries. Third-party tools require manual service management and explicit conflict resolution.
Run journalctl -xeu gnome-settings-daemon.service before you guess. The logs will show whether the desktop environment is already applying a gamma filter.
The native GNOME path
Start with the built-in tool. Open Settings, navigate to Displays, and find the Night Light section. You can set a fixed schedule, adjust the color temperature slider, or enable location-based sunset tracking. The GUI writes directly to the gsettings database. If you prefer the terminal, the same keys are available without opening a single window.
Here's how to enable and configure the native Night Light feature directly from the command line.
gsettings set org.gnome.settings-daemon.plugins.color night-light-enabled true # Activates the gamma adjustment pipeline
gsettings set org.gnome.settings-daemon.plugins.color night-light-schedule-automatic false # Disables location tracking so you can set fixed hours
gsettings set org.gnome.settings-daemon.plugins.color night-light-schedule-from 22.0 # Sets the start time in 24-hour format
gsettings set org.gnome.settings-daemon.plugins.color night-light-schedule-to 7.0 # Sets the end time for the warm filter
gsettings set org.gnome.settings-daemon.plugins.color night-light-temperature 3400 # Lowers the color temperature to reduce blue light
The desktop environment applies changes immediately. You do not need to restart the session or log out. The gnome-settings-daemon process reads the DConf database and pushes the new gamma curve to the compositor. Wayland compositors like Mutter handle this internally. X11 sessions route it through xrandr. The result is identical.
Here's how to confirm the daemon is applying the correct temperature and schedule.
gsettings get org.gnome.settings-daemon.plugins.color night-light-enabled # Returns true if the filter is active
gsettings get org.gnome.settings-daemon.plugins.color night-light-temperature # Shows the current Kelvin value
gsettings get org.gnome.settings-daemon.plugins.color night-light-schedule-from # Verifies the start time matches your configuration
Trust the desktop environment. Native integration avoids race conditions and respects compositor limits.
The redshift alternative
Some users prefer redshift because it supports manual temperature overrides, geographic precision, and a persistent tray icon. If you choose this route, you must disable the GNOME Night Light first. Running both daemons will cause the screen to pulse between states. The conflict happens because both processes write to the same gamma registers.
Here's how to install the daemon and generate a configuration file that matches your timezone.
sudo dnf install redshift-gtk # Installs the GTK tray version with systemd integration
redshift-gtk -l 40.7128:-74.0060 -t 5500:3400 # Runs a test with New York coordinates and custom temperature range
If the test feels right, save the settings permanently. Create the configuration directory and write the file. User configuration belongs in ~/.config/. Never place daemon configs in /etc/ unless you are managing a fleet of machines.
Here's the configuration file that tells the daemon how to behave on every boot.
[redshift]
temp-day=5500 # Sets the daytime color temperature in Kelvin
temp-night=3400 # Sets the nighttime color temperature
transition=1 # Smoothly shifts between temperatures over one minute
location-provider=manual # Bypasses geoclue to avoid permission prompts
[manual]
lat=40.7128 # Hardcodes your latitude
lon=-74.0060 # Hardcodes your longitude
Enable the systemd user service so it starts automatically. User services run under your login session and do not require root privileges.
Here's how to register the daemon with your user session.
systemctl --user enable redshift-gtk.service # Adds the service to your user's default target
systemctl --user start redshift-gtk.service # Launches the daemon immediately
Here's how to confirm the user service is running and not masked by the desktop environment.
systemctl --user status redshift-gtk.service # Shows active state and recent log lines
journalctl --user -u redshift-gtk.service -n 10 # Prints the last ten log entries for quick verification
Disable the GNOME toggle before starting redshift. Two temperature filters on one output will fight each other.
Hardware calibration and colord
Gamma shifting reduces blue light. It does not correct monitor manufacturing variances or aging backlight panels. If you edit photos, design interfaces, or need consistent color across multiple displays, you need ICC profiles. Fedora ships with colord, a system daemon that manages color profiles for monitors, printers, and cameras.
Here's how to check which profiles are currently loaded for your active display.
colormgr get-devices # Lists all color-managed devices recognized by the system
colormgr get-profiles --device <device-id> # Shows attached ICC profiles for a specific monitor
You can add custom profiles through Settings > Color, or drop .icc files into ~/.local/share/color/icc/. The daemon reloads automatically. Package-managed profiles live in /usr/lib/colord/profiles/. User overrides belong in ~/.local/share/ or /etc/colord/. Edit /etc/ only when you need system-wide enforcement.
Here's how to force the daemon to rescan for new profile files.
systemctl --user restart colord.service # Reloads the user-level color database
colormgr get-devices # Confirms the new profile appears in the device list
Run colormgr before you guess. The daemon caches profile metadata, so a restart is required after dropping new files.
Common pitfalls and error signatures
The most common issue is a conflict between gnome-settings-daemon and redshift. You will see the screen flicker, or the tray icon will show the wrong temperature. If you try to run redshift without a location provider, it prints Error: No location provider configured. to the terminal. Fix it by adding the [manual] block or installing geoclue2.
Another pitfall involves Wayland compositors. GNOME on Wayland restricts direct X11 gamma control. The native Night Light works because it uses the compositor's internal color pipeline. Third-party tools that rely on xrandr or direct /dev/dri access may fail silently or throw X Error of failed request: BadMatch. If you are on Wayland and need hardware-level color profiles, use colord instead of gamma shifters.
SELinux denials occasionally block custom daemon startup. You will see Permission denied in the journal. Check journalctl -t setroubleshoot for a one-line summary. The summary usually points to a missing file context or an untrusted executable. Restore the default context with restorecon -v ~/.config/redshift.conf before restarting the service.
Convention aside: firewall-cmd --reload after every rule change. Otherwise the runtime config and the persistent config diverge. The same principle applies to color daemons. Restart the service after every config edit. Otherwise the daemon reads stale data.
Check the journal before you force a restart. Half the time the symptom is a missing dependency or a locked DConf database.
Decision matrix
Use GNOME Night Light when you want zero configuration and seamless Wayland integration. Use redshift when you need manual temperature overrides, geographic precision, or a tray icon for quick toggling. Use colord with ICC profiles when you require hardware-accurate color reproduction for photo editing or design work. Stay on the native desktop settings if you only need basic blue light reduction.
Pick one color pipeline and stick to it. Mixing gamma shifters and compositor filters breaks more often than it helps.