LCD monitor timing misdetected: 60Hz != 60 Hz

[RichardNeill]

X is not correctly detecting my monitors' timings. Despite being a digital connection (with allegedly EDID), I have to force a modeline with xrandr. The graphical xrandr tools (arandr, or KDE's system-settings) do not work.

I used to think this was solved with the binary drivers (first nvidia, then fglrx), but I now realise that a modeline can be generated with xrandr and they will work with the open-source driver.

The 1600x1200 monitors are a pair of 20" 1600x1200 VideoSeven devices, purchased in 2006, with DVI and VGA inputs. I'm using both of the DVI inputs, (one of which via an HDMI/DVI adapter cable). They tend to be a bit fussy about being driven at the required 60Hz x 75 kHz, saying that the signal is out of range: they need 60x75, they are getting 60x75, but it's not good enough!).

I attach xorg.log to this. Also, here is what I get when I run xrandr (to list modes), then when I run my xrandr.sh script , then xrandr again. The 60 Hz mode is now listed as "59.9".

I'm filing this on xserver-xorg-core (2:1.15.1-0ubuntu8), though it might be a video-driver bug: xserver-xorg-video-radeon

#Output of Xrandr. At this point, only the DisplayPort monitor works rightly.

[rjn@chocolate ~]$ xrandr -d :0
Screen 0: minimum 320 x 200, current 4800 x 1200, maximum 16384 x 16384
DisplayPort-0 connected 1600x1200+3200+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200 60.0 +
   1920x1080 50.0
   1600x1200 60.0*
   1680x1050 59.9
   1280x1024 75.0 60.0
   1440x900 75.0 59.9
   1280x960 60.0
   1280x800 59.9
   1152x864 75.0
   1280x720 60.0 50.0 59.9
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   720x576 50.0
   720x480 60.0 59.9
   640x480 75.0 72.8 66.7 60.0 59.9
   720x400 70.1
HDMI-0 connected 1600x1200+1600+0 (normal left inverted right x axis y axis) 408mm x 306mm
   1600x1200 60.0*+
   1280x1024 85.0 75.0 60.0
   1024x768 85.0 75.1 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 75.0 72.8 66.7 60.0
   720x400 70.1
DVI-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 408mm x 306mm
   1600x1200 60.0*+
   1280x1024 85.0 75.0 60.0
   1024x768 85.0 75.1 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 75.0 72.8 66.7 60.0
   720x400 70.1

Now I run xrandr.sh, to add and apply new modes.

[rjn@chocolate ~]$ ./bin/xrandr.sh
This sets up my 3-head display. It can be called from ssh, as the display is forced to :0
 * The 2x VideoSeven 1600x1200 displays don't normally light up at all (they think the signal is out of range at 60 Hz, Xrandr's version is 59.9 Hz)
 * The Samsung monitor (1920x1200) comes up at 1600x1200
 * Everything is cloned, rather than 3 in a row
The modelines for the VideoSeven displays are from 'cvt 1600 1200 60' .
Now doing it... this may take a few seconds...
Creating new mode 1600x1200_60.00...
Adding this mode for the DVI-0 and HDMI-0 outputs...
Setting the modes and DPIs for the 3 outputs DVI-0, HDMI-0, DisplayPort-0...
Arranging the displays 3 in a row (DVI-0, HDMI-0, DisplayPort-0)...
Done

Now, all monitors work as they should, and here is the output of xrandr again.

[rjn@chocolate ~]$ xrandr -d :0
Screen 0: minimum 320 x 200, current 5120 x 1200, maximum 16384 x 16384
DisplayPort-0 connected 1920x1200+3200+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200 60.0*+
   1920x1080 50.0
   1600x1200 60.0
   1680x1050 59.9
   1280x1024 75.0 60.0
   1440x900 75.0 59.9
   1280x960 60.0
   1280x800 59.9
   1152x864 75.0
   1280x720 60.0 50.0 59.9
   1024x768 75.1 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   720x576 50.0
   720x480 60.0 59.9
   640x480 75.0 72.8 66.7 60.0 59.9
   720x400 70.1
HDMI-0 connected 1600x1200+1600+0 (normal left inverted right x axis y axis) 408mm x 306mm
   1600x1200 60.0 +
   1280x1024 85.0 75.0 60.0
   1024x768 85.0 75.1 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 75.0 72.8 66.7 60.0
   720x400 70.1
   1600x1200_60.00 59.9*
DVI-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 408mm x 306mm
   1600x1200 60.0 +
   1280x1024 85.0 75.0 60.0
   1024x768 85.0 75.1 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 75.0 72.8 66.7 60.0
   720x400 70.1
   1600x1200_60.00 59.9*

---- xrandr.sh script ----
#!/bin/bash

