Created attachment 60932 [details]
dmesg with Zotac 'displayport-to-dual-hdmi' adapter - screens stay blank.
Created attachment 60933 [details]
dmesg with Siig 'displayport-to-single-hdmi' adapter - works.
This is a might strange modeline: [ 10.542088] [drm:drm_mode_debug_printmodeline], Modeline 44:"3840x1080" 60 277540 3840 3928 3972 4120 1080 1084 1089 1125 0x48 0x5 Can you please attach a xrandr --verbose with the broken/working config? Also some more diagnostics are available from http://cgit.freedesktop.org/~danvet/drm-intel #drm-intel-next-queued The unusual 3840x1080 resolution is to be expected. Look for 'link_train' in the dmesg log with the Zotac adapter. Looks odd to me. I'm providing the xrandr output as requested - also a screenshot of the Ubuntu Displaysettings with the Zotac adapter. It looks exactly as it should - except that the screen stays blank. Created attachment 60937 [details]
xrandr --verbose for broken 'Displayport-to-dual-hdmi' setup
Created attachment 60938 [details]
xrandr --verbose for working native Displayport monitor.
Created attachment 60939 [details]
Screenshot of Displaysettings in Ubuntu - looks good, but Displayport screen stays blank!
So things work in Windows on that same machine? Our HDMI has clock limits so I didn't think it would support modes that high, but maybe it's using DP to signal to the dongle, then converts internally to HDMI? Ok yeah, the xrandr confirms that. So we ought to be able to drive 3840x1080 on DP just fine... Yes, it works with Windows 7 on that very same machine. And yes, it is using DP to signal between the computer and the dongle. The dongle then converts the signal into two regular 1920x1080 HDMI signals while presenting a single 3840x1080 screen on the DP side. Quite ingenious actually - as I said, it's Xinerama done in hardware! This is what strikes me as strange: dmesg with the working 'native' DP monitor: [ 5.127097] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [ 5.127810] [drm:intel_dp_start_link_train], clock recovery OK dmesg with the broken 'dp-to-dual-hdmi' adapter: [ 4.900133] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [ 4.900948] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [ 4.901763] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [ 4.902578] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [ 4.903392] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [ 4.904207] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [ 4.905021] [drm:intel_dp_start_link_train], too many voltage retries, give up Is there any progress being made on this or anything I can provide/test to help? I just received a similar adapter today and get the same behaviour. xrandr reports the 1920x1080 or 3840x1080 depending on if I have just one or two monitors plugged in the adapter, but both remain off. Connecting a single adapter using a standard DP => HDMI adapter works fine. I'm testing on Ubuntu 12.10 with xserver-xorg-video-intel 2:2.20.3-0ubuntu1 and a 3.5.0-13-generic kernel. That's on a Lenovo x230 with an HD4000. (In reply to comment #11) > Is there any progress being made on this or anything I can provide/test to > help? I have a ZOTAC mini-DisplayPort to Dual HDMI Adaptor ZT-MDP2HD, and I can reproduce the problem. Taking bug. New kernel (3.7), time to test. Thanks! Unfortunately still no success for me... Same as before, screens stay blank. Hello Jani, did you have a chance to look at this already? Unfortunately it seems there hasn't been any progress so far. Same for me. Two LG IPS235 panels (1920x1080) connected via HDMI to the Zotac ZT-MDP2HD. Hardware is a Lenovo X1 carbon with: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (via Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz) xrandr --verbose is here: https://nblr.de/xrandr-verbose-zotac-x1 Kernel is Ubuntu/Mint 3.5.0-26-generic Works like a charm and out of the box with current intel hd4000 video drivers in Windows 7. I tried a few random things for this on IVB. - tried to send the training pattern and training lane set with one aux write instead of two. - tried to disable enhanced framing - tried to force some voltage swing/pre-emphasis values - tried with 6 bpc so that we'd get 1.62 links speed instead of 2.7 - tried to send post cursor2 traning values in case that would trick the sink into cooperation Unfortunately none of that helped. The BIOS produces a picture with the dongle, so I tried to compare some of the register values. The main differences I saw were that the BIOS uses auto training for FDI, some of the M/N values were different, and of course the BIOS also has panel fitter active since it's using a 720x400 resolution. On Tue, 16 Apr 2013 09:50:53 +0000 bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=49402 > > --- Comment #17 from Ville Syrjala <ville.syrjala@linux.intel.com> --- > I tried a few random things for this on IVB. > > - tried to send the training pattern and training lane set with one aux write > instead of two. > - tried to disable enhanced framing > - tried to force some voltage swing/pre-emphasis values > - tried with 6 bpc so that we'd get 1.62 links speed instead of 2.7 > - tried to send post cursor2 traning values in case that would trick the sink > into cooperation > > Unfortunately none of that helped. > > The BIOS produces a picture with the dongle, so I tried to compare some of the > register values. The main differences I saw were that the BIOS uses auto > training for FDI, some of the M/N values were different, and of course the BIOS > also has panel fitter active since it's using a 720x400 resolution. The m/n values could definitely be a factor. Maybe our DP values are slightly off and causing some skew in the dongle? (In reply to comment #18) > On Tue, 16 Apr 2013 09:50:53 +0000 > bugzilla-daemon@freedesktop.org wrote: > > > https://bugs.freedesktop.org/show_bug.cgi?id=49402 > > > > --- Comment #17 from Ville Syrjala <ville.syrjala@linux.intel.com> --- > > I tried a few random things for this on IVB. > > > > - tried to send the training pattern and training lane set with one aux write > > instead of two. > > - tried to disable enhanced framing > > - tried to force some voltage swing/pre-emphasis values > > - tried with 6 bpc so that we'd get 1.62 links speed instead of 2.7 > > - tried to send post cursor2 traning values in case that would trick the sink > > into cooperation > > > > Unfortunately none of that helped. > > > > The BIOS produces a picture with the dongle, so I tried to compare some of the > > register values. The main differences I saw were that the BIOS uses auto > > training for FDI, some of the M/N values were different, and of course the BIOS > > also has panel fitter active since it's using a 720x400 resolution. > > The m/n values could definitely be a factor. Maybe our DP values are > slightly off and causing some skew in the dongle? It seems you are right. I just tried to hardcode the M/N values to the ones used by the BIOS, and now I get a picture on the screen. I'll just list the values here and hope someone else will figure out what code changes are needed to produce the working values ;) TU = 64 for both data M/N: BIOS: 62ae4e / 800000 i915: 65a360 / 83d600 link M/N: BIOS: 83931 / 80000 i915: 43c24 / 41eb0 The DP link training still "fails" the same way. It tries CR five times w/ vswing=0 and pre-emphasis=0 before giving up, and then goes on to the EQ phase which succeeds immediately. But the CR failure doesn't seem to prevent it from working. OK I lied. I did spend a few moments thinking about the issue a bit more. The BIOS N values are power of two. So assuming that power of two values are somehow better, perhaps we can adjust the calculated M/N values a bit. Something like this perhaps: new_n = min(roundup_pow_of_two(n), 1 << 23); new_m = m * new_n / n; Created attachment 78330 [details] [review] Possible fix This patch makes my Zotac donle + Samsung telly work. I have no idea whether it breaks some other displays though. Kudos for making it work with your hardware - I tried your patch with Linux 3.8.0-19-generic / Ubuntu 13.04, but unfortunately it doesn't work for me. I can verify that your patch produces the same M/N values as your BIOS, but unfortunately my screens (2x Dell U2312) stay blank. Did you change anything else by any chance? How did you figure out what values your BIOS uses? On the plus side - your patch does not seem to break support for my native Displayport monitor (Dell U2711) either. That one still works! I tried to pry open the Zotac adapter. It's based on an IDT VMM1402 chip, if that's of any help... (In reply to comment #22) > Kudos for making it work with your hardware - I tried your patch with Linux > 3.8.0-19-generic / Ubuntu 13.04, but unfortunately it doesn't work for me. I > can verify that your patch produces the same M/N values as your BIOS, but > unfortunately my screens (2x Dell U2312) stay blank. > > Did you change anything else by any chance? You could try the drm-intel-nightly branch from [1]. It contains Ville's patch, and many many other changes. > How did you figure out what values your BIOS uses? Does the adapter work for you through BIOS? I.e. do you see stuff on screen before the kernel loads? If yes, you could prevent the i915 driver from loading (to make sure it doesn't mess with the registers), boot to console, and run intel_reg_dumper from the intel-gpu-tools [2] package. [1] git://people.freedesktop.org/~danvet/drm-intel [2] git://git.freedesktop.org/git/xorg/app/intel-gpu-tools Jani, confirming this is an issue on the HD4000 series as well - Lenovo Carbon X1. Please let me know what further information is needed - however I would be testing from a liveUSB setup as I don't have a *nix install on the internal drive yet. I'm also willing to ship a Zotac DP->Dual HDMI adapter to someone if you think it'd help them fix the bug. (In reply to comment #25) > Please let me know what further information is needed - however I would be > testing from a liveUSB setup as I don't have a *nix install on the internal > drive yet. Please see comment #24. > I'm also willing to ship a Zotac DP->Dual HDMI adapter to someone if you > think it'd help them fix the bug. Thanks for the offer, we've got one. Created attachment 86402 [details] [review] drm/i915: don't write training pattern set if it doesn't change I had a look at this again. Here's a patch that fixes clock recovery (part of link training) for me. It's on top of drm-intel-nightly branch of [1]. I don't know if it does the right thing or whether it's strictly per the DP spec, but it's worth a try. Please report whether it works for you. Also available at dp-training-pattern branch of [2]. [1] git://people.freedesktop.org/~danvet/drm-intel [2] git://gitorious.org/jani/drm.git Created attachment 86720 [details] [review] drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time Please try the attached patch. Works for me. Presumed fixed by commit 70aff66c953054334bf0569696901c13e206ade6 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 27 15:10:44 2013 +0300 drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time We've fixed a number of display port link training issues, including the one above, and the Zotac adapter now works for me without problems running drm-intel-nightly branch of [1]. Please reopen if the problem persists running drm-intel-nightly. If there is interest in getting this backported to stable kernels, please try a v3.12-rc kernel, cherry-pick the above commit on top (it applies cleanly), and report your Tested-by: if it works. Thanks. [1] git://people.freedesktop.org/~danvet/drm |
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.
Created attachment 60931 [details] dmesg with Dell U2711 native Displayport monitor - works! Hello, I have tried this on a Lenovo T410 with Intel HD2000 graphics and on a Lenovo T420s with Intel HD3000 graphics: both were running a fresh installation of Ubuntu 12.04 and the results were identical: I have three different Displayport devices to test this with: a) A Dell U2711 monitor with a 'true' Displayport input. Works! b) A Siig 'Displayport-to-HDMI' adapter connected to a Dell U2312 monitor. Works! c) A Zotac 'Displayport-to-dual-HDMI' adapter connected to two Dell U2312 monitors. This does not work - the screens stay blank! FYI, the Zotac adapter pretty much does 'cinerama' in hardware. It takes the two attached HD monitors and presents a single 3840x1080 screen on the Displayport. It works great under Windows (and needs no special driver), but not with Linux. I am attaching dmesg logs for all three scenarios above from a powerup with drm.debug=0xe kernel parameter. I can't claim that I understand everything that's going on, but by comparing the logs, it seems to me that the problem is with the link training of the Zotac adapter. Any help would be greatly appreciated - if it's required, I'm more than happy to send the Zotac adapter to a developer for debugging. Thanks a lot! Wolf