Bug 67030

Summary: [HSW] no modes bigger than 1080p in the parsed EDID for 4k TV on both HDMI/VGA
Product: DRI Reporter: cancan,feng <cancan.feng>
Component: DRM/IntelAssignee: Damien Lespiau <damien.lespiau>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: enhancement    
Priority: medium CC: jinxianx.guo, qingshuai.tian
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
machine boot info
none
fix hdmi port clock limits on haswell
none
fix hdmi port clock limits on haswell v2
none
system boot info with patch
none
fix hdmi port clock limits v3
none
card0-HDMI-A-2
none
card0-VGA-1
none
Parse 4k VICs
none
boot dmesg with patch 83302
none
X server patch to look at the TMDS max frequency field from the EDID
none
gnome overscan
none
gnome rotation inverted
none
gnome 3840x2160@30.0
none
dmesg of new round test with latest kernel and X11R7
none
dmesg with fixed kernel and X server none

Description cancan,feng 2013-07-18 08:58:45 UTC
Environment:
--------------------------------------------
Kernel: (drm-intel-next-queued)8f588cfc349bbbd8ae62a13679b9efba41645064
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Wed Jul 17 12:19:03 2013 -0700

    drm/i915: Create VMAs

Bug detail Description:
--------------------------------------------
We bought a new SKYWORTH 50E780U 50" TV which supports 3840x2160. I tested it on our HSW desktop and found that it doesn't support mode 3840x2160. 
Here I list all of the HDMI modes.

18      16      connected       HDMI-A  600x340         30                                                           [15/1543]
  modes:
  name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot flags type clock
[0]  1280x720 60 1280 1390 1430 1650 720 725 730 750 0x5 0x48 74250
[1]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148500
[2]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148352
[3]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x15 0x40 74250
[4]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x15 0x40 74176
[5]  1920x1080 50 1920 2448 2492 2640 1080 1084 1089 1125 0x5 0x40 148500
[6]  1920x1080i 50 1920 2448 2492 2640 1080 1084 1094 1125 0x15 0x40 74250
[7]  1280x1024 75 1280 1296 1440 1688 1024 1025 1028 1066 0x5 0x40 135000
[8]  1280x720 60 1280 1390 1430 1650 720 725 730 750 0x5 0x40 74176
[9]  1280x720 50 1280 1720 1760 1980 720 725 730 750 0x5 0x40 74250
[10]  1440x576i 50 1440 1464 1590 1728 576 580 586 625 0x101a 0x40 27000
[11]  1024x768 75 1024 1040 1136 1312 768 769 772 800 0x5 0x40 78800
[12]  1024x768 70 1024 1048 1184 1328 768 771 777 806 0xa 0x40 75000
[13]  1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000
[14]  1440x480i 60 1440 1478 1602 1716 480 488 494 525 0x101a 0x40 27027
[15]  1440x480i 60 1440 1478 1602 1716 480 488 494 525 0x101a 0x40 27000
[16]  832x624 75 832 864 928 1152 624 625 628 667 0xa 0x40 57284
[17]  800x600 75 800 816 896 1056 600 601 604 625 0x5 0x40 49500
[18]  800x600 72 800 856 976 1040 600 637 643 666 0x5 0x40 50000
[19]  800x600 60 800 840 968 1056 600 601 605 628 0x5 0x40 40000
[20]  800x600 56 800 824 896 1024 600 601 603 625 0x5 0x40 36000
[21]  720x576 50 720 732 796 864 576 581 586 625 0xa 0x40 27000
[22]  720x480 60 720 736 798 858 480 489 495 525 0xa 0x40 27027
[23]  720x480 60 720 736 798 858 480 489 495 525 0xa 0x40 27000
[24]  640x480 75 640 656 720 840 480 481 484 500 0xa 0x40 31500
[25]  640x480 73 640 664 704 832 480 489 491 520 0xa 0x40 31500
[26]  640x480 67 640 704 768 864 480 483 486 525 0xa 0x40 30240
[27]  640x480 60 640 656 752 800 480 490 492 525 0xa 0x40 25200
[28]  640x480 60 640 656 752 800 480 490 492 525 0xa 0x40 25175
[29]  720x400 70 720 738 846 900 400 412 414 449 0x6 0x40 28320
Comment 1 cancan,feng 2013-07-18 08:59:34 UTC
Created attachment 82577 [details]
machine boot info
Comment 2 Chris Wilson 2013-07-18 09:21:23 UTC
HSW (and all earlier gen) do not support HDMI1.4 and so do not support 3840x2160 over a single HDMI link. The closest we can do is DP1.2.
Comment 3 Daniel Vetter 2013-07-18 10:21:40 UTC
Haswell actually does support HDMI1.4 ... it's just not implemented.
Comment 4 Daniel Vetter 2013-07-21 11:03:31 UTC
Created attachment 82766 [details] [review]
fix hdmi port clock limits on haswell

