The screen flickers right after login
You boot into Fedora and the login screen looks fine. You enter your password, the GNOME shell loads, and the entire desktop begins to strobe. The flickering might be a subtle vertical tear that scrolls with the mouse, or a harsh full-screen refresh that makes reading text impossible. The system remains responsive, but the visual feedback is broken. This usually happens after a kernel update, a driver change, or a fresh install on newer hardware. The display stack is fighting itself, and you need to tell it which component gets the final say.
What is actually happening
The flicker is a synchronization failure between the kernel graphics stack and the display server. Modern Linux graphics rely on Kernel Mode Setting (KMS). The kernel takes control of the display hardware early in the boot process, sets the resolution, and hands the framebuffer to the display server. When the kernel driver and the user-space driver disagree on how to handle page flipping or vertical synchronization, the screen refreshes out of order. You see the tear or the flicker.
Page flipping is the mechanism that swaps the back buffer with the front buffer at the exact moment the monitor finishes drawing a frame. This moment is called vblank. If the display server pushes a new frame outside the vblank window, the monitor catches the buffer mid-swap. The top half of the screen shows the old frame, and the bottom half shows the new frame. That is a tear. If the driver tries to force synchronization but the kernel rejects it, the compositor drops frames. That is a flicker.
Fedora ships with open-source drivers that use the modesetting driver by default. This driver relies entirely on KMS and works well for most Intel and AMD GPUs. NVIDIA users often install the proprietary nvidia driver, which manages its own page flipping. When the display server tries to enforce TearFree rendering on a driver that already handles synchronization, the two mechanisms fight. The result is a stuttering or flickering desktop.
Wayland handles this differently than X11. Wayland compositors like Mutter draw every frame in a single buffer and present it to the screen. X11 allows applications to draw directly to the screen, which requires explicit tearing prevention. The fix depends on which display server you are running and which GPU you have.
Force the modesetting driver with Xorg
If you are on X11 or need to force a specific driver behavior, you configure Xorg through drop-in files. Never edit the files inside /usr/lib/X11/xorg.conf.d. Those belong to the packages and get overwritten on upgrade. Create your overrides in /etc/X11/xorg.conf.d. The system reads /etc first, so your settings take precedence. The numeric prefix in the filename determines load order. Lower numbers load first.
Here is how to force the modesetting driver and disable the conflicting TearFree option.
sudo mkdir -p /etc/X11/xorg.conf.d
# Create the directory if it does not exist. Xorg reads all .conf files here.
sudo tee /etc/X11/xorg.conf.d/20-modesetting.conf > /dev/null <<EOF
Section "Device"
Identifier "modesetting"
Driver "modesetting"
# Force the kernel modesetting driver instead of the legacy vendor driver.
Option "TearFree" "false"
# Disable Xorg-level tearing prevention to let the kernel handle page flipping.
EndSection
EOF
# Write the configuration file. The heredoc ensures exact formatting.
sudo reboot
# Restart the system so Xorg picks up the new drop-in configuration.
Reboot before you debug. Half the time the symptom is gone.
Adjust Wayland compositor settings
If you are on Wayland, Xorg configuration files do not apply. Wayland ignores /etc/X11/. The flicker usually comes from the compositor struggling with hardware acceleration or a mismatched GPU profile. Switching to the X11 session is the fastest way to isolate the issue.
Log out completely. Click the gear icon in the bottom right corner of the GNOME login screen. Select "GNOME on Xorg" instead of the default "GNOME". Log back in. If the flickering stops, the issue is specific to the Wayland compositor or your GPU's Wayland support. If it persists, the problem lives in the kernel driver or the Xorg configuration.
You can also force hardware acceleration settings through environment variables. Mutter respects GALLIUM_DRIVER and MESA_VK_WSI_PRESENT_MODE. Setting the presentation mode to fifo forces vertical synchronization at the driver level.
echo 'export MESA_VK_WSI_PRESENT_MODE=fifo' >> ~/.bashrc
# Force Mesa to use vblank synchronization for Wayland surfaces.
echo 'export WLR_RENDERER=vulkan' >> ~/.bashrc
# Prefer Vulkan rendering over OpenGL for Wayland compositors.
source ~/.bashrc
# Apply the variables to the current shell session.
Log out and back in for the compositor to read the new environment. Check the display behavior before moving to kernel parameters.
Verify the display stack
Confirm which display server is active and which driver the kernel is using. The loginctl command shows the current session type. The glxinfo utility reveals the exact rendering backend. The DRM subsystem logs initialization details that explain why a driver fell back to software rendering.
loginctl show-session $(loginctl | grep $(whoami) | awk '{print $1}') -p Type
# Query the display server type for your active session.
glxinfo | grep "OpenGL renderer"
# Identify the exact GPU and driver stack handling 3D acceleration.
journalctl -xeu gdm
# Check the display manager logs for driver initialization failures.
If glxinfo reports llvmpipe or swrast, the system is falling back to software rendering. Software rendering on a modern desktop causes severe flickering and high CPU usage. The open-source driver failed to load, or the proprietary driver is missing firmware. Install the missing firmware package and reboot.
Run journalctl -xe first. Read the actual error before guessing.
Common pitfalls and error patterns
A syntax error in the Xorg drop-in file breaks the display server entirely. Xorg is strict about indentation and quote placement. If the screen goes black after reboot, you will drop to a TTY. Press Ctrl+Alt+F3 to access a terminal. Fix the file immediately.
sudo nano /etc/X11/xorg.conf.d/20-modesetting.conf
# Open the configuration file in the terminal editor.
sudo rm /etc/X11/xorg.conf.d/20-modesetting.conf
# Remove the file if you cannot fix the syntax quickly.
sudo systemctl restart gdm
# Restart the display manager to return to the login screen.
Another common trap is mixing driver options. Setting Option "TearFree" "true" on an NVIDIA proprietary driver causes immediate flickering. The NVIDIA driver manages tearing internally. Xorg's TearFree option tries to override it, creating a double-buffer conflict. Leave TearFree unset or set to false when using the nvidia driver.
Secure boot also blocks unsigned kernel modules. If you installed the proprietary NVIDIA driver and enabled secure boot, the kernel refuses to load the nvidia module. The system falls back to nouveau or modesetting, which often triggers flickering on newer GPUs. Enroll your MOK keys or disable secure boot in the firmware settings.
Fedora's release cadence is six months. The N-2 release goes end-of-life when N+1 ships. Kernel updates happen weekly. A flickering issue that appeared after dnf upgrade --refresh usually means the new kernel changed the KMS initialization sequence. Check the kernel changelog or the Fedora bug tracker before rewriting your entire graphics stack.
Trust the package manager. Manual file edits drift, snapshots stay.
Choose the right display path
Use the modesetting driver when you have Intel or AMD hardware and want a stable, kernel-driven display stack. Use the proprietary nvidia driver when you need CUDA support or older GPU compatibility. Use Wayland when you want modern security isolation and smoother touchpad gestures. Use X11 when you rely on legacy window managers, screen recording tools, or remote desktop protocols that break under Wayland. Stay on the default GNOME session if you only deviate from the defaults occasionally.