4k@60Hz works in Windows, not in Linux *** Workaround found ***

25 August 2016 update - Andy from Nvidia has come through with a workaround by limiting modes to supported ones via a manual specified EDID from another 4K display. Jump to page 2 of the post, give it a try and see if it works for you as well!

==================

19 August 2016 - after more than two months of silence on these forums for this issue (and most of the other reported issues it seems as well) I’ve decided to open my wallet to get a fix from someone, anyone. First person who gives me a workable solution using my existing hardware on Linux Mint 17.3 with 4k@60Hz over HDMI 2.0 gets $150 via the payment method of their choice. For others who have been having the same issue, I encourage you to add to this bounty as a way to say thanks since you’ll reap the rewards as well. I’m happy to provide logs and other information as needed - just ask.

The only caveat to my offer - no bounty if you are a Nvidia employee. You already got paid to fix this stuff. - D

*** Original post ***

The setup - EVGA 960 GTX 2GB card running solo on a x64 Linux Mint 17.3 (Ubuntu 14.04 base) with 24GB RAM. Exact same hardware running under either Windows 7 or Windows 10 gets 1080P@120Hz and 4k@60Hz without any issue on latest stable drivers from Nvidia website. Under Windows the driver does switch into the reduced YCbCr422 color space when using the above. TV is a Vizio D40u-D1 with a +18Gbps supported cable (Vizio brand in fact) plugged into the only port that supports 4k@60Hz, port 5.

Under Linux - blank screen for a couple of seconds, no signal and finally safe switch back to working resolution. Only color spaces that appear under the drop box for Monitor are RGB and YCbCr444

