LCD/LED TV with RHEL 6 and Friends
Because of my pastoral heart, I want to save others the sorrow of having to repeat my labors needlessly.
In this case, we are running Scientific Linux 6 on a recent Dell desktop with an Intel graphics chipset, and no fancy video outputs. For a monitor, I got my hands on a JVC LT-2EM21 LED TV. If you’ve never messed with
xorg.conf you’ll have no idea what this is all about. Please watch out for the line wrapping forced by how this blog displays.
Issue number one: Monitor Specs This 22-inch JVC does not offer a realistic EDID via the VGA cable, and the specs offered online are insufficient for the task.
This means guessing and testing. In this case, standard values are available from the Myth TV folks. You have to understand about what section of the database most closely matches your chosen display device. I chose mine from the “ATSC Standard Modes” section of the list. I chose the line which matched the basic specs of 1080p:
ModeLine "ATSC-1080-60p" 148.5 1920 1960 2016 2200 1080 1082 1088 1125
This was tested using
xrandr on the commandline. Open a terminal emulator and start hacking. Read up a bit on how to use
xrandr; this one from ArchLinux is good. The proper invocation for my case was these three lines:
xrandr --newmode "ATSC-1080-60p" 148.5 1920 1960 2016 2200 1080 1082 1088 1125
xrandr --addmode VGA1 "ATSC-1080-60p"
xrandr --output VGA1 --mode "ATSC-1080-60p" && sleep 10 && xrandr --output VGA1 --mode 1024x768
That complicated last line told
xrandr to test my new mode for ten seconds, and if it didn’t work, fall back to what the RHEL insisted was correct and worked, albeit poorly. What I got was close, but shifted a bit off screen to the right.
The next step is extracted from here: Modeline Calculator. Excellent, detailed and way too long for most folks to read. The point is to understand what Modelines mean, and how to make minute adjustments when something you try gets close. I kept getting closer by shifting the display to the left bit by bit. That meant, according to the calculator page, I needed to add increments of 8 each to the numbers 1960 and 2016 in that line. I kept track of this in an open text editor application. I renamed each mode by adding a digit to the end of the identifier ATSC-1080-60p1, ATSC-1080-60p2, ATSC-1080-60p3, etc. That way
xrandr knew it was different. Then I went through the grind of the three commands in sequence, changing the information in each as needed. Once I liked what I saw, I went back and compared with the lines offered in the database paged linked above, and found this:
ModeLine "1920x1080" 148.35 1920 2008 2052 2200 1080 1084 1089 1125 +HSync +VSync
It was under the “HDTV EDID ModePool” which was pretty important, because it revealed the actual “HorizSync” rate used: 67.4318 kHz. I tested it and it worked as good as it gets. You see, JVC doesn’t see fit to offer in their documentation a genuine range for HorizSyng and VertRefresh. Without them, it’s pretty hard to make RHEL behave properly.
Issue number two: Using the info RHEL and friends make it exceptionally difficult to bypass X.org’s defaults if the EDID is bogus. Mine is bogus, and JVC won’t help. So I saw on the database page that this particular line offers a distinct value for the HorizSync, which gave me a clue how to construct my
xorg.conf. You see, you can’t tell RHEL not to use the EDID with Intel chips. It ignores everything you try. So you have to construct enough of an
xorg.conf to force the issue. If you provide the values there, X.org won’t look for them elsewhere. Here’s what I consider a minimum:
Section "Device" Identifier "IntelCard0" Driver "intel" EndSection Section "Monitor" Identifier "JVC LT-22EM21 LED TV" Vendorname "JVC" Modelname "JVC LT-22EM21 LED TV Panel 1920x1080" Option "IgnoreEDID" HorizSync 30.0 - 75.0 VertRefresh 60.0 - 75.0 ModeLine "ATSC-1080-60p" 148.35 1920 2008 2052 2200 1080 1084 1089 1125 +HSync +VSync Option "PreferredMode" "ATSC-1080-60p" EndSection Section "Screen" Identifier "Screen0" Device "IntelCard0" Monitor "JVC LT-22EM21 LED TV" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1920×1080" EndSubSection EndSection
Without a range on the “HorizSync” wide enough to accommodate the actual sync used in the display, X.org would refuse to accept the Modeline. The ranges for both that and “VertRefresh” simply have to cover what the display actually does. I have no idea how to extract the sync rate itself, but the database offered a value I could use.