Linux Graphics Driver Troubleshooting is much easier when you first identify where the display problem begins instead of immediately reinstalling drivers. A black screen, wrong resolution, missing external monitor, or poor GPU performance can come from very different parts of the Linux graphics stack.
The issue may involve the kernel driver, firmware, Mesa, a proprietary NVIDIA driver, Wayland or Xorg, the desktop compositor, or even the display connection itself. Because NVIDIA, AMD, and Intel hardware behave differently, the safest approach is to identify the GPU and active driver before changing anything.
This guide walks through the most useful checks for black screens, GPU driver failures, resolution problems, external displays, hardware acceleration, and graphics issues that appear after kernel or system updates.
Before changing drivers: record your GPU model, current kernel, current driver, and whether the session uses Wayland or Xorg. Do not install an NVIDIA, AMD, or Intel driver package simply because another machine had a similar symptom.
Quick Diagnosis: Start With What You Can See
| Symptom | Check first |
|---|---|
| Black screen after selecting Linux in GRUB | Kernel/graphics driver, older kernel |
| Desktop boots at low resolution | Driver loading, display detection |
| External monitor missing | Connector detection, session, dock/cable |
| NVIDIA driver not loading | Kernel module, Secure Boot, package state |
| AMD/Intel performance unexpectedly poor | Kernel driver, Mesa, Vulkan/OpenGL renderer |
| Screen tearing or compositor issues | Wayland/Xorg, compositor, driver |
| Game uses software rendering | OpenGL/Vulkan renderer |
| Problem began after kernel update | Driver/kernel compatibility |
| Wayland session fails but Xorg works | Driver/compositor/session compatibility |
| Laptop uses the wrong GPU | Hybrid graphics configuration |
Do not reinstall the bootloader for a black screen that occurs after the kernel has already started. At that point, graphics or userspace is a more likely place to investigate.
1. Identify the GPU and Kernel Driver
Start with:
lspci -k | grep -A3 -E 'VGA|3D|Display'This normally shows:
- the graphics device;
- possible kernel modules;
- the kernel driver in use.
You may see drivers such as:
amdgpui915xenouveaunvidia
Now check the kernel version:
uname -rIf the problem began immediately after a kernel update, note that version before changing anything.
On laptops with hybrid graphics, lspci may show more than one GPU. That is normal.
Start here
Recommended guides
What Happens When You Press the Power Button on a Linux PC
A behind-the-scenes look at every stage between pressing the power button and reaching your Linux desktop or login prompt.
What Happens During the Linux Boot Process (2026 Guide)
A clear, stage-by-stage breakdown of what happens during the Linux boot process — from POST to login.
Lightweight Linux Distros That Run Smoothly on 4GB RAM (2026 Guide)
Still fast, still maintained — 11 lightweight Linux distros that run smoothly on 4GB RAM in 2026.
2. Check Whether You Are Using Wayland or Xorg
Run:
echo $XDG_SESSION_TYPEThe result is commonly:
waylandor:
x11This matters because a graphics problem can exist in one session type but not the other.
If your login manager offers both, testing the alternative session once can provide useful evidence.
For example:
- Wayland fails but Xorg works → investigate the driver/compositor/Wayland path.
- Both fail → the problem may be lower in the graphics stack.
- Both work but one application fails → focus on that application or API.
Do not treat switching permanently to Xorg or Wayland as the only fix. Use the comparison to narrow the problem first.
3. Check the Actual OpenGL and Vulkan Renderer
A desktop can look normal while applications fall back to software rendering.
If glxinfo is installed:
glxinfo -BLook for the OpenGL renderer.
If you see a software renderer such as llvmpipe when you expected the GPU, hardware acceleration is not working as intended.
For Vulkan, if vulkaninfo is installed:
vulkaninfo --summaryThe exact packages providing these tools differ by distribution.
Do not install random graphics packages merely to obtain the commands. Use your distribution’s package manager and documentation.
4. Check Kernel Messages for Graphics Errors
Kernel logs can show whether the GPU driver initialized properly.
Try:
dmesg | grep -iE 'drm|gpu|nvidia|amdgpu|i915|xe|nouveau|firmware'Depending on your distribution, access to all kernel messages may require elevated privileges.
Look for repeated errors involving:
- firmware;
- module loading;
- GPU resets;
- display connectors;
- failed initialization;
- driver crashes.
A single old warning may be harmless. Repeated errors that match the time of the black screen or display failure are more useful.
5. Black Screen After a Kernel or Driver Update
If GRUB appears normally and the screen goes black after selecting Linux, try a previously working kernel from GRUB’s advanced menu if one is available.
If the older kernel boots:
- record the working kernel;
- identify the graphics driver;
- check the failed boot’s logs;
- check your distribution for an updated kernel or driver package.
This is especially important for proprietary modules that must match the running kernel.
Do not delete the working older kernel until the issue is resolved.
6. NVIDIA Driver Is Installed but Not Loading
For NVIDIA systems, first check whether the proprietary module is loaded:
lsmod | grep nvidiaYou can also check:
nvidia-smiwhen the proprietary NVIDIA driver and utility are installed.
If nvidia-smi cannot communicate with the driver, investigate:
- whether the kernel module built for the current kernel;
- package installation state;
- Secure Boot/module signing;
- whether another driver is bound to the device;
- driver/kernel compatibility.
Check:
lspci -k | grep -A3 -E 'VGA|3D|Display'to see the driver actually in use.
Secure Boot
Where available:
mokutil --sb-stateSecure Boot does not automatically make NVIDIA unusable, but unsigned third-party kernel modules can fail to load.
Use your distribution’s supported NVIDIA installation method instead of NVIDIA’s generic .run installer unless you have a specific reason and understand the maintenance consequences.
7. AMD Graphics Problems
Most modern AMD GPUs use the in-kernel amdgpu driver along with Mesa user-space components.
Check:
lspci -k | grep -A3 -E 'VGA|3D|Display'and confirm amdgpu is in use where expected.
If the desktop works but games or accelerated applications fail, check the OpenGL/Vulkan renderer rather than assuming the kernel driver is missing.
Firmware can also matter. Kernel messages may show missing firmware files.
Use distribution-provided kernel, Mesa, Vulkan, and firmware packages unless you have a well-defined reason to use another stack.
8. Intel Graphics Problems
Intel integrated graphics normally use in-kernel drivers with Mesa user-space components.
Identify the active driver:
lspci -k | grep -A3 -E 'VGA|3D|Display'Modern Intel generations may use different kernel driver paths depending on hardware and distribution/kernel version.
If hardware acceleration is questionable, check:
glxinfo -Band, where applicable:
vulkaninfo --summaryAvoid forcing kernel parameters intended for another Intel generation without checking current kernel and distribution guidance.
9. External Monitor Is Not Detected
Start with the physical path:
- cable;
- adapter;
- dock;
- monitor input selection;
- another port if available.
Then see what the desktop detects.
On Xorg systems, xrandr can be useful:
xrandrWayland compositors may use desktop-specific display tools instead.
If the monitor works when connected directly but not through a dock, focus on the dock, USB-C/Thunderbolt path, DisplayPort MST, or driver support.
If the monitor appears in settings but remains blank, check resolution, refresh rate, and whether the selected mode is supported by the display/cable combination.
10. Wrong Resolution or Refresh Rate
If Linux boots at an unexpectedly low resolution, first confirm that the correct graphics driver loaded.
Then check the display modes offered by your desktop.
On Xorg:
xrandrcan list connected displays and available modes.
Do not immediately create custom modelines. If a previously supported monitor suddenly offers only low resolutions, investigate:
- driver loading;
- cable/adapter quality;
- EDID detection;
- dock behavior;
- kernel regression.
A custom mode should be a later step, not the first response.
11. Hybrid Graphics: Laptop Uses the Wrong GPU
Many laptops contain an integrated GPU and a discrete GPU.
That is not a fault.
The goal is usually to use the integrated GPU for normal desktop work and the discrete GPU when needed, although distributions and hardware differ.
Identify both devices:
lspci -k | grep -A3 -E 'VGA|3D|Display'Then use your distribution’s supported hybrid-graphics method.
Avoid installing multiple switching utilities from unrelated guides. Ubuntu, Fedora, Arch-based systems, NVIDIA PRIME, and vendor-specific laptops can use different approaches.
If battery life became much worse after a driver change, check whether the discrete GPU is being kept active unnecessarily.
12. Screen Tearing or Stutter
Tearing and stutter can come from:
- compositor behavior;
- Wayland/Xorg differences;
- driver problems;
- refresh-rate mismatch;
- variable refresh rate;
- application-specific rendering;
- multi-monitor setups with different refresh rates.
First determine whether it occurs:
- everywhere;
- only in video;
- only in games;
- only on one monitor;
- only under Xorg or Wayland.
That distinction tells you whether to investigate the compositor, display configuration, or application.
Avoid applying old Xorg tear-prevention options to a Wayland session.
13. GPU Problems After Suspend or Resume
If the screen fails only after waking from suspend, the graphics driver may not be restoring the GPU/display state correctly.
Check logs from the current boot:
journalctl -b | grep -iE 'drm|gpu|nvidia|amdgpu|i915|xe'Compare behavior with:
- external monitors disconnected;
- another kernel;
- another session type;
- updated firmware.
If the problem is reproducible after every suspend but a fresh boot is fine, that distinction is valuable when searching your distribution’s issue tracker.
14. Check Failed Display Services
If the machine reaches a text console but the graphical login does not appear, check the display manager.
Common examples include GDM, SDDM, and LightDM.
You can inspect the default display-manager service through:
systemctl status display-managerCheck failed services:
systemctl --failedAnd logs:
journalctl -bA display-manager failure is not necessarily a GPU driver failure, although the two can be related.
15. Try a Text Console When the Desktop Is Black
On many systems, you can switch to another virtual console with a key combination such as:
Ctrl+Alt+F3The exact usable function key can vary.
If a text login works while the graphical desktop is black, the kernel and system are much further through boot than a completely frozen machine.
From the console you can:
- inspect logs;
- check disk space;
- identify the driver;
- check failed services;
- temporarily undo a recent configuration change.
Do not use this as proof that the GPU itself is healthy, but it is a useful diagnostic boundary.
16. Check Disk Space Before Blaming the Driver
A full root or home filesystem can break desktop sessions.
Check:
df -hIf / or /home is full, free space and try logging in again before reinstalling graphics packages.
A login loop or broken desktop caused by zero free space can look surprisingly similar to a graphics problem.
17. Avoid Mixing Graphics Driver Sources
One of the easiest ways to create a fragile Linux graphics setup is mixing installation methods.
Examples:
- distribution packages;
- vendor
.runinstallers; - unofficial repositories;
- manually copied libraries;
- multiple Mesa stacks.
Whenever possible, use one supported packaging path.
Before changing an existing driver installation, understand how it was installed. Removing half of one method and installing another can leave conflicting libraries or kernel modules.
18. When a Live USB Helps
A current live Linux USB can help answer whether the graphics hardware works with a clean software environment.
If the live environment detects displays and renders normally while the installed system fails, investigate the installed:
- kernel;
- driver;
- Mesa stack;
- configuration;
- desktop session.
If both show the same hardware failure, broaden the investigation to compatibility, firmware, cables, docks, or hardware.
A Practical Linux Graphics Troubleshooting Order
Use this sequence:
- Identify the GPU with
lspci -k. - Record the kernel with
uname -r. - Check Wayland versus Xorg.
- Check OpenGL/Vulkan renderer if acceleration is in question.
- Read GPU-related kernel logs.
- Try an older kernel if the issue began after an update.
- Check Secure Boot/module state for proprietary NVIDIA drivers.
- Test external displays without docks/adapters where possible.
- Check disk space and display-manager state.
- Use a live USB when you need a clean comparison.
- Change drivers only after identifying the active driver and failure.
The best graphics fix is the one that matches your GPU, kernel, distribution, and session—not the one that happened to work on another laptop.
NVIDIA, AMD and Intel: Why the Troubleshooting Path Differs
NVIDIA users may be running the proprietary NVIDIA driver or the open-source Nouveau path, depending on hardware and distribution. Kernel module compatibility and Secure Boot can matter.
AMD graphics commonly use the in-kernel amdgpu driver with Mesa providing much of the user-space graphics stack.
Intel integrated graphics also rely heavily on in-kernel drivers and Mesa, with driver details evolving across hardware generations.
That is why “reinstall the GPU driver” is too vague to be useful advice on Linux.
Official References Worth Checking
Useful primary sources include:
- Linux kernel DRM documentation
- your Linux distribution’s graphics-driver documentation;
- NVIDIA’s Linux documentation where proprietary NVIDIA drivers are involved;
- Mesa documentation and your distribution’s Mesa packages;
- hardware vendor documentation for docks and display interfaces.
Linux graphics troubleshooting becomes much easier when you first identify the GPU and the driver that is actually running. From there, compare kernel, session, renderer, and logs before replacing anything.