What I’ve tried so far with no effect:

  • Install ALL driver versions available from both Ubuntu and the Updated Graphics PPA
  • Added the Option for NoEdidHDMI2Check and some other seemingly relevant ones from the Nvidia README file in both in the /usr/share/X11/xorg.conf.d and /etc/X11 locations
  • Tried several kernels between current and 4.2
  • Install a newer Ubuntu 16.04 to spare drive and loaded up just the Nvidia driver and nothing else
  • Oddly the Xorg logs doesn’t show any errors - it shows the attempts to switch to the resolution but no outcome.

    Here is a link to the nvidia Debug file:
    https://drive.google.com/file/d/0B4ukNWkQbld5dFRraHlYd1dzSWM/view?usp=sharing

    Any help is greatly appreciated - if you need more info just ask for it.

    I’m in the same boat. Tried upgrading to 364 a number of times for a number of dot releases now and it just kills my signal.

    Running Arch Linux, a GTX 970, with a Samsung Curved LED which has had numerous problems with nvidia drivers.

    4k@30 works but not @60. I always end up rolling back to 361 and my older kernel to get my 4k@60. Seems weird nvidia removed support in their newer drivers. Or broke it and never fixed it. Been like this for a long time.

    I’ve decided to finally get active on this forum to see if we can get a fix. I really like my NVIDIA for gaming in windows but Linux is a mess right now for me.

    Hoping I don’t have to switch GPUs as I really prefer NVIDIA over the years, but I need my 4k@60 for development. :)

    Oh, also have you tried the 367 beta drivers yet? I haven’t but wondering if perhaps they fixed the issues in there and just didn’t merge those fixes into 364.

    When I did the fresh install of 16.04 I used the 367 drivers - no dice. Ambershark what kernel were/are you on to get 4k@60hz on the 361 drivers?

    On arch I had to specifically set these packages to the versions noted:

    warning: libglvnd: ignoring package upgrade (0.0.0.20160315-1 => 0.1.0.20160411-1)
    warning: linux: ignoring package upgrade (4.4.5-1 => 4.5.4-1)
    warning: linux-headers: ignoring package upgrade (4.4.5-1 => 4.5.4-1)
    warning: nvidia: ignoring package upgrade (361.28-4 => 364.19-3)
    warning: nvidia-libgl: ignoring package upgrade (361.28-5 => 364.19-1)
    warning: nvidia-utils: ignoring package upgrade (361.28-5 => 364.19-1)

    My kernel as you can see is 4.4.5. This is ARCH’s version of the kernel though so it may differ from stock kernel.org.

    Set my install to the same versions - no change. I did notice something that I thought was peculiar, in Nvidia settings it shows the refresh rates in a shuffled ordered instead of highest to lowest - it shows as 30Hz, 60Hz, 24Hz.

    I was asked to post to this forum by Nvidia for assistance but other than Ambershark no one seems willing to comment?!

    Can you please remove the ModeValidation overrides and add

    Option "ModeDebug"
    

    to xorg.conf, and then attach a bug report generated after starting X and attempting to switch to that mode?

    Done - attaching file to post
    nvidia-bug-report.log.gz (222 KB)

    Okay I dug thru the last debug file and I think I found the issue but I have no idea how to resolve it. Basically it looks like the driver decides to create a couple of the metamodes twice - the first one is named normally (3840x2160_60) but the 2nd one gets suffixed with the digit 0 like this - 3840x2160_60_0

    I was able to switch to the 1920x1080_120_0 using the advance view in Nvidia-settings but I wasn’t able to do that for the 4K resolutions - it only doubled the 24hz and 30hz metamodes.

    So the question becomes how do we prevent the duplicate modes or get to switch to them? I’ve attached a screenshot to better explain.

    If anyone else in the forum is having a similar issue, please make a reply with your card model and TV model. Ditto for anyone who has 4k@60Hz working - perhaps we can work together to figure this out.

    I have working 4k@60Hz without any extra steps on Arch x64.
    My monitor Philips BDM4350UC is connected through Display Port (I had to change do DP 1.2 in monitor options for 60Hz).
    When I will be back home i will try HDMI and report back.

    Loaded up the 367.27 driver today under Mint 17.3 and newest kernel - still the same. I can backdoor 1080P@120Hz via the duplicate metamodes in Nvidia-Settings->Display Config->Advanced but that does not work for 4k@60Hz

    Has anybody else got 4k@60Hz working on Ubuntu Trusty / Mint 17.x install?

    Crazy… I was just about to start a thread about literally almost the exact same thing.

    I have an EVGA 960 4GB, which works perfectly at 4K-60Hz on my Vizio D40u-D1 40" TV under Windows 10, but only runs at 30Hz under Arch Linux.

    I got some help on reddit in regard to xorg settings here: https://www.reddit.com/r/archlinux/comments/4q7lst/is_setting_the_ycbcr420_color_space_possible_with/

    Setting the NoEdidHDMI2Check mode validation did at least change things so my computer would attempt to do 60 Hz at 4K (wouldn’t even try before), which would leave me with a “no signal” screen. Unfortunately, it didn’t help at all aside from that.

    Interesting to see that the version 361 drivers are working. I might try downgrading later and at least hold out there until a fix comes through.

    If it’s at all useful, here are the contents of my xorg.conf file:

    cat /etc/X11/xorg.conf.d/80-nvidia.conf 
    # nvidia-settings: X configuration file generated by nvidia-settings
    # nvidia-settings:  version 367.27  (builduser@svenstaro)  Mon Jun 13 18:56:26 CEST 2016
    
    Section "ServerLayout"
        Identifier     "Layout0"
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "Mouse0" "CorePointer"
        Option         "Xinerama" "0"
    EndSection
    
    Section "Files"
    EndSection
    
    Section "InputDevice"
        # generated from default
        Identifier     "Mouse0"
        Driver         "mouse"
        Option         "Protocol" "auto"
        Option         "Device" "/dev/psaux"
        Option         "Emulate3Buttons" "no"
        Option         "ZAxisMapping" "4 5"
    EndSection
    
    Section "InputDevice"
        # generated from default
        Identifier     "Keyboard0"
        Driver         "kbd"
    EndSection
    
    Section "Monitor"
        # HorizSync source: edid, VertRefresh source: edid
        Identifier     "Monitor0"
        VendorName     "Unknown"
        ModelName      "VIZ D40u-D1"
        HorizSync       15.0 - 140.0
        VertRefresh     25.0 - 76.0
        Option         "DPMS"
    EndSection
    
    Section "Device"
        Identifier     "Device0"
        Driver         "nvidia"
        VendorName     "NVIDIA Corporation"
        BoardName      "GeForce GTX 960"
    EndSection
    
    Section "Screen"
        Identifier     "Screen0"
        Device         "Device0"
        Monitor        "Monitor0"
        DefaultDepth   24
        Option         "Stereo" "0"
        Option         "nvidiaXineramaInfoOrder" "DFP-1"
        Option         "metamodes" "3840x2160_60 +0+0; nvidia-auto-select +0+0"
    # Option "ModeValidation" "NoEdidHDMI2Check"
        Option         "SLI" "Off"
        Option         "ColorSpace" "YCbCr420"
        Option         "ColorRange" "Full"
        Option         "MultiGPU" "Off"
        Option         "BaseMosaic" "off"
        SubSection     "Display"
            Depth       24
        EndSubSection
    EndSection
    

    Bump? Wondering if any devs can let us know whether a fix for this in the works. Is 4K @ 60Hz over HDMI2 supposed to be working under Linux at all?

    Just tried with the new 367.35 drivers. Still can’t get 4K 60 Hz over HDMI 2.0…

    The funny thing is it used to work in the 361 drivers. It was removed or broken in 364 and carried on into 367.

    I’ve waited a long time to upgrade from my 361 drivers. At this point I’m thinking it probably won’t happen. I’ve started looking into AMD for my next card which sucks since I’ve been an NVIDIA user since the 90s.

    I wish they would just open source the drivers so we could fix them ourselves.

    Anyone try the new 370.23 beta drivers yet?

    Just loaded up the new drivers - still no go. And as per usual, no one from nvidia seems to be helping at all.

    Time to try a new tactic …

    Hmm, that’s sad to hear. Was just curious. I actually ended up returning my 960 GTX a while back, as it wasn’t any better than the 760 GTX I’d been previously using and didn’t have much more to offer other than the supposed HDMI2.0 support.

    I got an XFX RX 480 to replace it, and unfortunately the drivers are kind of a mess right now (but at least being worked on). I can’t get a video signal at all with the Vizio as HDMI 2.0 support hasn’t been merged in yet (sounds like it’ll land in kernel 4.9). And of course, everything runs fine under Windows. I’ll perhaps try patching the kernel myself with the DAL code change from AMD to see how things turn out.

    Going back to Nvidia, I wonder if the 1060 GTX has issues with this TV. I know it’s something to do with this particular TV (perhaps in combination with the 960 GTX), as I was able to use my roommate’s HiSense TV in 4K @ 60Hz without issue.

    Sorry you guys haven’t received any assistance, yet.

    4k@60Hz over HDMI works for me with an LG 40UB8000 + 370.23 + GeForce GTX 960.

    I looked into this, and I think I found the problem. There is definitely an NVIDIA driver bug here, but I think there are several possible work arounds.

    I’ll attach the EDID from my LG 40UB8000 TV

    (Note: the forum software wouldn’t let me upload “edid.bin” because the file extension wasn’t whitelisted; I’ve named it “edid.txt”. The CustomEDID option won’t care what the file extension is.)

    As an experiment, can you download that EDID and use the “CustomEDID” X configuration option to force the use of that EDID?

    E.g.,

    option "CustomEDID" "DFP-1:/path/to/edid.bin"
    

    You may need to use a different value for “DFP-1”, check your current X log for a line like:

    [ 8.999] (–) NVIDIA(0): VIZ D40u-D1 (DFP-1): connected

    I’d be curious if 4k@60Hz works for you with that EDID.

    Second, I extracted the EDID for the Vizio D40u-D1 and loaded that with 370.23 in my test config. An interesting thing about the D40u-D1’s EDID is that there are two 3840x2160@60 modes and two 4096x2160@60 modes:

    [   662.538] (--) NVIDIA(0): --- EDID for VIZ D40u-D1 (HDMI-0) ---
    [...]
    [   662.540] (--) NVIDIA(0):   3840 x 2160 @ 60 Hz
    [   662.540] (--) NVIDIA(0):     Pixel Clock      : 593.41 MHz
    [   662.540] (--) NVIDIA(0):     HRes, HSyncStart : 3840, 4016
    [   662.540] (--) NVIDIA(0):     HSyncEnd, HTotal : 4104, 4400
    [   662.540] (--) NVIDIA(0):     VRes, VSyncStart : 2160, 2168
    [   662.540] (--) NVIDIA(0):     VSyncEnd, VTotal : 2178, 2250
    [   662.540] (--) NVIDIA(0):     H/V Polarity     : +/+
    [   662.540] (--) NVIDIA(0):     CEA Format       : 97
    [   662.540] (--) NVIDIA(0):     Aspect Ratio     : 16:9
    [   662.540] (--) NVIDIA(0):     RGB 444 bpcs     : 8, 10, 12
    [   662.540] (--) NVIDIA(0):     YUV 444 bpcs     : 8, 10, 12
    [   662.540] (--) NVIDIA(0):     YUV 422 bpcs     : 8, 10, 12
    [   662.540] (--) NVIDIA(0):   4096 x 2160 @ 60 Hz
    [   662.540] (--) NVIDIA(0):     Pixel Clock      : 593.41 MHz
    [   662.540] (--) NVIDIA(0):     HRes, HSyncStart : 4096, 4184
    [   662.540] (--) NVIDIA(0):     HSyncEnd, HTotal : 4272, 4400
    [   662.540] (--) NVIDIA(0):     VRes, VSyncStart : 2160, 2168
    [   662.540] (--) NVIDIA(0):     VSyncEnd, VTotal : 2178, 2250
    [   662.540] (--) NVIDIA(0):     H/V Polarity     : +/+
    [   662.540] (--) NVIDIA(0):     CEA Format       : 102
    [   662.540] (--) NVIDIA(0):     Image Size       : 256 mm x 135 mm
    [   662.540] (--) NVIDIA(0):     RGB 444 bpcs     : 8, 10, 12
    [   662.540] (--) NVIDIA(0):     YUV 444 bpcs     : 8, 10, 12
    [   662.540] (--) NVIDIA(0):     YUV 422 bpcs     : 8, 10, 12
    [   662.540] (--) NVIDIA(0):   3840 x 2160 @ 60 Hz
    [   662.540] (--) NVIDIA(0):     Pixel Clock      : 593.41 MHz
    [   662.540] (--) NVIDIA(0):     HRes, HSyncStart : 3840, 4016
    [   662.540] (--) NVIDIA(0):     HSyncEnd, HTotal : 4104, 4400
    [   662.540] (--) NVIDIA(0):     VRes, VSyncStart : 2160, 2168
    [   662.540] (--) NVIDIA(0):     VSyncEnd, VTotal : 2178, 2250
    [   662.540] (--) NVIDIA(0):     H/V Polarity     : +/+
    [   662.540] (--) NVIDIA(0):     CEA Format       : 97
    [   662.540] (--) NVIDIA(0):     Aspect Ratio     : 16:9
    [   662.540] (--) NVIDIA(0):     YUV 420 bpcs     : 8
    [   662.540] (--) NVIDIA(0):   4096 x 2160 @ 60 Hz
    [   662.540] (--) NVIDIA(0):     Pixel Clock      : 593.41 MHz
    [   662.540] (--) NVIDIA(0):     HRes, HSyncStart : 4096, 4184
    [   662.541] (--) NVIDIA(0):     HSyncEnd, HTotal : 4272, 4400
    [   662.541] (--) NVIDIA(0):     VRes, VSyncStart : 2160, 2168
    [   662.541] (--) NVIDIA(0):     VSyncEnd, VTotal : 2178, 2250
    [   662.541] (--) NVIDIA(0):     H/V Polarity     : +/+
    [   662.541] (--) NVIDIA(0):     CEA Format       : 102
    [   662.541] (--) NVIDIA(0):     Image Size       : 256 mm x 135 mm
    [   662.541] (--) NVIDIA(0):     YUV 420 bpcs     : 8
    

    Note that in 370.23 we added logging of the EDID-reported per-mode supported colorspace (RGB vs YUV) and decimation (444 vs 422 vs 420) (and bits per component, bpcs, but that is less relevant to this bug).

    All of the modes in the EDID get considered by mode validation, and then end up in the modepool:

    [   662.584] (II) NVIDIA(GPU-0): --- Modes in ModePool for VIZ D40u-D1 (DFP-1) ---
    [...]
    [   662.584] (II) NVIDIA(GPU-0): "4096x2160_60"       : CEA-861B:#102:4096x2160x59.940Hz/P (from: EDID)
    [   662.584] (II) NVIDIA(GPU-0): "4096x2160_60_0"     : CEA-861B:#102:4096x2160x59.940Hz/P (from: EDID)
    [...]
    [   662.584] (II) NVIDIA(GPU-0): "3840x2160_60"       : CEA-861B:#97:3840x2160x59.940Hz/P (from: EDID)
    [   662.584] (II) NVIDIA(GPU-0): "3840x2160_60_0"     : CEA-861B:#97:3840x2160x59.940Hz/P (from: EDID)
    [...]
    [   662.584] (II) NVIDIA(GPU-0): --- End of ModePool for VIZ D40u-D1 (DFP-1): ---
    

    The extra “_0” is just to distinguish the modes, so that each has a unique name.

    “4096x2160_60” is the 4096x2160_60 YUV420 mode, and “4096x2160_60_0” is the 4096x2160_60 RGB444/YUV422/YUV422 mode (or vice versa… it is a hole in our logging that you cannot tell which is which from the above).

    You can switch between modes using the nvidia-settings commandline, e.g.,

    nvidia-settings -a currentmetamode=4096x2160_60
    

    Using the Vizio EDID (i.e., without the “CustomEDID” option), I’d be curious in your results testing each of:

    nvidia-settings -a currentmetamode=4096x2160_60
    nvidia-settings -a currentmetamode=4096x2160_60_0
    nvidia-settings -a currentmetamode=3840x2160_60
    nvidia-settings -a currentmetamode=3840x2160_60_0
    

    Having two modes that are identical, except for the supported colorspace and decimation, trips up the driver during modeset-time validation. In my testing, it looks like the YUV420 modes fail due to this confusion. I’d be curious if the RGB444/YUV422/YUV422 modes work for you with the Vizio EDID, or if the YUV420 modes work for you when you use the LG EDID.

    The LG EDID I provided at the start of this message avoids the problem because it /only/ has YUV420 modes, so the driver doesn’t get confused by identical-except-for-colorspace modes.

    We’ll work on fixing the driver for a subsequent release, but I hope the LG EDID can serve as a workaround for you in the mean time.

    Let me know what you find.

    edid.txt (256 Bytes)