When the desktop falls back to a generic driver
You just installed Fedora on a machine with a modern AMD Radeon card. The desktop environment loads, but the resolution is stuck at a low default, window animations stutter, and the system reports a software renderer instead of your actual GPU. You run a quick hardware check and see the card listed, but the kernel is using a fallback framebuffer driver. You need the proper AMD graphics stack to restore hardware acceleration, correct display scaling, and smooth desktop performance.
How the AMD graphics stack actually works
Linux handles graphics through a layered architecture. The kernel module communicates directly with the silicon. The display server uses a userspace driver to translate drawing commands into instructions the kernel understands. Fedora ships with open-source drivers enabled by default, but the packages sometimes need explicit installation or rebuilding to match your running kernel.
The amdgpu kernel module handles display output, power management, and compute workloads. The xf86-video-amdgpu package provides the Xorg display driver. The akmod variant automatically rebuilds the kernel module when you update the kernel. This prevents the black screen that occurs when the module version drifts from the kernel version. Fedora's package manager handles the compilation in the background, but you still need to trigger the initial load and verify the stack is active.
Run the installation commands from a terminal. If you are currently on a broken graphical session, switch to a virtual console with Ctrl+Alt+F3 and log in before proceeding.
Install the driver packages
Here's how to pull the correct packages from the repository and trigger the kernel module build.
sudo dnf install akmod-amdgpu akmod-xf86-video-amdgpu xorg-x11-drv-amdgpu -y
# -y skips the interactive prompt so the transaction proceeds automatically
# akmod packages trigger a background kernel module compilation
# xorg-x11-drv-amdgpu provides the userspace display driver for Xorg
The akmod system uses dkms under the hood to compile modules against your exact kernel version. The compilation runs in the background and usually completes within a minute on modern hardware. You can watch the progress if you want to confirm the build is not stuck.
Here's how to monitor the kernel module compilation process.
journalctl -f -u akmods.service
# -f follows the log stream in real time
# -u filters output to the akmods service only
# Watch for the "Build complete" message before proceeding
Once the build finishes, the new module exists in /lib/modules/$(uname -r)/extra/. The system does not automatically load it until you trigger the load or reboot. Manual loading is faster than rebooting and lets you verify the module attaches correctly before committing to a restart.
Here's how to load the kernel module immediately.
sudo modprobe amdgpu
# modprobe reads module dependencies and inserts the .ko file into the running kernel
# This activates hardware acceleration without requiring a system reboot
If you are using Secure Boot, the akmod build will fail to sign the module automatically. You will need to enroll the MOK key or disable Secure Boot temporarily. The build log will print a clear warning if signature verification is blocking the load.
Reboot only after the module loads successfully. A cold boot clears any leftover framebuffer state that interferes with the new driver.
Verify the hardware is recognized
The installation is not complete until the display server and the kernel agree on the hardware. You need to confirm three things: the kernel module is loaded, the Xorg or Wayland compositor is using the correct driver, and OpenGL/Vulkan reports the actual GPU name.
Here's how to check whether the kernel module is active and bound to your card.
lspci -k | grep -A 3 -i vga
# -k shows the kernel driver in use
# grep filters for the VGA controller and prints three lines after the match
# Look for "Kernel driver in use: amdgpu" in the output
If the output shows Kernel driver in use: (none) or Kernel modules: radeon, the system is still falling back to legacy drivers. The radeon module only supports older GCN 1.0 and 1.1 architecture cards. Modern RDNA and GCN 2.0+ cards require amdgpu.
Here's how to confirm the userspace driver is reporting the correct renderer.
glxinfo | grep "OpenGL renderer"
# glxinfo queries the Mesa graphics stack for current capabilities
# grep isolates the renderer string so you can verify hardware acceleration
# Output should contain "AMD Radeon" followed by your exact GPU model
If glxinfo returns llvmpipe or softpipe, the userspace driver is not attached. This usually means the Xorg configuration is overriding the default driver selection. Check /etc/X11/xorg.conf.d/ for any custom .conf files that force a different driver. Remove or rename them, then restart the display manager.
Here's how to check the kernel log for initialization messages.
journalctl -k | grep amdgpu | tail -n 10
# -k filters to kernel ring buffer messages only
# grep isolates amdgpu-related log lines
# tail shows the last ten entries to catch the final initialization state
You should see lines indicating successful PCI enumeration, firmware loading, and display connector detection. If you see amdgpu: probe of ... failed with error -12, the system is out of memory during initialization. Increase your swap space or reduce the number of concurrent background services before retrying.
Run the verification commands before closing the terminal. A silent failure in the userspace layer will not show up in dmesg.
Common pitfalls and what the error looks like
The AMD stack is mature, but a few configuration traps still catch new Fedora users. The most common issue is a conflicting legacy module. The radeon driver will claim older cards and block amdgpu from loading. You need to blacklist the legacy module if it persists.
Here's how to blacklist the legacy driver permanently.
echo "blacklist radeon" | sudo tee /etc/modprobe.d/blacklist-radeon.conf
# tee writes the line to the modprobe configuration directory
# /etc/ holds user modifications while /usr/lib/ ships with packages
# modprobe reads this file on every boot and skips blacklisted modules
Another frequent problem is Secure Boot blocking unsigned akmod modules. The build process will complete, but modprobe will refuse to insert the module. The journal will print a clear denial.
modprobe: ERROR: could not insert 'amdgpu': Required key not available
This is not a driver bug. The kernel refuses to load modules that lack a valid signature matching your MOK database. You must either disable Secure Boot in the firmware settings or enroll the generated key using mokutil --import. Fedora's documentation covers the MOK enrollment flow in detail.
A third trap involves Wayland compositors falling back to Xorg when they detect an incomplete driver stack. If your session defaults to Xorg instead of Wayland, the compositor likely failed to initialize the DRM/KMS interface. Check the compositor logs for failed to open drm device or no available output. This usually means the kernel module did not load before the display manager started. Reboot after loading the module, or add amdgpu to /etc/modules-load.d/amdgpu.conf so it loads early in the boot sequence.
Check the journal before guessing at configuration changes. The exact error string tells you whether the problem is kernel-level, userspace, or firmware-related.
When to use this stack versus alternatives
Use the mainline amdgpu stack when you want stability, automatic updates, and full Fedora support. Use akmod-amdgpu when you run custom kernels, backport patches, or need immediate module rebuilding after kernel updates. Stick to the default in-tree kernel modules when you are on a standard Fedora install and do not modify kernel headers. Switch to radeon only when you are maintaining legacy GCN 1.0 hardware that predates the amdgpu driver. Stay on the upstream Mesa packages if you only deviate from the defaults occasionally.
Trust the package manager. Manual file edits drift, snapshots stay.