echo "This sets up my 3-head display. It can be called from ssh, as the display is forced to :0"
echo " * The 2x VideoSeven 1600x1200 displays don't normally light up at all (they think the signal is out of range at 60 Hz, Xrandr's version is 59.9 Hz)"
echo " * The Samsung monitor (1920x1200) comes up at 1600x1200"
echo " * Everything is cloned, rather than 3 in a row"
echo "The modelines for the VideoSeven displays are from 'cvt 1600 1200 60' ."
echo "Now doing it... this may take a few seconds..."

#Displays are physically located: (Left) DVI-0 HDMI-0 DisplayPort-0 (Right)
#The -d :0 is the $DISPLAY, so that this works on my desktop PC even if I ssh in from a laptop to fix it!

#Create the mode with the correct timing. Use the mode from: cvt 1600 1200 60 #or: cvt -r 1600 1200 60
echo "Creating new mode 1600x1200_60.00..."
xrandr -d :0 --newmode "1600x1200_60.00" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync

#Add these modes for the outputs concerned:
echo "Adding this mode for the DVI-0 and HDMI-0 outputs..."
xrandr -d :0 --addmode DVI-0 1600x1200_60.00
xrandr -d :0 --addmode HDMI-0 1600x1200_60.00

#Set the outputs to these modes (and set the DPI while we're at it).
#NB the 2x 1600x1200 monitors are exactly that size (measured), thus 99.6 dpi, while the 1920x1200 is fudged to 99.6 dpi for consistency, though it's actually fractionally less.
echo "Setting the modes and DPIs for the 3 outputs DVI-0, HDMI-0, DisplayPort-0..."
xrandr -d :0 --output DVI-0 --mode 1600x1200_60.00 --fbmm 408x306
xrandr -d :0 --output HDMI-0 --mode 1600x1200_60.00 --fbmm 408x306
xrandr -d :0 --output DisplayPort-0 --mode 1920x1200 --fbmm 490x306

#Now arrange the displays:
echo "Arranging the displays 3 in a row (DVI-0, HDMI-0, DisplayPort-0)..."
xrandr -d :0 --output DVI-0 --left-of HDMI-0 --output HDMI-0 --left-of DisplayPort-0

echo "Done"
---
ApportVersion: 2.14.4-0ubuntu1
Architecture: amd64
DistroRelease: Ubuntu 14.10
HibernationDevice: RESUME=UUID=dd46a6f0-bcb8-4e75-b77d-6158117027ac
InstallationDate: Installed on 2014-07-06 (1 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1)
IwConfig:
 eth0 no wireless extensions.

 eth1 no wireless extensions.

 lo no wireless extensions.
MachineType: System manufacturer System Product Name
Package: linux (not installed)
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.15.0-6-generic root=UUID=591b7866-2111-434a-8423-b79bbf373c85 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.15.0-6.11-generic 3.15.0
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.15.0-6-generic N/A
 linux-backports-modules-3.15.0-6-generic N/A
 linux-firmware 1.132
RfKill:

Tags: utopic
Uname: Linux 3.15.0-6-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
dmi.bios.date: 07/01/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4105
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P8Z68-V LX
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4105:bd07/01/2013:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP8Z68-VLX:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1338622

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[RichardNeill (ubuntu-richardneill)]

apport information

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc4-utopic/

[RichardNeill (ubuntu-richardneill)]

Hi Joseph,
Can I ask why you think this might be a kernel bug? I've had this problem for about 11 years, with multiple kernels, distros and both AMD and Nvidia graphics cards. I always fixed it with the binary driver. However, I only just discovered that it could also be fixed by the correct modeline in X.

My current hunch is that these particular monitors are very choosy about modelines (notably, when X drives them at 60Hzx75kHz, they display an error about the timing being out of range and ask me to set it to 60x75). So either:

1) X is mis-calculating the modeline from the information given by the monitor's EDID.

2) There is an obscure compatibility bug, where these specific monitors (this model and vendor) need a special-case hack.

I think (1) is the case, because Xorg already auto-detects them at 1600x1200@@60Hz, and if I then manually generate a modeline with "cvt 1600 1200" and force that, everything works.

HTH - Richard

P.S. Here is a picture of the problematic monitor. I bought this pair of 1600x1200 20" monitors as an investment in not getting eyestrain, back in 2003. They've worked really welll since then, but they were one of the first set of devices to support DVI at that resolution. This might be a clue to the compatibility problem. Photo here:
http://skinflint.co.uk/eu/v7-videoseven-l20-1cm-a40169.html

[RichardNeill (ubuntu-richardneill)]

I did just try the upstream kernel as requested (linux-image-3.16.0-031600rc4-generic).
This does (mostly) fix the problem, but not entirely, so I'll tag it bug-exists upstream.

1) I have all 3 monitors working correctly if I combine kernel 3.16 AND a hand-tuned xorg.conf

2) Without Xorg.conf , the monitors are not correctly autoconfigured.

3) Everything is now great in XFCE, but under KDE, 2 of the 3 monitors don't show the mouse-pointer.

In case it's relevant, I'm still seeing dmesg errors of this type:
[ 60.216937] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[ 60.216941] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing C7E8 (len 62, WS 0, PS 0) @ 0xC804