Backport hdmi_portclock_limit regression fix patch to allow forcing overclocking of DVI/HDMI signals

[Joseph S Tate]

https://bugzilla.kernel.org/show_bug.cgi?id=72961

Summary: a patch included after upstream kernel 3.10 (and for ubuntu, whatever was used in the live iso) restricted DVI-D single link connections to 165MHz. Some monitors, which worked before that patch via an overclocked single link connection stopped working. This patch lets the user specify modes manually that are higher than 165MHz "at their own risk".

I've tested the patch in the upstream bug against the current (as of 19 Jun 2014) git trusty kernel tree and everything seems to work fine. While the patch listed on the above bug won't apply with git-am, it will apply as patch -p0.

I have it patched on my local branch, and can send a diff if it's needed.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-29-generic 3.13.0-29.53
ProcVersionSignature: Ubuntu 3.13.0-30.54-generic 3.13.11.2
Uname: Linux 3.13.0-30-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: jtate 2315 F.... pulseaudio
                      jtate 2635 F.... pulseaudio
 /dev/snd/controlC0: jtate 2315 F.... pulseaudio
                      jtate 2635 F.... pulseaudio
CurrentDesktop: KDE
Date: Thu Jun 19 13:30:52 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-06-16 (3 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-30-generic root=/dev/mapper/kubuntu--vg-root ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-30-generic N/A
 linux-backports-modules-3.13.0-30-generic N/A
 linux-firmware 1.127.2
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/23/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.30
dmi.board.name: Z97 Extreme4
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.30:bd05/23/2014:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnZ97Extreme4:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Tim Gardner (timg-tpi)]

40478455fefdc0bde24ae872c3f88d58a1b0e435 drm/i915: Reject >165MHz modes w/ DVI monitors

[Joseph S Tate (jtate)]

Tim, no, that's the original patch that broke my monitor.

The patch I want backported is

commit b6842feb63a23a6a988f4e1ffb93408d8ff6931e
Author: Ville Syrjälä <email address hidden>
Date: Thu Mar 27 11:08:45 2014 +0200

    drm/i915: Allow user modes to exceed DVI 165MHz limit

[Joseph S Tate (jtate)]

Oh, I see, you marked it as fix released for Utopic.

[Joseph S Tate (jtate)]

For anyone finding this in the future, this is how I set up the out of spec modes and set one to come up automatically.

Create the file /etc/X11/xorg.conf.d/90-monitor.conf (you may have to create the directory)

Add the contents of the file as:

Section "Monitor"
        Identifier "HDMI1"
        VendorName "KJT
        ModelName "78c5"
    Option "PreferredMode" "2560x1440"
    ModeLine "2560x1440" 241.50 2560 2608 2640 2720 1440 1442 1447 1481 +hsync +vsync
    ModeLine "1920x1080" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync
endSection

Modify the Identifier to match the name used by xrandr to show the connected monitor. VendorName and ModelName are optional, or you can modify to match your hardware. Use the modelines as appropriate for your monitor. You only need to add modes that are over 165MHz (the first number after the mode name). The rest of the modes will be added from the EDID. You must specify the PreferredMode or it will not use overscan modes by default.

VendorName and ModelName can usually be found in Xorg.0.log. If the ModeLines are not displayed in your Xorg.0.log file, you may wish to add a "Device" section that has a line 'Option "ModeDebug" "True"' to get more output from the modesetting module.

I'm still trying to figure out how to set the kernel frame buffer mode.

[Joseph S Tate (jtate)]

Still getting:

xrandr: Configure crtc 0 failed

when trying to set an out of spec HDMI/DVI mode with 3.13.0-30.

[Joseph S Tate (jtate)]

I do see the patch in the git repo tagged 3.13.0-31 however.

