| Summary: | MegaChips MCDP2800 LSPCON and ASRock Fatal1ty Z170 Gaming-ITX/ac issues (Broadcast RGB, HDMI output, triple monitor not working) | ||
|---|---|---|---|
| Product: | DRI | Reporter: | bz |
| Component: | DRM/Intel | Assignee: | Manasi <manasi.d.navare> |
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | fritsch, imre.deak, intel-gfx-bugs, jani.nikula, shashank.sharma, ville.syrjala |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | SKL | i915 features: | display/LSPCON |
| Attachments: | |||
Result of inxi -F
System: Host: Mini-PC Kernel: 4.5.0-040500rc5-generic x86_64 (64 bit) Desktop: Xfce 4.12.3
Distro: Ubuntu 15.10 wily
Machine: Mobo: ASRock model: Z170 Gaming-ITX/ac serial: M80-58013100295
Bios: American Megatrends v: P1.80 date: 01/27/2016
CPU: Quad core Intel Core i7-6700 (-HT-MCP-) cache: 8192 KB
clock speeds: max: 4000 MHz 1: 1418 MHz 2: 800 MHz 3: 3700 MHz 4: 3407 MHz 5: 830 MHz 6: 813 MHz
7: 955 MHz 8: 3800 MHz
Graphics: Card: Intel Sky Lake Integrated Graphics
Display Server: X.org 1.17.2 drivers: intel (unloaded: fbdev,vesa)
tty size: 130x30 Advanced Data: N/A for root
Audio: Card-1 Intel Sunrise Point-H HD Audio driver: snd_hda_intel Sound: ALSA v: k4.5.0-040500rc5-generic
Card-2 Plantronics driver: USB Audio
Network: Card-1: Intel Ethernet Connection (2) I219-V driver: e1000e
IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: d0:50:99:84:34:51
Card-2: Broadcom BCM4352 802.11ac Wireless Network Adapter driver: bcma-pci-bridge
IF: N/A state: N/A mac: N/A
Drives: HDD Total Size: 756.2GB (68.1% used) ID-1: /dev/sda model: Samsung_SSD_850 size: 256.1GB
ID-2: /dev/sdb model: WDC_WD5000LPLX size: 500.1GB
Partition: ID-1: / size: 204G used: 136G (71%) fs: ext4 dev: /dev/sda1
ID-2: swap-1 size: 34.03GB used: 0.00GB (0%) fs: swap dev: /dev/sda5
RAID: No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors: System Temperatures: cpu: 53.0C mobo: N/A
Fan Speeds (in rpm): cpu: N/A
Info: Processes: 240 Uptime: 2:10 Memory: 2030.9/31863.7MB Client: Shell (sudo) inxi: 2.2.16
Created attachment 121890 [details]
xrandr --verbose
I've just noticed that according to xrandr, I have TWO DP and ONE HDMI connection. This is wrong. I have ONE DP and TWO HDMI connections. Here are the specs from Asus http://www.asrock.com/mb/Intel/Fatal1ty%20Z170%20Gaming-ITXac/ ASRock Super Alloy Gaming Armor - CPU Power / Memory / VGA Card / Cooling / Internet Digi Power, 8 Power Phase design Supports 6th Generation Intel® Core™ Processors (Socket 1151) Supports DDR4 4000+(OC) memory modules 1 PCIe 3.0 x16, 1 Half-size Mini-PCIe Graphics Output Options: 2 HDMI, DisplayPort 1.2 Supports Triple Monitor 7.1 CH HD Audio (Realtek ALC1150 Audio Codec), Supports Purity Sound™ 3 & DTS Connect *snip* (In reply to bz from comment #3) > I've just noticed that according to xrandr, I have TWO DP and ONE HDMI > connection. > > This is wrong. > > I have ONE DP and TWO HDMI connections. Please add drm.debug=14 module parameter, and attach dmesg again, all the way from boot to the desktop. Let's see what the driver really thinks. If you mean drm.debug=0xe then I have already added that to /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="drm.debug=0xe" Created attachment 121892 [details]
dmesg with drm.debug=14 enabled
now i have a endless loop and my fan is running constantly (In reply to bz from comment #5) > If you mean drm.debug=0xe then I have already added that to > /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="drm.debug=0xe" That's not present in the logs you've attached: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.5.0-040500rc5-generic root=UUID=b40e94c4-e405-406c-af72-586f06f4f7cd ro quiet splash vt.handoff=7 and there are no debug messages in the logs. (In reply to bz from comment #7) > now i have a endless loop and my fan is running constantly I have no idea what those errors are about. Created attachment 121893 [details]
dmesg.txt drm.debug=14 enabled
Hi, sorry I did add the correct line to /etc/default/grub but I forgot to run update-grub *facepalm* :-) I've now attached the correct file and deleted the two older ones. (In reply to bz from comment #3) > I've just noticed that according to xrandr, I have TWO DP and ONE HDMI > connection. > > This is wrong. > > I have ONE DP and TWO HDMI connections. Seems like you have one DP, one DP-MST, and one HDMI, from the driver POV. If the chassis has two HDMI, one of the DP-MST ones must have on-board converter to HDMI. (In reply to Jani Nikula from comment #11) > (In reply to bz from comment #3) > > I've just noticed that according to xrandr, I have TWO DP and ONE HDMI > > connection. > > > > This is wrong. > > > > I have ONE DP and TWO HDMI connections. > > Seems like you have one DP, one DP-MST, and one HDMI, from the driver POV. > > If the chassis has two HDMI, one of the DP-MST ones must have on-board > converter to HDMI. I see the bug status is still set to 'need info'. Do you need any further information from me? Still the same with 4.5 rc6. Would be nice if someone from Intel answered my questions.....!! *** Bug 94425 has been marked as a duplicate of this bug. *** Is this: http://www.newegg.com/Product/Product.aspx?Item=N82E16813157650 the same motherboard you're using? (In reply to dog from comment #15) > Is this: http://www.newegg.com/Product/Product.aspx?Item=N82E16813157650 the > same motherboard you're using? Yes, that's the one Could you boot the motherboard and then hotplug the monitors into all three connectors and resend the dmesg log? I want to take a look at the log and see what connector type gets detected at each hotplug Created attachment 122205 [details]
Dmesg with monitors hotplugged as requested
(In reply to Manasi from comment #17) > Could you boot the motherboard and then hotplug the monitors into all three > connectors and resend the dmesg log? I want to take a look at the log and > see what connector type gets detected at each hotplug I rebooted the computer with only monitor one attached. I then hotplugged monitor two (which was detected and could be used) and then hotplugged monitor three (which was detected but could not be used) Monitor two was attached to an HDMI port but seems to be detected as DP No change with Kernel 4.5. Would be nice if you gave this a higher priority than medium. I've had this bug for months now and I'd like to use three monitors sooner rather than later Any updates on this? Still nothing? Anyone actually CARE about this...????????? Hi, yes we are working on some kernel patches to address the issue. This work is in progress. Meanwhile I have ordered the ASUS motherboard so that I can test the kernel fix to ensure that the issue is fixed on my side. (In reply to Manasi from comment #23) > Hi, yes we are working on some kernel patches to address the issue. This > work is in progress. > Meanwhile I have ordered the ASUS motherboard so that I can test the kernel > fix to ensure that the issue is fixed on my side. Thank you for the update Manasi. Any progress updates Manasi? Possible patches anytime soon? JUST WHAT THE F*** DO I HAVE TO DO TO GET AN ANSWER FROM YOU GUYS??????????????????????????????? (In reply to bz from comment #26) > JUST WHAT THE F*** DO I HAVE TO DO TO GET AN ANSWER FROM YOU > GUYS??????????????????????????????? I understand your frustration, but please remain civil. If xrandr says 2*DP + HDMI but your chassis has 1*DP + 2*HDMI, you've got an internal DP to HDMI converter. Specifically, looks like a DP MST device. Seeing that HDMI 2.0 resolutions (4k@60Hz) are being advertized for your motherboard, but your GPU does not support HDMI 2.0 natively, this is not surprising. DP MST still has plenty of rough edges all around Linux, not just Intel graphics, and fixes are flowing in all the time. There are also fixes flowing in for various DP-to-whatever downstream devices. All of the above is DP MST in general and DP converters in general, and your use case is HDMI 2.0 bridge and triple displays, specifically, and I don't think they're trivial either. That said, does the HDMI display on the DP MST to HDMI port work on its own? You could try drm-intel-nightly branch of [1], report back, and attach dmesg with drm.debug=14 module parameter set. [1] http://cgit.freedesktop.org/drm-intel I asked a civil question on 11/05 and noone answered.(Same as noone answered me on 10/04). I understand completely if this is a very complicated techical issue and is going to take a while to fix. What REALLY annoys me is that noone answers my questions when I ask for an update.Would it really have been so difficult to write that 10 days ago? Why up til now do I have to ask twice for further information? Communication to your customers is just as important (actually I would say it is MORE important) as a technical solution. Now, with regards to DP MST a couple of questions... WRT HDMI 2.0 advertising, is there anyway I can change this? Is this a bios issue instead of an Intel Driver issue? "DP MST still has plenty of rough edges all around Linux". Ok, fair enough. Where in particular? Is this a kernel problem, motherboard manufacturer problem, driver problem or all three? Yes, if there is only one monitor attached it works both on the DP and HDMI connections. I will try the drm-intel nightly and report back, but I was under the impression that Manasi had ordered my motherboard and was going to be testing it himself. Is this no longer the case? Look, the users just vastly outnumber us developers. For some perspective, I seem to have received 67 bugzilla comments per day, on the average, for the past 30 days, including weekends. Responding here is just a tiny part of what I do. (In reply to bz from comment #28) > WRT HDMI 2.0 advertising, is there anyway I can change this? Is this a bios > issue instead of an Intel Driver issue? No, I mean the marketing material for your motherboard says you have HDMI 2.0 hardware while your GPU doesn't have it, ergo you have a converter. > "DP MST still has plenty of rough edges all around Linux". Ok, fair enough. > Where in particular? Is this a kernel problem, motherboard manufacturer > problem, driver problem or all three? Core DRM and i915. > Yes, if there is only one monitor attached it works both on the DP and HDMI > connections. Please provide dmesg for the case where you have HDMI on the port that xrandr says is DP. > I will try the drm-intel nightly and report back, but I was under the > impression that Manasi had ordered my motherboard and was going to be > testing it himself. Is this no longer the case? Manasi, have you received the motherboard? Ok, so I ran "git clone git://anongit.freedesktop.org/drm-intel". I now seem to have sources for the whole kernel. Is this correct? If not, please tell me the correct git command. Do I have to compile the whole kernel, or is there a way just to compile the updated graphics drivers? (FYI, I'm running Xubuntu 16.04 with kernel 4.6.0) Backporting drivers from one kernel to another is not trivial, you need the whole kernel. Please make sure you use the drm-intel-nightly branch. The expectation here is that you know how to build and configure your kernels. See http://kernelnewbies.org/KernelBuild for help. No no, that's fine. I know how to configure, build and install my own kernel. Just wanted to make sure that the whole kernel was needed. Could you tell me the correct git command? git clone git://anongit.freedesktop.org/drm-intel-nightly gives me the following error fatal: remote error: access denied or repository not exported: /drm-intel-nightly Off the top of my head $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ cd linux $ git remote add drm-intel git://anongit.freedesktop.org/drm-intel $ git fetch drm-intel $ git checkout -t drm-intel/drm-intel-nightly Thanks for that. I'll try it out and post my results... No change so far. Manasi, do you have the motherboard yet for testing? Hi, Yes I do have the ASUS motherboard for my testing here, infact I have tested a few patches that for this fix on your motherboard. I will be doing some more testing this week. Meanwhile, would it be possible for you to find out which lspcon board is present on the ASUS motherboard. It would be great if you could give this information. There is clearly a DP to HDMI board present on the ASUS motherboard that you are using. Would it be possible for you to investigate what is the vendor for that board? I'll certainly try. Excuse my ignorance but are lspcon and DP to HDMI the same thing? Yes it is the same thing. Have been looking a lot in the internet, but I couldn't really find any information. How are patches coming along? (In reply to Manasi from comment #37) > There is clearly a DP to HDMI board present on the ASUS motherboard that you > are using. Would it be possible for you to investigate what is the vendor > for that board? Z170 Skylake mainboards which provide HDMI 2.0 seem to be using the following LSPCON: MegaChips MCDP2800 http://www.megachips.com/products/displayport/MCDP28x0 http://www.megachips.com/products/Data_Brief/MCDP28x0_Databrief.pdf Regards Thank you By the way: (In reply to bz from comment #0) > I have an Asus z170 gaming-itx/ac motherboard which has one dp and two hdmi > connections. There is no "z170 gaming-itx/ac" from ASUS. There's only a Fatal1ty Z170 Gaming-ITX/ac. And it is from ASRock, not from ASUS, see: http://www.asrock.com/mb/Intel/Fatal1ty%20Z170%20Gaming-ITXac/ So, why do you say ASUS when it clearly is from ASRock? Anyway, ASRock even has a firmware update available for the MegaChips MCDP2800 LSPCON on the Fatal1ty Z170 Gaming-ITX/ac, see: http://asrock.pc.cdn.bitgravity.com/TSD/TheGuildofsupporting4kx2k@60Hz.pdf It is available for download from: http://www.asrock.com/mb/Intel/Fatal1ty%20Z170%20Gaming-ITXac/?cat=Download&os=All If you look into the Config.ini of that firmware update tool, you can clearly see that it is updating the firmware of the MegaChips MCDP2800 LSPCON. AFAICT, the firmware can only be upgraded from within Windows though (i.e. not from Linux). Regards Yes, you're correct I should have said ASRock, but if you look at the link I provided I did in fact provide the link to the correct board. I'm using Linux so I can't use that tool but thanks again for your assistance. (In reply to nw9165-3201 from comment #43) > If you look into the Config.ini of that firmware update tool, you can > clearly see that it is updating the firmware of the MegaChips MCDP2800 > LSPCON. And also if you look into the "bin" folder of that firmware update tool, you can also see that it has an updated firmware for the MegaChips MCDP2800 LSPCON on the ASRock Fatal1ty Z170 Gaming-ITX/ac. (In reply to bz from comment #44) > I'm using > Linux so I can't use that tool but thanks again for your assistance. Why not just boot into Windows once just to update the firmware and then boot back into Linux? Regards I don't have and don't want Windows... I can update the BIOS online and I have the most recent version installed (2.10). (In reply to bz from comment #47) > I can update the BIOS online and I have the most recent version installed > (2.10). Have the same mainboard here and updating the BIOS does not update the firmware for the MCDP2800. Got the mainboard in 2016 and it did not have the MCDP2800 firmware v1.36 which is available via the HDMI firmware update tool. The tool tells you which MCDP2800 firmware is currently installed. And it was way older than v1.36. After using the tool (from within Windows) to update the MCDP2800 firmware, the firmware is now at version v1.36. Can't tell you if updating the MCDP2800 firmware to v1.36 makes three monitors working in Linux though. Only got one monitor here. (In reply to nw9165-3201 from comment #48) > Can't tell you if updating the MCDP2800 firmware to v1.36 makes three > monitors working in Linux though. Only got one monitor here. Driver support is required for the LSPCON in most cases. Yes, as I said earlier (I said I had contacted ASUS but I should of course have said ASRock - apologies) they told me that three monitors were working with the windows driver Thanks for this information confirming that it does have MegaChips LSPCON board. I am testing the patches here with the driver support for LSPCON. But the old firmware is possibly causing some issues. I might need to figure out a way to update the firmware version to v1.36. Have you tried updating the firmware on Linux? Don't think there IS a way to update the firmware on Linux. Seems to be Windows only.... (In reply to Manasi from comment #51) > Thanks for this information confirming that it does have MegaChips LSPCON > board. If possible, you can thank me by explaining me how the Broadcast RGB setting can be changed directly upon boot. Your workmates Jani Nikula and Chris Wilson do not seem to be willing to explain it to me, see: https://bugs.freedesktop.org/show_bug.cgi?id=96489 https://bugs.freedesktop.org/show_bug.cgi?id=96501 If you could reply over there and explain it to me I would be grateful. Regards Hi, With the ASRock board that we have here, and with our patches for support of Lspcon Megachips board, the HDMI LSPCON port (HDMI port above the native port) works fie along with the native DP. So two monitors perfectly. However the second HDMI (HDMI port next to native DP) does not work at all with a suspect of port port design. Could you test this specific HDMI port next to native DP port on Windows? This will validate the hypothesis. Hi Manasi, I can confirm that three monitors are working with Windows. The reason I know is that I contacted ASRock about this problem before I opened this bug and ASRock confirmed to me that it was a Linux-only problem and that with windows all three monitor connections were working (In reply to Manasi from comment #51) > But > the old firmware is possibly causing some issues. I might need to figure out > a way to update the firmware version to v1.36. Have you updated the firmware to v1.36 meanwhile? And may I ask why you need to figure out a way to update the firmware? I mean, judging from your email address, you are working at Intel? Intel surely must have a copy and license for Windows lying around somewhere? Then why not just boot into Windows and update the firmware and be done? Or why not just contact ASRock and ask them how to update the firmware from Linux? You work at Intel... can't be that hard to get in touch with board manufacturers which utilize your hardware (Intel Z170)? (In reply to Manasi from comment #54) > Could you test this specific HDMI port next to > native DP port on Windows? This will validate the hypothesis. Sorry, but this really baffles me. Why can't you test this yourself if you work at Intel? It can't be too hard for someone at Intel to boot a PC into Windows? Furthermore, it really baffled me that you didn't know that Z170 Skylake boards which provide HDMI 2.0 are doing this by utilizing the MegaChips MCDP2800 LSPCON. I mean, you work at the source, at Intel, there surely must be a way to gather this info when working at Intel? Also: Is there no communication between the Windows driver team and the Linux driver team at Intel? Why can't you just contact someone on the Windows driver team at Intel and ask him what they are doing to get three monitors working? Maybe he can tell you and then you can do the same in Linux. Regards Generally speaking, installing/booting Windows should not be something that is required or recommended to get Linux working. It should not be part of the solution. Usually, it should also not be part of the debug process to compare to Windows. The drivers are completely different, and developed independently. There has to be thousands of products with Intel CPUs, from a huge number of OEMs with a huge number of chips from other vendors. The Linux driver developers probably have as much idea about what those OEMs do with the CPUs as we have about what you do with the driver and what other software you combine it with. (In reply to Jani Nikula from comment #57) > Generally speaking, installing/booting Windows should not be something that > is required or recommended to get Linux working. We were talking about getting potentially buggy firmware patched with the help of Windows. If the pre v1.36 HDMI firmware is buggy and needs to be updated to v1.36, then it's just the way it is. And if upgrading the HDMI firmware requires Windows because the manufacturer has decided so, then that's also just the way it is (unless you figure out how to make updating the firmware work on Linux). (In reply to Jani Nikula from comment #57) > It should not be part of > the solution. Usually, it should also not be part of the debug process to > compare to Windows. The drivers are completely different, and developed > independently. To me that sounds like "We have absolutely no idea what the completely independent Windows driver team is doing to make three monitors working and we haven't even attempted to ask them since... we work independently from each other." *facepalm* I'd say it probably couldn't hurt to ask the Windows driver team. Maybe they know something about the hardware that you don't. And that's not a shame. But it would be a shame not to ask them. (In reply to Jani Nikula from comment #57)> > There has to be thousands of products with Intel CPUs, from a huge number of > OEMs with a huge number of chips from other vendors. The Linux driver > developers probably have as much idea about what those OEMs do with the CPUs > as we have about what you do with the driver and what other software you > combine it with. By the way: Gigabyte also offers that MegaChips firmware update tool for their Z170 mainboards featuring HDMI 2.0, see "HDMI 2.0 FW Update Tool" over there: http://www.gigabyte.com/support-downloads/Utility.aspx Regards (In reply to nw9165-3201 from comment #58) > (In reply to Jani Nikula from comment #57) > To me that sounds like "We have absolutely no idea what the completely > independent Windows driver team is doing to make three monitors working and > we haven't even attempted to ask them since... we work independently from > each other." > > *facepalm* > > I'd say it probably couldn't hurt to ask the Windows driver team. Maybe they > know something about the hardware that you don't. > > And that's not a shame. But it would be a shame not to ask them. Please understand that this part of the discussion is fruitless because you can come up with whatever hypothesis and post them here, and I can't comment on them one way or another, or disclose how we do stuff here. Please just give it a rest. Don't know how many (if any) changes you've made to the DRM driver up to Kernel 4.7rc4, but I'm now noticing that the HDMI monitor (i.e. the one the driver thinks is connected to DP-2) is going completely black for a second or two (and the HDMI audio is also being interrupted). This might be a separate issue of course, but I thought I'd mention it here just in case. Here's a snip from dmesg... 009.345353] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) [ 4009.345356] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK on first message, retry [ 4009.345604] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) [ 4009.345609] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter i915 gmbus dpb [ 4009.345861] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1) [ 4009.345863] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK on first message, retry [ 4009.346125] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1) [ 4009.346130] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:43:HDMI-A-1] disconnected [ 4009.346154] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:HDMI-A-2] [ 4009.346156] [drm:intel_hdmi_detect] [CONNECTOR:46:HDMI-A-2] [ 4009.470825] [drm:intel_hdmi_detect] HDMI live status down [ 4009.470834] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:HDMI-A-2] disconnected [ 4009.470860] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:52:HDMI-A-3] [ 4009.470864] [drm:intel_hdmi_detect] [CONNECTOR:52:HDMI-A-3] [ 4009.471174] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK for addr: 0050 w(1) [ 4009.471180] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK on first message, retry [ 4009.471468] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK for addr: 0050 w(1) [ 4009.471476] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter i915 gmbus dpd [ 4009.471781] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK for addr: 0040 w(1) [ 4009.471787] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK on first message, retry [ 4009.472089] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK for addr: 0040 w(1) [ 4009.472099] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:52:HDMI-A-3] disconnected ASRock now has released a new v1.48 MCDP2800 LSPCON firmware for the Fatal1ty Z170 Gaming-ITX/ac, see: http://www.asrock.com/mb/Intel/Fatal1ty%20Z170%20Gaming-ITXac/?cat=Download&os=All So, v1.36 is outdated now. It's v1.48 now. Created attachment 124869 [details]
attachment-28404-0.html
I will be out on vacation in Alaska without any email/cellphone access. Please expect the delay in any response.
Regards
Manasi
Hi bz, I have been working on rootcausing this issue. I have been also working with ASRock to understand their HW architecture and which ports have LSPCON (DP to HDMI active dongle). So till now we know for sure that the three ports on ASRock board : 1. Native DP 2. LSPCON Port (Externally HDMI but internally DP with a LSPCON chip for conversion) 3. Still trying to get more clarity on if it is native HDMI or 2nd LSPCON I booted their system in Windows 10 and was able to upgrade the firmware to v2.1 that has support for LSPCON as per talks with ASRock. At the same time we (Intel) are adding support for LSPCON feature in our kernel and the patches are being validated before merging into the kernel. I used these patches from our developer and tested them on ASRock new firmware. With this the second port that LSPCON has been validated and is working to generate a 4K display out. These patches will soon be merged and become part of the Linux kernel after which you can pull them. You will need to upgrade the ASRock firmware and try with the new kernel after they are merged. This should successfully generate output on two monitors (connected to native DP and to the LSPCON port that is HDMI Port located above native DP port). Because of LSPCON feature, you will have no issues with these two ports and they would work cleanly. I am still in talks with ASRock to get clarity on why the third HDMI is not working. The suspect is that the LSPCON chip on that port is not enabled by ASRock in their firmware. Manasi Hi Manasi, Thank you for your update. If I understand you correctly, after updating the firmware and when the kernel has been updated with your new patches I STILL will be unable to use three monitors, but when I use two the ports will be detected as 1 x DP and 1 x HDMI as opposed to now where my system reports 2 x DP. Correct? Hi Bz, Yes that is correct. You should see 1 DP and second one also enumerated as DP but you will see that the kernel configures the LSPCON on this port. Still working on getting your third monitor to work. I will keep you posted. Manasi @ Manasi: Since you are already in contact with ASRock, could you please also ask them if it is possible to upgrade the firmware from Linux instead of having to do it from within Windows? Regards Hi Manasi, Are you making progress on this? Can we expect a fix soon? Hello??? Anyone listening??? The driver support is still being developed. Thank you. Do we have an ETA for this? A month? Three months? Is sometime this year realistic? Hi, I have an Asus UX303UB laptop with a skylake I7-6500U. Ever since I installed linux with 2 external monitors I've been having problems. Some kernels simply crash, some only recognize 2 monitors. The setup is as follows: HDMI-2 @ 1080p DP-1 @ 1024x768 on a mini-DP to VGA dongle eDP-1 @ 3200x1800 on the notebook's screen Currently the most stable kernel that I've used is 4.6.4-301 on fc24. Every kernel I've used after that one has a problem (4.7.2-201, 4.7.3-200, 4.7.4-200, 4.7.5-200). Mostly they don't recognize the DP-1 external monitor. Due to previous kernel version problems, kernel boot options are: nouveau.modeset=0 rd.driver.blacklist=nouveau vconsole.font=latarcyrheb-sun32 dis_ucode_ldr acpi_backlight=none acpi_osi= Let me know if more info is required. Please try https://patchwork.freedesktop.org/series/8024/ on top of drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel (In reply to Jani Nikula from comment #72) > Please try https://patchwork.freedesktop.org/series/8024/ on top of > drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel No joy I'm afraid. Still only 2 monitors. Created attachment 127325 [details]
dmesg using patched kernel 4.8.0+ as per request
Well good news. It now seems to be working. I've been pulling the nightly drm-intel kernels over the last few days (haven't reapplied the patchwork patch) As of an hour or so ago, I now have three monitors working. GREAT! That's a great NEWS! I know LSPCON patches got merged and I bet that made the magic! Manasi (In reply to Joaquin Ruiseco from comment #71) > Hi, I have an Asus UX303UB laptop with a skylake I7-6500U. Ever since I > installed linux with 2 external monitors I've been having problems. Some > kernels simply crash, some only recognize 2 monitors. The setup is as > follows: > > HDMI-2 @ 1080p > DP-1 @ 1024x768 on a mini-DP to VGA dongle > eDP-1 @ 3200x1800 on the notebook's screen > > Currently the most stable kernel that I've used is 4.6.4-301 on fc24. Every > kernel I've used after that one has a problem (4.7.2-201, 4.7.3-200, > 4.7.4-200, 4.7.5-200). Mostly they don't recognize the DP-1 external > monitor. Presumably this DP->VGA issue was fixed by commit 16c83fad79ca912b8b5bbdcb5272794a2be41262 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Oct 3 10:55:16 2016 +0300 drm/i915: Allow DP to work w/o EDID Just tried Kernel 4.8 from latest Ubuntu Zesty daily build and seeing some (new) issues: 1. Using the HDMI port to the left side of the DisplayPort port (which is the HDMI port that is being powered by the MegaChips MCDP2800 LSPCON), Broadcast RGB suddenly is automatically being set to Limited 16:235, even though it's connected to a DVI-D PC monitor via a passive HDMI to DVI-D cable. This is not the case with Kernel 4.4 from Ubuntu Xenial. With Kernel 4.4 from Ubuntu Xenial, it's properly being set to Broadcast RGB Full. So, this seems to be a regression between Kernel 4.4 and Kernel 4.8. 2. Plugging the same monitor with the same cable into the HDMI port above the DisplayPort, the monitor stops receiving a signal once KMS kicks in (it goes blank and goes into standby). Why is that? Could you please fix those issues? (In reply to nw9165-3201 from comment #78) > 1. Using the HDMI port to the left side of the DisplayPort port (which is > the HDMI port that is being powered by the MegaChips MCDP2800 LSPCON), > Broadcast RGB suddenly is automatically being set to Limited 16:235, even > though it's connected to a DVI-D PC monitor via a passive HDMI to DVI-D > cable. This is not the case with Kernel 4.4 from Ubuntu Xenial. With Kernel > 4.4 from Ubuntu Xenial, it's properly being set to Broadcast RGB Full. So, > this seems to be a regression between Kernel 4.4 and Kernel 4.8. The CEA-861-E spec says we must default to limited color range for CEA modes with bpp other than 18. We've probably changed this between 4.4 and 4.8, I don't remember exactly. Whichever we default to will be correct for some people, and wrong for some others. Thus the neutral option is to go by the spec. (In reply to Jani Nikula from comment #79) > The CEA-861-E spec says we must default to limited color range for CEA modes > with bpp other than 18. We've probably changed this between 4.4 and 4.8, I > don't remember exactly. No, that change actually was introduced in 2013 and it's being discussed over there: https://bugzilla.kernel.org/show_bug.cgi?id=94921 So why am I suddenly seeing this regression between 4.4 and 4.8? Maybe a bug? (In reply to Jani Nikula from comment #79) > Whichever we default to will be correct for some > people, and wrong for some others. Thus the neutral option is to go by the > spec. Can you please tell me how I can change the default behavior other than manually setting it via xrandr? I've already asked it in https://bugs.freedesktop.org/show_bug.cgi?id=96501 but nobody answered. Is there any way to change the default behavior? As you can see from the comments in https://bugzilla.kernel.org/show_bug.cgi?id=94921, it's really quite an issue. Especially now, since something seems to have broke between 4.4 and 4.8. try this patch https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/linux/patches/default/linux-999-i915-implement-passthrough-colors.patch maybe some one could merge that :P Created attachment 128374 [details]
attachment-28785-0.html
Hello,
I am on vacation between 06 Dec - 16 Dec with limited Phone and no mail access.
Please expect delay in response.
If this is something urgent, please contact my manager : Indranil, Mukherjee
Regards
Shashank
Also tried it with Fedora Rawhide, running Kernel 4.9. It's still automatically setting Broadcast RGB Limited 16:235, even though it should be Broadcast RGB Full. Again, this worked on Kernel 4.4. What has happened in between? Also: Fedora is using Wayland. On Wayland it does not seem to be possible to adjust Broadcast RGB via xrandr. So, what can a user do here to change Broadcast RGB on Wayland? Tried it with Kernel 4.10 now (4.10-rc2): The HDMI port above the DisplayPort, which never worked before, now works (I guess thanks to the LSPCON patches that have probably landed into Kernel 4.10 now). Using this port, Broadcast RGB is also being properly set to Full. However, the HDMI port to the left side of the DisplayPort is still incorrectly being set to Broadcast RGB Limited 16:235, even though it should be Broadcast RGB Full. On Kernel 4.4, it is properly being set to Broadcast RGB Full, but not on newer Kernels. (In reply to nw9165-3201 from comment #84) > Tried it with Kernel 4.10 now (4.10-rc2): > > The HDMI port above the DisplayPort, which never worked before, now works (I > guess thanks to the LSPCON patches that have probably landed into Kernel > 4.10 now). Using this port, Broadcast RGB is also being properly set to Full. > > However, the HDMI port to the left side of the DisplayPort is still > incorrectly being set to Broadcast RGB Limited 16:235, even though it should > be Broadcast RGB Full. On Kernel 4.4, it is properly being set to Broadcast > RGB Full, but not on newer Kernels. If the mode you are using is a CEA mode, it should default to limited range per the HDMI and CEA specs. This was fixed some time after v4.4. Are there any issues remaining? Can we close the bug? (In reply to Jani Nikula from comment #85) > If the mode you are using is a CEA mode, it should default to limited range > per the HDMI and CEA specs. This was fixed some time after v4.4. Then why does it default to full range on one HDMI port and to limited range on the other HDMI port? (In reply to nw9165-3201 from comment #86) > (In reply to Jani Nikula from comment #85) > > If the mode you are using is a CEA mode, it should default to limited range > > per the HDMI and CEA specs. This was fixed some time after v4.4. > > Then why does it default to full range on one HDMI port and to limited range > on the other HDMI port? Same exact mode used with both ports? If so, then it sounds like there's a bug somewhere. Please attach dmesg w/ drm.debug=0xe that shows the modeset for each of the ports. Created attachment 129140 [details]
dmesg_HDMI_above_DisplayPort
Created attachment 129141 [details]
dmesg_HDMI_left_to_DisplayPort
(In reply to Ville Syrjala from comment #87) > Same exact mode used with both ports? As already mentioned: Same monitor and same cable, just connected to the other HDMI port. (In reply to Ville Syrjala from comment #87) > Please attach dmesg w/ > drm.debug=0xe that shows the modeset for each of the ports. Attached: dmesg from HDMI port located above the DisplayPort: https://bugs.freedesktop.org/attachment.cgi?id=129140 dmesg from HDMI port located on the left side of the DisplayPort: https://bugs.freedesktop.org/attachment.cgi?id=129141 (In reply to Ville Syrjala from comment #87) > If so, then it sounds like there's a bug somewhere. Do you see a bug from the attached dmesg's? Created attachment 129142 [details]
dmesg from HDMI port located above the DisplayPort
Created attachment 129143 [details]
dmesg from HDMI port located on the left side of the DisplayPort
Re-attached: dmesg from HDMI port located above the DisplayPort: https://bugs.freedesktop.org/attachment.cgi?id=129142 dmesg from HDMI port located on the left side of the DisplayPort: https://bugs.freedesktop.org/attachment.cgi?id=129143 [ 12.431104] [drm:intel_atomic_check [i915]] [CONNECTOR:56:HDMI-A-2] checking for sink bpp constrains [ 12.431151] [drm:intel_atomic_check [i915]] clamping display bpp (was 36) to default limit of 24 [ 12.431201] [drm:intel_hdmi_compute_config [i915]] picking bpc to 8 for HDMI output [ 12.431246] [drm:intel_hdmi_compute_config [i915]] forcing pipe bpc to 24 for HDMI [ 12.431293] [drm:intel_atomic_check [i915]] hw max bpp: 36, pipe bpp: 24, dithering: 0 [ 12.431359] [drm:intel_dump_pipe_config [i915]] [CRTC:31:pipe A][modeset] [ 12.431403] [drm:intel_dump_pipe_config [i915]] cpu_transcoder: A, pipe bpp: 24, dithering: 0 [ 12.431446] [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0 That "infoframes: 0" part is telling me that your display likely doesn't identify itself as supporting HDMI, so we treat it as DVI and decide to send it full range data instead of limited range data. But for DP (which is what LSPCON is for us) we don't make that distinction. Unfortunately the DP spec doesn't make any useful provisions for these kinds of combinations. so we're basically left to guess what we should be doing. I think what we might want to do is send full range data regardless of the timings when dealing with a DVI/HDMI downstream port and the monitor doesn't identify itself as HDMI compatible (essentially using the same logic as we use for native HDMI). DP++ downstream port might more difficult since I don't recall if we can somehow tell if the plugged in monitor is actually DVI/HDMI or DP (I'll need to look into this a bit more). For VGA/NO_EDID/whatnot downstream ports sending full range all the time might be the right choice. (In reply to Ville Syrjala from comment #94) > That "infoframes: 0" part is telling me that your display likely doesn't > identify itself as supporting HDMI, so we treat it as DVI and decide to send > it full range data instead of limited range data. It _is_ a DVI monitor. It's connected via a passive HDMI to DVI-D cable (HDMI on the PC side, DVI-D on the monitor side). > But for DP (which is what > LSPCON is for us) we don't make that distinction. Unfortunately the DP spec > doesn't make any useful provisions for these kinds of combinations. so we're > basically left to guess what we should be doing. > > I think what we might want to do is send full range data regardless of the > timings when dealing with a DVI/HDMI downstream port and the monitor doesn't > identify itself as HDMI compatible (essentially using the same logic as we > use for native HDMI). DP++ downstream port might more difficult since I > don't recall if we can somehow tell if the plugged in monitor is actually > DVI/HDMI or DP (I'll need to look into this a bit more). For > VGA/NO_EDID/whatnot downstream ports sending full range all the time might > be the right choice. Please simply remove the automatic detection. No one wants it anyway, see: https://bugzilla.kernel.org/show_bug.cgi?id=94921 (In reply to nw9165-3201 from comment #95) > Please simply remove the automatic detection. No one wants it anyway, see: No one, for whom the current code does not work, wants it. No one, for whom the current code works, wants it removed. The current code follows the relevant specifications. Damned if you do, damned if you don't, but going by the spec tips the scale. (In reply to Jani Nikula from comment #96) > No one, for whom the current code does not work, wants it. Which is the majority of users/monitors. (In reply to Jani Nikula from comment #96) > No one, for whom the current code works, wants it removed. Which is the minority of users/monitors. (In reply to Jani Nikula from comment #96) > but going by the spec tips the scale. Which makes no sense if most monitors don't adhere to the specs. Plus, DisplayPort doesn't even support this "spec" according to Ville Syrjala's previous comment... majority, minority, most, [citation needed]. (In reply to Jani Nikula from comment #99) > citation needed Well, if I understood correctly, then everyone who has a DVI-D monitor (these are a lot, this does not require any citation or statistic) and wants to connect it to a notebook or PC with a DisplayPort output, already has an issue now (unless you do something about it). And the rest was already discussed in lengths in the other thread: https://bugzilla.kernel.org/show_bug.cgi?id=94921 Plus, if you are on Wayland, you have a real issue at the moment, see: https://bugs.freedesktop.org/show_bug.cgi?id=99406 https://bugzilla.gnome.org/show_bug.cgi?id=777248 The content of attachment 129142 [details] has been deleted for the following reason: Asked to in https://bugs.freedesktop.org/show_bug.cgi?id=99537 The content of attachment 129140 [details] has been deleted for the following reason: Asked to in https://bugs.freedesktop.org/show_bug.cgi?id=99537 The content of attachment 129141 [details] has been deleted for the following reason: Asked to in https://bugs.freedesktop.org/show_bug.cgi?id=99537 Is there any update on this one? (In reply to N. W. from comment #105) > Is there any update on this one? What are the pending issues? (In reply to Jani Nikula from comment #106) > What are the pending issues? Why do I have to explain that again? It's all explained already. To repeat: LSPCon/DisplayPort always outputs limited range RGB, even when it should output full range RGB. (In reply to N. W. from comment #107) > (In reply to Jani Nikula from comment #106) > > What are the pending issues? > > Why do I have to explain that again? It's all explained already. To repeat: Because this bug conflates a number of issues, has grown very long, and every time someone looks at it they get confused. > LSPCon/DisplayPort always outputs limited range RGB, even when it should > output full range RGB. Thank you. I think the other, more pressing issues here have been fixed. I know you're going to hate me for this, but please file a new bug for just that, excluding everything else. Closing. (In reply to Jani Nikula from comment #108) > I know you're going to hate me for this No. However: I think you should have opened a new separate bug for it yourself after closing this one instead of asking me to do it, since it should be in your best interest to have this issue fixed, since it is your own product. (In reply to Jani Nikula from comment #108) > but please file a new bug for just Done: https://bugs.freedesktop.org/show_bug.cgi?id=100023 (In reply to N. W. from comment #109) > (In reply to Jani Nikula from comment #108) > > I know you're going to hate me for this > > No. However: I think you should have opened a new separate bug for it > yourself after closing this one instead of asking me to do it, since it > should be in your best interest to have this issue fixed, since it is your > own product. > > (In reply to Jani Nikula from comment #108) > > but please file a new bug for just > > Done: https://bugs.freedesktop.org/show_bug.cgi?id=100023 Thanks N. W. The content of attachment 129143 [details] has been deleted for the following reason:
user request
|
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 121889 [details] dmesg log file with debugging enabled I have an Asus z170 gaming-itx/ac motherboard which has one dp and two hdmi connections. I have three Samsung S27D850 monitors. When I connect only one monitor (dp or hdmi) everything is fine. When I connect two monitors (dp/hdmi or hdmi/hdmi) everything is fine. However, when I connect all three monitors, neither of the monitors connected to the hdmi ports will work. Only the dp monitor works. When I open the display program in ubuntu with three monitors connected, it shows me all three (correctly identified as Samsung monitors). 1 and 2 are enabled (even although 2 is blank) and 3 is disabled. I try to enable monitor 3 but it won't accept it. I've tried both hotplugging the 3rd monitor and having them all connected at startup. I've contacted Asus about this, and they told me that when they tested this with linux they had the same symptoms, but when they tested with Windows all 3 monitors were working. Seems to me therefore that the problem lies with the linux driver and not with my hardware. I'm using Intel Graphics Installer 1.4.0 (with latest updates downloaded) and the latest kernel (4.5 rc5)