| 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/Intel | Assignee: | 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
cancan,feng
2013-07-18 08:58:45 UTC
Created attachment 82577 [details]
machine boot info
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. Haswell actually does support HDMI1.4 ... it's just not implemented. Created attachment 82766 [details] [review] fix hdmi port clock limits on haswell Please test the attached patch. Created attachment 82769 [details] [review] fix hdmi port clock limits on haswell v2 Oops, this is the right thing. (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. Created attachment 82796 [details]
system boot info with patch
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. (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 (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? (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 (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. 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? Created attachment 82805 [details]
card0-HDMI-A-2
(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". (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. (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 Created attachment 82809 [details]
card0-VGA-1
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. 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 (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". (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* 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 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. 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) (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? (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. (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 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 (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". 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 (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? 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 (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. Created attachment 83338 [details]
boot dmesg with patch 83302
The 38x21 modes are being pulled out of the EDID at least, just being culled by the equivalent santiy checking code in the kernel. 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. 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" Perhaps X_PROBED rather than X_INFO for the TMDS frequency? 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. (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? Just to confirm, did you test all the way with X running and xrandr (or the gnome display settings applet)? (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. Created attachment 83745 [details]
gnome overscan
Created attachment 83746 [details]
gnome rotation inverted
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 (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 Created attachment 83761 [details] gnome 3840x2160@30.0 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 We tend to keep bugs open until all the patches are merged - stuff gets lost otherwise. (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? Everything but the x server patches has been pushed. Procrastinating on that last part. 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 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? 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. One step further, xserver series reviewed and submitted for real: http://lists.x.org/archives/xorg-devel/2014-January/039861.html The X server series has been merged \o/ 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.
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.