There is a specific kind of hell reserved for techies: Having a perfectly capable 1920×1080 monitor stuck in a blurry 1024×768 fallback mode. For the last few months, my main PC was essentially a paperweight. I saw three separate NVIDIA driver updates roll out, hoping each would fix the “handshake” issue. None did.
If you are running Ubuntu with Wayland on an NVIDIA GeForce GTX 960 (Maxwell generation), and your monitor is being detected as “Unknown,” this is how I finally reclaimed my desktop.
The Culprit: Maxwell, New Kernels, and Faulty Firmware
The root of the issue was a perfect storm: an NVIDIA GTX 960 (Maxwell architecture) paired with a newer Linux kernel and faulty firmware. This combination caused a complete breakdown in the EDID (Extended Display Identification Data) handshake.
The system logs (dmesg), treated me with this fun error:nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device HDMI-0
Because the firmware couldn’t read the monitor’s identity, the system played it safe and dropped me into a 1024×768 “safe mode” instead of the native 1080p.
What I Tried (and Why I Skipped X11)
I didn’t want a “band-aid” fix. I explicitly avoided any X11-only solutions like xrandr because I wanted to stay future-compatible with Wayland. Here is what failed:
- The Nouveau Driver: I tried switching to the open-source Nouveau drivers multiple times. It was a total failure—the system wouldn’t boot to a GUI at all.
- Waiting for Official Fixes: I waited months through three driver updates. It became clear that the software wasn’t going to fix a firmware-level communication error between the GTX 960 and the kernel.
- Manual
monitors.xmlEdits: I tried “force-feeding” GNOME the correct resolution via the config file, but since the kernel didn’t believe the hardware supported 1080p, Wayland ignored the file entirely.
The Lifesaver: SSH to the Rescue
Experimental display tweaking is dangerous. Several of my attempts resulted in a black screen—no cursor, no terminal, no hope.
Luckily, I was running an SSH server on the machine. This allowed me to remote in from my laptop, revert my broken changes changes, and get a working (albeit low-res) screen back without having to take more drastic measures.
The Solution: The “Fake” EDID Injection
Since the hardware couldn’t talk to each other, I decided to “hallucinate” a working monitor for the system. We can provide a generic 1080p profile and tell the kernel to use it as if it came from the monitor itself.
1. Create the Fake Identity
I used a generic 1080p EDID binary that describes a perfect display.
sudo mkdir -p /lib/firmware/edid
sudo wget [https://github.com/akatrevorjay/edid-generator/raw/master/1920x1080.bin](https://github.com/akatrevorjay/edid-generator/raw/master/1920x1080.bin) -O /lib/firmware/edid/1920x1080.bin2. Configure GRUB (The Kernel Level)
This is where we bypass the driver’s confusion. Note that while NVIDIA calls the port HDMI-0 (in the error log above), the Kernel (DRM) calls it HDMI-A-1. You must use the Kernel name.
- Open the config:
sudo vim /etc/default/grub - Update the boot line to force modeset and point to our “fake” firmware:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=1 drm.edid_firmware=HDMI-A-1:edid/1920x1080.bin video=HDMI-A-1:1920x1080@60e"
3. Commit and Reboot
You must bake the EDID into the initial RAM disk so the driver sees it immediately upon boot.
sudo update-grub
sudo update-initramfs -u
sudo rebootThe Result
After months of waiting for a firmware update that never came, my GTX 960 finally booted into a crisp, native 1920×1080 on Wayland. By taking control of the EDID handshake ourselves, we bypassed the Maxwell/Kernel bug entirely.