[Luis Henriques (henrix)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.13.0-32.57

---------------
linux (3.13.0-32.57) trusty; urgency=low

  [ Upstream Kernel Changes ]

  * l2tp: Privilege escalation in ppp over l2tp sockets
    - LP: #1341472
    - CVE-2014-4943

linux (3.13.0-32.56) trusty; urgency=low

  [ Luis Henriques ]

  * Merged back Ubuntu-3.13.0-30.55 security release
  * Revert "x86_64,ptrace: Enforce RIP <= TASK_SIZE_MAX (CVE-2014-4699)"
    - LP: #1337339
  * Release Tracking Bug
    - LP: #1338524

  [ Upstream Kernel Changes ]

  * ptrace,x86: force IRET path after a ptrace_stop()
    - LP: #1337339
    - CVE-2014-4699
  * hpsa: add new Smart Array PCI IDs (May 2014)
    - LP: #1337516

linux (3.13.0-31.55) trusty; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1336278

  [ Andy Whitcroft ]

  * [Config] switch hyper-keyboard to virtual
    - LP: #1325306
  * [Packaging] linux-udeb-flavour -- standardise on linux prefix

  [ dann frazier ]

  * [Config] CONFIG_GPIO_DWAPB=m
    - LP: #1334823

  [ Feng Kan ]

  * SAUCE: (no-up) arm64: dts: Add Designware GPIO dts binding to APM
    X-Gene platform
    - LP: #1334823

  [ John Johansen ]

  * SAUCE: (no-up) apparmor: fix apparmor spams log with warning message
    - LP: #1308761

  [ Kamal Mostafa ]

  * [Config] updateconfigs ACPI_PROCFS_POWER=y after v3.13.11.4 rebase

  [ Loc Ho ]

  * SAUCE: (no-up) phy-xgene: Use correct tuning for Mustang
    - LP: #1335636

  [ Michael Ellerman ]

  * SAUCE: (no-up) powerpc/perf: Ensure all EBB register state is cleared
    on fork()
    - LP: #1328914

  [ Ming Lei ]

  * Revert "SAUCE: (no-up) rtc: Add X-Gene SoC Real Time Clock Driver"
    - LP: #1274305

  [ Suman Tripathi ]

  * SAUCE: (no-up) libahci: Implement the function ahci_restart_engine to
    restart the port dma engine.
    - LP: #1335645
  * SAUCE: (no-up) ata: Fix the dma state machine lockup for the IDENTIFY
    DEVICE PIO mode command.
    - LP: #1335645

  [ Tim Gardner ]

  * [Config] CONFIG_POWERNV_CPUFREQ=y for powerpc, ppc64el
    - LP: #1324571
  * [Debian] Add UTS_UBUNTU_RELEASE_ABI to utsrelease.h
    - LP: #1327619
  * [Config] CONFIG_HAVE_MEMORYLESS_NODES=y
    - LP: #1332063
  * [Config] CONFIG_HID_RMI=m
    - LP: #1305522

  [ Upstream Kernel Changes ]

  * Revert "offb: Add palette hack for little endian"
    - LP: #1333430
  * Revert "net: mvneta: fix usage as a module on RGMII configurations"
    - LP: #1333837
  * Revert "USB: serial: add usbid for dell wwan card to sierra.c"
    - LP: #1333837
  * Revert "macvlan : fix checksums error when we are in bridge mode"
    - LP: #1333838
  * serial: uart: add hw flow control support configuration
    - LP: #1328295
  * mm/numa: Remove BUG_ON() in __handle_mm_fault()
    - LP: #1323165
  * Tools: hv: Handle the case when the target file exists correctly
    - LP: #1306215
  * Documentation/devicetree/bindings: add documentation for the APM X-Gene
    SoC RTC DTS binding
    - LP: #1274305
  * drivers/rtc: add APM X-Gene SoC RTC driver
    - LP: #1274305
  * arm64: add APM X-Gene SoC RTC DTS entry
    - LP: #1274305
  * powerpc/perf: Add Power8 cache & TLB events
    - LP: #1328914
  * powerpc/perf: Configure BH...

[free5lot (free5lot)]

I have Kubuntu 14.10 with 3.16.0-28 kernel and the issue still exists.

When I choose 3.11.0-20 during boot in Grub - 2560x1440@60Hz works perfectly without any xorg-config changing.
But versions 3.11.0-22 and 3.16.0-28 support only up to 1920x1200@60Hz or something like that.

So, 3.11.0-20 is the last kernel version I've used, that worked correctly for high-resolution monitors with DVI-D connection.

Does this regression still exist and not solved?

[free5lot (free5lot)]

Some news: solution of Joseph S Tate (jtate) from on 2014-06-19 works partly (thanks Joseph!).
These changes allow to use 3.16.0-28 kernel, but during boot on encryption stage (before / is accessible) the resolution is still incorrect, so user has to enter password in blurred screen.

I insist this bug should be called an "unfixed regression", maybe desirable or inevitable, but still a regression:

E.g. user bough a huge monitor which worked perfectly with Windows in the shop, came home and it doesn't work correctly with his favorite Linux distribution with the same DVI-D cable.
And for him it's impossible to make xorg-config, put there ModeLines from Xorg logs or xrandr output and etc. It's a step back to 1990th with all this manual xorg-config stuff.

And even more, this monitor worked perfectly the year before with the same Linux distro, and now it doesn't. For sure it's a regression, isn't it?