EDID (Extended Display Identification Data) is a technology that allows
a monitor to provide information about itself to a computer. The
operating system reads this information to find out what resolutions,
refresh rates, and so on the monitor supports so it can automatically
configure the display output.
This is a good idea when it works, but if the OS cannot read the EDID
information from the monitor for whatever reason, your spanking new high-end
monitor will be limited to a low resolution display of limited use.
I encountered this situation where the EDID information was missing. Here is
what I did to resolve the issue in Linux Mint 15 using Radeon graphics.
Update: If the monitor still gives trouble when using modelines generated by cvt or gtf, try using read-edid as described in this article.
The Problem
I had the chance to use a quality 1920×1080 LCD display, which had three
video connections: VGA, HDMI, and DVI. Linux Mint 15 detected and configured
the monitor properly when connected to the VGA or HDMI connectors, but not
with the DVI.
After much trial and error, it was determined that EDID information was not
being supplied when conencted to the monitor’s DVI port. This happened with Ubuntu, Xubuntu, Linux Mint, Windows XP, and Windows 7. The results were consistent, and all of the operating systems detected the DVI connection as a “Generic Display” limited to 640×480, 800×600, or 1024×768 resolutions.
The Solution
Since Linux (Windows too, but I am resolving this using Linux Mint 15) could
not find the EDID information, the solution was to force the resolution. In the
end, I modified the /etc/X11/xorg.conf file with a custom Monitor section that
provided a Modeline of 1920×1080. The end result looked something like this:
Section "Monitor" Identifier "DVI-0" DisplaySize 1920 1080 Option "DPMS" "true" Modeline "1920x1080_60.00" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync EndSection
Xorg reads this Modeline upon X initialization and says, “Okay, the DVI port
supports this resolution. Let’s use it.”
That’s it. Upon restarting X, the problematic monitor automatically switched to
full screen 1920×1080 at 60Hz. Even the login GDM screen displayed at the
proper resolution.
Why
This is just a guess, but if X cannot determine what resolutions are
supported by the monitor, it limits them to the lowest possible values to avoid
potentially damaging the monitor even if they are resolutions that the monitor
supports.
The Adventure
Fixing xorg.conf as shown above might seem like a simple solution, and it is, but it required a great amount of effort, research, studying, and trial and error. I found three workable solutions, but the xorg.conf modification worked best for my purposes.
“Is the cable good?”
The first thing I checked was the DVI cable. Several different cables were
tested and they all produced the same result. I even tried using DVI-VGA and
DVI-HDMI adapters to try connecting VGA and HDMI ports on the computer to the
DVI port on the monitor. Same non-EDID result.
“Is the DVI graphics card port okay?”
The problematic monitor was tested with different graphics cards, computers,
and operating systems. When connected to the VGA and HDMI ports on the monitor, the monitor displayed in all of its native glory as intended. But when
connected to its DVI port, the monitor was always detected as a generic display
device limited to 1024×768.
“Is it an operating system issue?”
After reformatting with Ubuntu, Xubuntu, Linux Mint, Windows XP, and Windows 7
using different computers multiple times, the tested OS always read the monitor
as “Unknown” and limited its resolution when connected using the DVI port of
the monitor.
“Does the same problem occur with another identical monitor?”
I had the opportunity to test an exact, identical monitor, and its DVI port
functioned properly. The computer always registered the testing monitor through its DVI port and automatically set the resolution, but the problematic monitor
continued to default to “Unknown” with its DVI port.
With the hardware verified and the problem isolated, it was clear that this
was a fault of the monitor. This was not a Linux/Windows/software issue.
“What next?”
The only real way to fix this issue would be to send the monitor back to the
manufacturer for repairs. (Checking the monitor’s support page was absolutely
no help, so that did not inspire confidence in the manufacturer.) Besides, I
needed the monitor now.
“What about a workaround?”
The monitor supports all resolutions and displays them great. The problem
is that the computer does not know about them due to a missing EDID. Would it
be possible to force the resolution from within the operating system?
Forcing the Resolution
This is the most direct approach, and it uses three programs: xrandr, cvt, and
gtf.
xrandr is a command-line program that adds and sets new resolutions for a
monitor. However, it does not save its settings, so a startup script is
required. xrandr worked quite well, in fact, but I mostly used it to test mode
settings before making them permanent in xorg.conf.
Here is how it goes:
First, create a modeline for the intended resolution. For 1920×1080 at 60
Hz, run cvt or gtf to get a full modeline for that mode.
cvt 1920 1080 60
or
gtf 1920 1080 60
A modeline will be returned.
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
The Modeline is what xrandr uses to create a monitor mode. The
“1920x1080_60.00” is the name of the mode, which you are free to change to
anything you like. You access this mode by using its name.
Note: cvt and gtf results are slightly different. Take a look at the results
below for the same 1920×1080@60Hz.
cvt:
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
gtf:
Modeline "1920x1080_60.00" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync
Either might work despite the differences depending upon your system. In my
case, neither worked. Both produced fuzzy blurring at 1920×1080.
Next, add the mode so the system knows about it.
xrandr --newmode <full modeline goes here>
Example:
xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
Now, add the mode to the problematic port. This, too, has a name. Run xrandr by
itself to see a list of connected display ports. For this system, the problematic monitor was connected to DVI-0, so this is the name of the port we will add the new mode to.
xrandr --addmode DVI-0 1920x1080_60.00
Be sure to use the name of the mode (1920x1080_60.00 in this case). Do not use
the modeline again.
As the last step, we need to activate the DVI port.
xrandr --output DVI-0 --mode 1920x1080_60.00
Again, use the name of the display mode.
The monitor switches to the new resolution, and, if it is supported, the monitor
will stay at that resolution. For me, it was correct, but all graphics were
blurry. This was due to an incorrect Modeline from cvt and gtf.
Finding the Proper Modeline
X records its activity in /var/log/Xorg.0.log. When X reads the EDID data, it
logs all supported resolutions here for later viewing.
I connected the computer to a working port (HDMI) so X would grab all modelines
and log them in this file upon restarting X. These are known, good modelines provided by the monitor itself. They are not generated artificially by cvt or gtf, so if I use one of these, then I should have the proper modeline, right?
I opened the log file, copied the needed modeline, and used the new modeline with xrandr again in the steps above after reconnecting the monitor through its DVI port and restarting X.
Success! xrandr properly set the monitor to the correct resolution without any
blurring. The values in the new modeline from /var/log/Xorg.0.log were
different from those produced by cvt and gtf, and they made a difference.
Making the Changes Permanent
So far so good, but the changes are not persistent. The obvious solution is to
use a script to initialize the xrandr process. But how about xorg.conf? After
all, that is the configuration file X uses.
Information about X.Org is not something usually available at the
top of every “Introduction to Linux” tutorial, so you must dig to find answers. Due to the lack of readily available information (compared to the ease of information regarding programming languages, for example), X seems like a deep, mysterious topic delving into the arcane underworkings of the Linux video subsystem.
Actually, X is not that hard to grasp, but it requires much effort to learn and
many, many, many X restarts to figure things out.
After researching the relevant parameters at the X.Org site and pouring over the
X log files, it was apparent that xorg.conf needed a monitor section
containing the working Modeline for the problematic monitor. The identifier was
given the same name (DVI-0) as the problematic DVI port. That’s it. After
saving and rebooting, the monitor displayed the full 1920×1080 at 60 Hz.
Problem solved!
Three Solutions
During the course of fixing this problem, three solutions worked.
1. Modify xorg.conf
This is the solution I settled upon because it worked best for my situation.
- Add a monitor section contianing a Modeline obtained from /var/log/Xorg.0.log.
The other main reason for using this solution is that the Linux kernel can be
upgraded without crashing Cinnamon (discussed below). I was able to upgrade Linux Mint 15 to kernel 3.10.9 without crashing Cinnamon or resorting to fallback mode in MATE or Xubuntu. This is working with a Radeon-based graphics system, not an nvidia system.
2. xrandr script
Place all xrandr lines in a startup script. It works, but the display flashes
during loading. Ugly. Quickly abandoned since the xorg.conf modification is less hassle.
3. Custom EDID from file
It is possible to grab the EDID data from the monitor and save it to a file
/etc/X11/edid.bin. If you have an nvidia card installed, you can use the nvidia-settings dialog to grab the EDID data.
With an nvidia card installed with its nvidia drivers, I then added the line,
Option "CustomEDID" "DVI-0:/etc/X11/edid.bin"
to the Device section for the nvidia driver in xorg.conf.
Section "Device"
Driver "nvidia"
Option "CustomEDID" "DVI-0:/etc/X11/edid.bin"
EndSection
Xorg loaded the EDID information from the file and used it to automatically
configure the monitor. The EDID data was obtained from the same monitor when
connected to its HDMI port, so it had to work since it was the EDID for that
specific monitor. The nvidia display configuration properly saw the monitor
through the DVI port. Problem solved…almost.
This lead to an even worse problem.
Using the CustomEDID in Linux Mint 15, Cinnamon would always crash when updating the kernel, installing a gdm, or doing almost nothing. Cinnamon became very touchy, and when it crashed, it was usually permanent.
Linux Mint 15 seemed to to run fine with its default 3.8.0 kernel, but when
upgraded to kernel 3.10.9, Cinnamon crashed into fallback mode, and there was
no way to restore it–even after uninstalling the newer kernel.
And this was not limited to Linux Mint 15. Xubuntu 13.04 and Linux Mint 15 MATE
all started in software mode whenever a new kernel was installed. However, this might be an issue with the nvidia drivers since this phenomenon only happened when the nvidia card was used. Using the Radeon graphics never produced a Cinnamon crash.
Conclusion
When it come to Linux video problems, there is no “one size fits all” solution.
It seems as if every system is different and requires its own approach. I
researched and tried all possible advice I could find, but what worked for one
person never worked for me. However, several tidbits helped point me in the
right deduction direction.
In the end, when it comes to situations like this, it boils down to independent
research, logical thinking, log file analysis, and much trial and error with
both hardware and software. This process appears most prevalent with Linux
systems, so it is no wonder that Linux users remain among the most technically
knowledgeable computer users around!
Hopefully, the information provided here might give ideas to those afflicted
with similar video issues in Linux involving a missing EDID.
Delightly Linux 