Please test the attached patch.
Comment 5 Daniel Vetter 2013-07-21 11:06:03 UTC
Created attachment 82769 [details] [review]
fix hdmi port clock limits on haswell v2

Oops, this is the right thing.
Comment 6 cancan,feng 2013-07-22 02:21:31 UTC
(In reply to comment #5)
> Created attachment 82769 [details] [review] [review]
> fix hdmi port clock limits on haswell v2
> 
> Oops, this is the right thing.

If this patch tends to fix the "HDMI overscan" issue which is bug #67027 or bug #67030?
I tested this patch on our hsw desktop, the two issues look like before. It doesn't work.
Comment 7 cancan,feng 2013-07-22 02:37:03 UTC
Created attachment 82796 [details]
system boot info with patch
Comment 8 Daniel Vetter 2013-07-22 05:54:21 UTC
Created attachment 82800 [details] [review]
fix hdmi port clock limits v3

Yeah, the patch wasn't updating the ->mode_valid callback. With this one here we should have many more modes listed, and hopefully also the 4k mode. Please retest.
Comment 9 cancan,feng 2013-07-22 06:20:02 UTC
(In reply to comment #8)
> Created attachment 82800 [details] [review] [review]
> fix hdmi port clock limits v3
> 
> Yeah, the patch wasn't updating the ->mode_valid callback. With this one
> here we should have many more modes listed, and hopefully also the 4k mode.
> Please retest.

By the way, I tested it with Windows 7 on HSW desktop, here is the max resolution:
  VGA                 HDMI
2048x1152          3840x2160
Comment 10 Daniel Vetter 2013-07-22 06:35:07 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Created attachment 82800 [details] [review] [review] [review]
> > fix hdmi port clock limits v3
> > 
> > Yeah, the patch wasn't updating the ->mode_valid callback. With this one
> > here we should have many more modes listed, and hopefully also the 4k mode.
> > Please retest.
> 
> By the way, I tested it with Windows 7 on HSW desktop, here is the max
> resolution:
>   VGA                 HDMI
> 2048x1152          3840x2160

Just to check: Does the max resolution of 2048x1152 on VGA work on linux?
Comment 11 cancan,feng 2013-07-22 06:42:08 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Created attachment 82800 [details] [review] [review] [review] [review]
> > > fix hdmi port clock limits v3
> > > 
> > > Yeah, the patch wasn't updating the ->mode_valid callback. With this one
> > > here we should have many more modes listed, and hopefully also the 4k mode.
> > > Please retest.
> > 
> > By the way, I tested it with Windows 7 on HSW desktop, here is the max
> > resolution:
> >   VGA                 HDMI
> > 2048x1152          3840x2160
> 
> Just to check: Does the max resolution of 2048x1152 on VGA work on linux?

No, 2048x1152 doesn't work on linux.

9       10      connected       VGA     930x520         13
  modes:
  name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot flags type clock
[0]  1920x1080 60 1920 1968 2000 2080 1080 1083 1088 1111 0x9 0x48 138500
[1]  1280x1024 75 1280 1296 1440 1688 1024 1025 1028 1066 0x5 0x40 135000
[2]  1024x768 75 1024 1040 1136 1312 768 769 772 800 0x5 0x40 78800
[3]  1024x768 70 1024 1048 1184 1328 768 771 777 806 0xa 0x40 75000
[4]  1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000
[5]  800x600 75 800 816 896 1056 600 601 604 625 0x5 0x40 49500
[6]  800x600 72 800 856 976 1040 600 637 643 666 0x5 0x40 50000
[7]  800x600 60 800 840 968 1056 600 601 605 628 0x5 0x40 40000
[8]  800x600 56 800 824 896 1024 600 601 603 625 0x5 0x40 36000
[9]  640x480 75 640 656 720 840 480 481 484 500 0xa 0x40 31500
[10]  640x480 73 640 664 704 832 480 489 491 520 0xa 0x40 31500
[11]  640x480 60 640 656 752 800 480 490 492 525 0xa 0x40 25200
[12]  720x400 70 720 738 846 900 400 412 414 449 0x6 0x40 28320
Comment 12 cancan,feng 2013-07-22 06:51:32 UTC
(In reply to comment #8)
> Created attachment 82800 [details] [review] [review]
> fix hdmi port clock limits v3
> 
> Yeah, the patch wasn't updating the ->mode_valid callback. With this one
> here we should have many more modes listed, and hopefully also the 4k mode.
> Please retest.

I retest this patch and there are not more modes listed, it's still the same as before.
Comment 13 Daniel Vetter 2013-07-22 07:29:38 UTC
Hm, we seem to not be able to see any mode > 1080p ... We should list them, but then prune them when they're hitting a limit.

I guess this is an issue with our EDID parser. Can you please attach the binary edid from /sys/class/drm/card0-<port-name>/edid and attach it?
Comment 14 cancan,feng 2013-07-22 07:57:01 UTC
Created attachment 82805 [details]
card0-HDMI-A-2
Comment 15 cancan,feng 2013-07-22 08:16:59 UTC
(In reply to comment #13)
> Hm, we seem to not be able to see any mode > 1080p ... We should list them,
> but then prune them when they're hitting a limit.
> 
> I guess this is an issue with our EDID parser. Can you please attach the
> binary edid from /sys/class/drm/card0-<port-name>/edid and attach it?

I get the edid of HDMI by using "xrandr --verbose", and I attached the HDMI binary edid in the attachment.
edid of HDMI:
 EDID:
                00ffffffffffff004d77010001000000
                1c160103803c22780a0dc9a057479827
                12484cbfef0001010101010101010101
                010101010101011d007251d01e206e28
                5500c48e2100001e011d8018711c1620
                582c2500c48e2100009e000000fc0053
                6b79776f727468205548440a000000fd
                00314c0f500e000a20202020202001b1
                020329744b84101f0513140102110615
                26097f03117f18830100006d030c0030
                00b83c2f8060010203011d00bc52d01e
                20b8285540c48e2100001e011d80d072
                1c1620102c2580c48e2100009e8c0ad0
                8a20e02d10103e9600138e210000188c
                0ad090204031200c405500138e210000
                18000000000000000000000000000002

About VGA, the binary edid is 0 bit, and I can't grab EDID by using "xrandr --verbose".
Comment 16 Daniel Vetter 2013-07-22 08:47:05 UTC
(In reply to comment #15)
> About VGA, the binary edid is 0 bit, and I can't grab EDID by using "xrandr
> --verbose".

But apparently you have a mod list for VGA ... Can you please double-check? Please also check in /sys/class/drm/*/edid in case X is eating the edid.

If the edid isn't there for VGA I think we need to file a 2nd bug for this screen on haswell+vga.
Comment 17 cancan,feng 2013-07-22 09:07:23 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > About VGA, the binary edid is 0 bit, and I can't grab EDID by using "xrandr
> > --verbose".
> 
> But apparently you have a mod list for VGA ... Can you please double-check?
> Please also check in /sys/class/drm/*/edid in case X is eating the edid.
> 
> If the edid isn't there for VGA I think we need to file a 2nd bug for this
> screen on haswell+vga.

You are right..
EDID of VGA:
                00ffffffffffff004d77010001000000
                1c1601031f5d3478ca31c3a3554a9b24
                10474aafcf0001010101010101010101
                0101010101011a3680a070381f403020
                3500a20b3200001a000000fd0032551f
                460f000a202020202020000000fc0053
                6b79776f727468205548440a00000010
                0053563432325856540a2020202000ee
Comment 18 cancan,feng 2013-07-22 09:07:59 UTC
Created attachment 82809 [details]
card0-VGA-1
Comment 19 Daniel Vetter 2013-07-22 10:20:31 UTC
Can you please try what happens when you manually add the mode:

$ xrandr --newmode "3840x2160_60.00"  712.34  3840 4152 4576 5312  2160 2161 2164 2235  -HSync +Vsync
$ xrandr --addmode HDMI2 "3840x2160_60.00"
$ xrandr --output HDMI2 --mode "3840x2160_60.00"

You need to test this with the patch v3 otherwise the kernel will reject the mode when you try to use it.
Comment 20 Daniel Vetter 2013-07-22 10:23:24 UTC
If the first one doesn't work please also try the --newmode/--addmode sequence with this modeline:

"3840x2160_25.00"  278.70  3840 4056 4464 5088  2160 2161 2164 2191  -HSync +Vsync
Comment 21 cancan,feng 2013-07-23 01:15:21 UTC
(In reply to comment #19)
> Can you please try what happens when you manually add the mode:
> 
> $ xrandr --newmode "3840x2160_60.00"  712.34  3840 4152 4576 5312  2160 2161
> 2164 2235  -HSync +Vsync
> $ xrandr --addmode HDMI2 "3840x2160_60.00"
> $ xrandr --output HDMI2 --mode "3840x2160_60.00"
> 
> You need to test this with the patch v3 otherwise the kernel will reject the
> mode when you try to use it.

[root@x-hsw24 ~]# xrandr --newmode "3840x2160_60.00"  712.34  3840 4152 4576 5312  2160 2161 2164 2235  -HSync +Vsync
[root@x-hsw24 ~]# xrandr --addmode HDMI2 "3840x2160_60.00"
[root@x-hsw24 ~]# xrandr --output HDMI2 --mode "3840x2160_60.00"
xrandr: Configure crtc 0 failed
[root@x-hsw24 ~]#

This mode doesn't work out, it will give warning like "xrandr: Configure crtc 0 failed".
Comment 22 cancan,feng 2013-07-23 01:19:49 UTC
(In reply to comment #20)
> If the first one doesn't work please also try the --newmode/--addmode
> sequence with this modeline:
> 
> "3840x2160_25.00"  278.70  3840 4056 4464 5088  2160 2161 2164 2191  -HSync
> +Vsync

Yeah~~This mode can work out!!

HDMI2 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
   1280x720       60.0 +   50.0     59.9
   1920x1080i     60.1     50.0     60.0
   1280x1024      75.0
   1440x576i      50.1
   1024x768       75.1     70.1     60.0
   1440x480i      60.1     60.1
   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
   3840x2160_60.00   60.0
   3840x2160_25.00   25.0*
Comment 23 Daniel Vetter 2013-07-23 05:44:34 UTC
Ok, so with the patch (which is merged into -fixes already) 4k works on Haswell, the only problem we seem to have here is that we can't get the mode from the EDID. And it doesn't work for both the HDMI and the VGA EDID.

Strange.

For reference the dotclock fix is:

commit 363202bb22467ea1de6dd284b78eff5cf517db66
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Jul 22 18:02:39 2013 +0200

    drm/i915: fix hdmi portclock limits
Comment 24 Chris Wilson 2013-07-23 07:12:33 UTC
If Windows works as you say, then grab its. modelines (and EDID). My expectation is that the EDID is the same, but the manufacturer installed a monitor.inf to compenstate for their non-conformant and lackluster EDID.
Comment 25 Damien Lespiau 2013-07-23 17:34:36 UTC
So, in fact, the reason why we don't expose those modes is because we have a small gap in our EDID parsing. The CEA HDMI vendor block has a special list of VICs for the 4k modes that we don't parse yet. I've checked and the edid above does have those bits, it's just a matter of writing the patch now (I'll do it next week as I'm off Wed-Fri)
Comment 26 Daniel Vetter 2013-07-23 18:00:38 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > Just to check: Does the max resolution of 2048x1152 on VGA work on linux?
> 
> No, 2048x1152 doesn't work on linux.

Digging out the VGA topic again. Can you please check in windows what refresh rate is used on Haswell VGA at 2048x1152?
Comment 27 cancan,feng 2013-07-24 03:05:26 UTC
(In reply to comment #24)
> If Windows works as you say, then grab its. modelines (and EDID). My
> expectation is that the EDID is the same, but the manufacturer installed a
> monitor.inf to compenstate for their non-conformant and lackluster EDID.


(In reply to comment #26)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Just to check: Does the max resolution of 2048x1152 on VGA work on linux?
> > 
> > No, 2048x1152 doesn't work on linux.
> 
> Digging out the VGA topic again. Can you please check in windows what
> refresh rate is used on Haswell VGA at 2048x1152?

2048x1152 only has 60 Hertz.
Comment 28 cancan,feng 2013-07-24 03:24:32 UTC
(In reply to comment #24)
> If Windows works as you say, then grab its. modelines (and EDID). My
> expectation is that the EDID is the same, but the manufacturer installed a
> monitor.inf to compenstate for their non-conformant and lackluster EDID.

(In reply to comment #24)
> If Windows works as you say, then grab its. modelines (and EDID). My
> expectation is that the EDID is the same, but the manufacturer installed a
> monitor.inf to compenstate for their non-conformant and lackluster EDID.

I tried some tools to grab HDMI's EDID but can only grab 128 bytes, here I attach:
00FFFFFFFFFFFF00 4D77010001000000 1C160103803C2278 0A0DC9A057479827 12484CBFEF000101 0101010101010101 010101010101011D 007251D01E206E28 5500C48E2100001E 011D8018711C1620 582C2500C48E2100 009E000000FC0053 6B79776F72746820 5548440A000000FD 00314C0F500E000A 20202020202001B1 

VGA's EDID is:
0x00	 00 FF FF FF FF FF FF 00 4D 77 01 00 01 00 00 00	
0x10	 1C 16 01 03 80 3C 22 78 0A 0D C9 A0 57 47 98 27	
0x20	 12 48 4C BF EF 00 01 01 01 01 01 01 01 01 01 01	
0x30	 01 01 01 01 01 01 01 1D 00 72 51 D0 1E 20 6E 28	
0x40	 55 00 C4 8E 21 00 00 1E 01 1D 80 18 71 1C 16 20	
0x50	 58 2C 25 00 C4 8E 21 00 00 9E 00 00 00 FC 00 53	
0x60	 6B 79 77 6F 72 74 68 20 55 48 44 0A 00 00 00 FD	
0x70	 00 31 4C 0F 50 0E 00 0A 20 20 20 20 20 20 01 B1
Comment 29 Daniel Vetter 2013-07-24 06:14:03 UTC
Hm, 2048x1152 @ 60Hz is a bit much for vga on haswell. Still can you please try whether manually adding the mode works?

The modeline would be

"2048x1152_60.00"  197.97  2048 2184 2408 2768  1152 1153 1156 1192  -HSync +Vsync
Comment 30 cancan,feng 2013-07-24 06:40:11 UTC
(In reply to comment #29)
> Hm, 2048x1152 @ 60Hz is a bit much for vga on haswell. Still can you please
> try whether manually adding the mode works?
> 
> The modeline would be
> 
> "2048x1152_60.00"  197.97  2048 2184 2408 2768  1152 1153 1156 1192  -HSync
> +Vsync

This can't work. We get warning like "xrandr: Configure crtc 0 failed".
Comment 31 Damien Lespiau 2013-07-30 14:01:14 UTC
Created attachment 83302 [details] [review]
Parse 4k VICs

Could you try this kernel patch? it parses the HDMI CEA vendor specific block to look for 4k modes.

I noticed that X prunes those modes because their pixel clock is larger than the other detailed modes. It'll have to be fixed at some point.

(II) intel(0): Not using mode "3840x2160" (bad mode clock/interlace/doublescan)

You can however use libdrm's modeprint to check that the modes are exposed by the kernel:

$ ./modeprint i915
Mode: "3840x2160" 3840x2160 30
Mode: "3840x2160" 3840x2160 25
Mode: "3840x2160" 3840x2160 24

I also left printks in this patch:

$ dmesg | grep XXX
[    4.901749] [drm:do_hdmi_vsdb_modes], XXX: Found 3 modes in the HDMI vsdb
[    4.901751] [drm:do_hdmi_vsdb_modes], XXX: Found VIC 1 
[    4.901753] [drm:do_hdmi_vsdb_modes], XXX: Found VIC 2 
[    4.901755] [drm:do_hdmi_vsdb_modes], XXX: Found VIC 3
Comment 32 Chris Wilson 2013-07-30 14:36:33 UTC
(In reply to comment #31) 
> I noticed that X prunes those modes because their pixel clock is larger than
> the other detailed modes. It'll have to be fixed at some point.
> 
> (II) intel(0): Not using mode "3840x2160" (bad mode
> clock/interlace/doublescan)

The EDID does declare a dotclock limit of 300MHz, which is marginally more than required (297MHz). Can you dump the mode as it goes through X and so work out where/why it gets rejected?
Comment 33 Damien Lespiau 2013-07-30 16:43:47 UTC
I'm updating my sandybridge machine to be able to compile an X server easily, will take a while.

At the moment I'm suspecting xf86ProbeOutputModes() that uses xf86ForEachDetailedBlock() to, it seems, compute max_clock from the DS_RANGE sections. On this EDID, we have a GTF range section:

- Monitor ranges (GTF): 49-76Hz V, 15-80kHz H, max dotclock 140MHz

and that ends up being used.

I don't see any evidence that the X server parses the HDMI vendor specific block (other than xf86MonitorIsHDMI()) and that block contains a different max clock:

- Maximum TMDS clock: 300MHz
Comment 34 cancan,feng 2013-07-31 02:18:01 UTC
(In reply to comment #31)
> Created attachment 83302 [details] [review] [review]
> Parse 4k VICs
> 
> Could you try this kernel patch? it parses the HDMI CEA vendor specific
> block to look for 4k modes.
> 
> I noticed that X prunes those modes because their pixel clock is larger than
> the other detailed modes. It'll have to be fixed at some point.
> 
> (II) intel(0): Not using mode "3840x2160" (bad mode
> clock/interlace/doublescan)
> 
> You can however use libdrm's modeprint to check that the modes are exposed
> by the kernel:
> 
> $ ./modeprint i915
> Mode: "3840x2160" 3840x2160 30
> Mode: "3840x2160" 3840x2160 25
> Mode: "3840x2160" 3840x2160 24
> 
> I also left printks in this patch:
> 
> $ dmesg | grep XXX
> [    4.901749] [drm:do_hdmi_vsdb_modes], XXX: Found 3 modes in the HDMI vsdb
> [    4.901751] [drm:do_hdmi_vsdb_modes], XXX: Found VIC 1 
> [    4.901753] [drm:do_hdmi_vsdb_modes], XXX: Found VIC 2 
> [    4.901755] [drm:do_hdmi_vsdb_modes], XXX: Found VIC 3

I tried this patch and I still can't see "3840x2160"..I attached the dmesg with this patch if this is useful for you.
Comment 35 cancan,feng 2013-07-31 02:18:39 UTC
Created attachment 83338 [details]
boot dmesg with patch 83302
Comment 36 Chris Wilson 2013-07-31 07:26:11 UTC
The 38x21 modes are being pulled out of the EDID at least, just being culled by the equivalent santiy checking code in the kernel.
Comment 37 Damien Lespiau 2013-07-31 09:42:41 UTC
As Chris says, the 4k modes are now being pruned by the kernel, do you have

https://patchwork.kernel.org/patch/2831439/

in your tree? You need this for the correct upper limit of HSW HDMI port.
Comment 38 Damien Lespiau 2013-07-31 18:32:13 UTC
Created attachment 83387 [details] [review]
X server patch to look at the TMDS max frequency field from the EDID

Hi,

With this additional patch to the xserver, I can now see the 4k modes with xrandr. I cannot actually test the whole chain as I'm faking having the monitor, but you'll hopefully be able to test it.

So you need in addition of the 2 kernel patches already mentioned:

- This patch to the X server
- The master branch of the DDX driver (a bug fixed in the UXA part of the driver) http://cgit.freedesktop.org/xorg/driver/xf86-video-intel. Or you can just cherry-pick "uxa/display: Keep the EDID blob around for the lifetime of an output"
Comment 39 Chris Wilson 2013-07-31 18:44:35 UTC
Perhaps X_PROBED rather than X_INFO for the TMDS frequency?
Comment 40 Damien Lespiau 2013-07-31 19:32:11 UTC
Hum., that was a debug printf left there so we can easily make sure QA has all the right patches. I guess it's useful anyway, so will pimp it up in the final patch.
Comment 41 cancan,feng 2013-08-01 05:10:23 UTC
(In reply to comment #40)
> Hum., that was a debug printf left there so we can easily make sure QA has
> all the right patches. I guess it's useful anyway, so will pimp it up in the
> final patch.

Hi, this can work now !! There are three new modes showed:

[1]  3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 0x5 0x40 297000
[2]  3840x2160 25 3840 4896 4984 5280 2160 2168 2178 2250 0x5 0x40 297000
[3]  3840x2160 24 3840 5096 5184 5480 2160 2168 2178 2250 0x5 0x40 297000

These new modes all can display correctly. :) So, close the bug?
Comment 42 Damien Lespiau 2013-08-01 07:19:24 UTC
Just to confirm, did you test all the way with X running and xrandr (or the gnome display settings applet)?
Comment 43 cancan,feng 2013-08-07 03:08:38 UTC
(In reply to comment #42)
> Just to confirm, did you test all the way with X running and xrandr (or the
> gnome display settings applet)?

In X running, I need to add the mode "3840x2160_25.00" manually, I do some tests about X and it looks fine.

Gnome display overscan at mode "3840x2160_25.00", I can't see the gnome panel in the top of the window. I take a screenshot of this. And I also take a screenshot of rotation inverted, you can see the difference.
Comment 44 cancan,feng 2013-08-07 03:10:11 UTC
Created attachment 83745 [details]
gnome overscan
Comment 45 cancan,feng 2013-08-07 03:11:16 UTC
Created attachment 83746 [details]
gnome rotation inverted
Comment 46 Damien Lespiau 2013-08-07 07:19:18 UTC
The goal is that we shouldn't have to add the mode line manually :)

Have you applied the DDX patch (having current master is fine) and xserver patch? if yes can you attach the Xorg.log again to see what happens with those modes?

Thanks
Comment 47 cancan,feng 2013-08-07 08:24:32 UTC
(In reply to comment #46)
> The goal is that we shouldn't have to add the mode line manually :)
> 
> Have you applied the DDX patch (having current master is fine) and xserver
> patch? if yes can you attach the Xorg.log again to see what happens with
> those modes?
> 
> Thanks

I didn't apply the DDX patch before, sorry. Now I apply the DDX patch ,X server patch and kernel patch, here is xrandr info:

HDMI2 connected 1280x720+0+0 (normal left inverted right x axis y axis) 708mm x
398mm
   1280x720       60.0*+   50.0     59.9
   3840x2160      30.0     25.0     24.1
   1920x1080      60.0     50.0     59.9
   1920x1080i     60.1     50.0     60.0
   1280x1024      75.0
   1440x576i      50.1
   1024x768       75.1     70.1     60.0
   1440x480i      60.1     60.1
   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

We can see 3840x2160 already in. :) Gnome displays well at this mode, the top panel is showed as well: 3840x2160_30.0_scrot.png
Comment 48 cancan,feng 2013-08-07 08:25:55 UTC
Created attachment 83761 [details]
gnome 3840x2160@30.0
Comment 49 Damien Lespiau 2013-08-07 18:42:46 UTC
Great, thanks for testing. The patches will hopefully find their way in their respective trees.

I wrote a summary of what still needs to land on dri-devel:

http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html
Comment 50 Daniel Vetter 2013-08-07 20:44:26 UTC
We tend to keep bugs open until all the patches are merged - stuff gets lost otherwise.
Comment 51 Jani Nikula 2013-10-11 08:10:21 UTC
(In reply to comment #49)
> Great, thanks for testing. The patches will hopefully find their way in
> their respective trees.
> 
> I wrote a summary of what still needs to land on dri-devel:
> 
> http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html

Damien, what's the status of TODO items? Are we getting closer to closing this bug?
Comment 52 Damien Lespiau 2013-10-12 10:05:33 UTC
Everything but the x server patches has been pushed. Procrastinating on that last part.
Comment 53 Damien Lespiau 2013-12-16 15:30:11 UTC
Sent a v3 of the X server series with a fix to a bug Chris spotted:
  http://lists.x.org/archives/xorg-devel/2013-December/039671.html
Comment 54 Qingshuai Tian 2013-12-17 08:51:56 UTC
Created attachment 90869 [details]
dmesg of new round test with latest kernel and X11R7

I finished a round of testing with the latest drm-intel-nightly kernel(f0404e) and the latest X11R7.
The I-G-T/testdisplay case can list the 3840x2160 mode and all 3840x2160 mode can display normally. All the modes are as follows:
[0]  1280x720 60 1280 1390 1430 1650 720 725 730 750 0x5 0x48 74250
[1]  3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 0x5 0x40 297000
[2]  3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 0x5 0x40 296704
[3]  3840x2160 25 3840 4896 4984 5280 2160 2168 2178 2250 0x5 0x40 297000
[4]  3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 0x5 0x40 297000
[5]  3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 0x5 0x40 296704
[6]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148500
[7]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148352
[8]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x15 0x40 74250
[9]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x15 0x40 74176
[10]  1920x1080 50 1920 2448 2492 2640 1080 1084 1089 1125 0x5 0x40 148500
[11]  1920x1080i 50 1920 2448 2492 2640 1080 1084 1094 1125 0x15 0x40 74250
[12]  1280x1024 75 1280 1296 1440 1688 1024 1025 1028 1066 0x5 0x40 135000
[13]  1280x720 60 1280 1390 1430 1650 720 725 730 750 0x5 0x40 74176
[14]  1280x720 50 1280 1720 1760 1980 720 725 730 750 0x5 0x40 74250
[15]  1440x576i 50 1440 1464 1590 1728 576 580 586 625 0x101a 0x40 27000
[16]  1024x768 75 1024 1040 1136 1312 768 769 772 800 0x5 0x40 78800
[17]  1024x768 70 1024 1048 1184 1328 768 771 777 806 0xa 0x40 75000
[18]  1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000
[19]  1440x480i 60 1440 1478 1602 1716 480 488 494 525 0x101a 0x40 27027
[20]  1440x480i 60 1440 1478 1602 1716 480 488 494 525 0x101a 0x40 27000
[21]  832x624 75 832 864 928 1152 624 625 628 667 0xa 0x40 57284
[22]  800x600 75 800 816 896 1056 600 601 604 625 0x5 0x40 49500
[23]  800x600 72 800 856 976 1040 600 637 643 666 0x5 0x40 50000
[24]  800x600 60 800 840 968 1056 600 601 605 628 0x5 0x40 40000
[25]  800x600 56 800 824 896 1024 600 601 603 625 0x5 0x40 36000
[26]  720x576 50 720 732 796 864 576 581 586 625 0xa 0x40 27000
[27]  720x480 60 720 736 798 858 480 489 495 525 0xa 0x40 27027
[28]  720x480 60 720 736 798 858 480 489 495 525 0xa 0x40 27000
[29]  640x480 75 640 656 720 840 480 481 484 500 0xa 0x40 31500
[30]  640x480 73 640 664 704 832 480 489 491 520 0xa 0x40 31500
[31]  640x480 67 640 704 768 864 480 483 486 525 0xa 0x40 30240
[32]  640x480 60 640 656 752 800 480 490 492 525 0xa 0x40 25200
[33]  640x480 60 640 656 752 800 480 490 492 525 0xa 0x40 25175
[34]  720x400 70 720 738 846 900 400 412 414 449 0x6 0x40 28320

But xrandr still cannot list the 3840x2160 mode normally .
It shows:
HDMI2 connected 1280x720+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
   1280x720       60.0*+   50.0     59.9
   1920x1080i     60.1     50.0     60.0
   1280x1024      75.0
   1440x576i      50.1
   1024x768       75.1     70.1     60.0
   1440x480i      60.1     60.1
   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

On my side building X server blocked by one Bug 71241 so we only use the (master) xorg-server-1.14.99.3-31-g264fc3abe5f18341d0cf9ddb6766e10e4154e447

I checked the xserver, but can't find any commit corresponding to the patches in Comment 53. Damien, does this patch already pushed to upstream?
Comment 55 Damien Lespiau 2013-12-17 11:10:26 UTC
The series I pointed to in comment #54 still needs to be upstreamed. Your log shows the kernel parses the 4k modes correctly but you also need that x server series for xrandr to display them. Aat the moment the X server decides the mode goes beyond what the screen can display because it's not fully parsing the EDID.
Comment 56 Damien Lespiau 2014-01-15 16:36:50 UTC
One step further, xserver series reviewed and submitted for real:

http://lists.x.org/archives/xorg-devel/2014-January/039861.html
Comment 57 Damien Lespiau 2014-01-22 21:06:08 UTC
The X server series has been merged \o/
Comment 58 Qingshuai Tian 2014-01-23 08:58:34 UTC
Created attachment 92647 [details]
dmesg with fixed kernel and X server

Verified.Fixed.

Tested with latest nightly kernel(83ac01) and X server,the bug has been fixed.
The xrandr shows:
Screen 0: minimum 320 x 200, current 1280 x 720, maximum 32767 x 32767
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 connected 1280x720+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
   1280x720       60.0*+   50.0     59.9
   3840x2160      30.0     25.0     24.0     30.0     24.0
   1920x1080      60.0     50.0     59.9
   1920x1080i     60.1     50.0     60.0
   1280x1024      75.0
   1440x576i      50.1
   1024x768       75.1     70.1     60.0
   1440x480i      60.1     60.1
   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
DP1 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

You can check the dmesg in attachment.
Comment 59 Elizabeth 2017-10-06 14:44:59 UTC
Closing old verified.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.