Can you boot with drm.debug=0xe and provide the full dmesg?  Also, please try the drm-intel-nightly branch to confirm it has not been fixed upstream already.

I'm changing the status to "NEEDINFO". Please, once you provide more information change the tag from "NEEDINFO" to "REOPEN". Thank you.

Created attachment 132026 [details]
dmesg output

I compiled latest drm-intel-nightly (SHA 18d562c9) and still get no image.

I also attached the full dmesg output with "drm.debug=0xe log_buf_len=4M"

(In reply to stef@zechner77.de from comment #3)
> Created attachment 132026 [details]
> dmesg output
> 
> I compiled latest drm-intel-nightly (SHA 18d562c9) and still get no image.
> 
> I also attached the full dmesg output with "drm.debug=0xe log_buf_len=4M"

Thanks for the information,

There are 3 things that caught my attention in your log:

1) The hotplug task is triggering every few seconds and (apparently) successfully detecting the monitor attached to HDMI-A-3 every time.

2) After each detection, errors like this occur:

 [drm:intel_engine_cmd_parser [i915]] CMD: Rejected register 0x00002360 in command: 0x11000001 (rcs0)
[   50.339786] [drm:intel_engine_cmd_parser [i915]] CMD: Rejected register 0x00002360 in command: 0x11000001 (rcs0)

3) Finally, we have:

 [drm:intel_prepare_plane_fb [i915]] failed to pin object

Which doesn't seem related to the rest.  

Since the monitor is identified and the connector modes are successfully probed,  I want to start by figuring out what made the register value to be rejected.

thanks for investigating.

Please let me know if you want me to patch or modify anything in the sources to pin down this issue.

BTW.: The HDMI device is a 5 years old Samsung Video Beamer and the only special configuration in this computer might be the two satellite TV cards (DVB-S2)

(In reply to krisman from comment #4)

> 2) After each detection, errors like this occur:
> 
>  [drm:intel_engine_cmd_parser [i915]] CMD: Rejected register 0x00002360 in
> command: 0x11000001 (rcs0)
> [   50.339786] [drm:intel_engine_cmd_parser [i915]] CMD: Rejected register
> 0x00002360 in command: 0x11000001 (rcs0)

So, if I'm not mistaken, this is oacontrol and it is expected to fail.  It is not related.

Created attachment 132235 [details]
dmesg output: monitor connected to HDMI is working

I just tried to connect my LG monitor to HDMI output.
And I was surprised that it is working well. (see attachment dmesg_monitor_short_txt.gz)

So it seems to be an issue with Intel HDMI output and my Video Beamer "Samsung SP-A600XB".
Anyhow I also connected the HDMI beamer solely (no additional monitor) and the image disappeared during Linux boot like previously described.

Anybody has an idea what may be different between beamer and monitor? And how I can fix this with the latest kernel?

thanks
Stefan

Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
*Logs included

Any update on this? We've been experiencing the same issue with some Philips displays on kernal 4.9 (debian stretch)

A shot in the dark, please try this debug patch on top of drm-tip:

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index e6f8f30ce7bd..af309a6efb26 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1547,6 +1547,8 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
 		}
 	}
 
+	type = DRM_DP_DUAL_MODE_TYPE1_DVI;
+
 	if (type == DRM_DP_DUAL_MODE_NONE)
 		return;

thanks Jani,

I tried 4.14.0-rc2+ from branch drm-intel-nightly and your line makes the difference.

Cc: Ville, he probably has some idea.

Created attachment 134527 [details]
dmesg output

Created attachment 134528 [details]
dmesg output: monitor connected to HDMI is working

Please *always* attach files unpacked.

(In reply to Jani Nikula from comment #10)
> +	type = DRM_DP_DUAL_MODE_TYPE1_DVI;

That really was a shot in the dark, and shouldn't really have made a difference... but I guess it works by forcing 165 MHz max clock, and therefore 8 bpc instead of 12 bpc. That's all I can think of. 12 bpc leads to 222.75 MHz clock which is pretty close to the 225 MHz limit.

So throw the old debug patch away, and try instead:

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index e6f8f30ce7bd..5c99189e9ccf 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1463,7 +1463,9 @@ bool intel_hdmi_compute_config(struct intel_encoder *encoder,
 
 		/* Need to adjust the port link by 1.5x for 12bpc. */
 		pipe_config->port_clock = clock_12bpc;
-	} else {
+	}
+
+	if (true) {
 		DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
 		desired_bpp = 8*3;
 

or alternatively set the "audio" property to "force-dvi" on the connector.

Please attach dmesg on the try.

Created attachment 134552 [details]
dmesg output: picking bpc to 8 for HDMI output

Hi Jani,

tried your new patch and it is working again.

I uploaded: dmesg_2017_09_28.txt.gz

it's compressed because of the 32k file size limit

(In reply to stef@zechner77.de from comment #18)
> Hi Jani,
> 
> tried your new patch and it is working again.

Jani, reassigning to you since the patch fixes the issue.

Created attachment 134614 [details]
dmesg output: picking bpc to 8 for HDMI output

(In reply to krisman from comment #19)
> Jani, reassigning to you since the patch fixes the issue.

Sorry, I'm not taking it on. That was just a quick hack debug patch to prove a theory. It brings us one step closer to finding out what the problem is, but I have no idea what the fix should be. That patch is not the fix.

(In reply to stef@zechner77.de from comment #18)
> it's compressed because of the 32k file size limit

There shouldn't be such a limit here. I hear it should be more like 4 MB limit.

but do you have a workaround for me like setting a kernel parameter?

So that I can run the latest Debian kernel without recompiling.

Hi,

here is the values in function intel_hdmi_compute_config() for the HDMI device:

pipe_config->pipe_bpp: 36
pipe_config->has_hdmi_sink: 1
hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true): 0
hdmi_12bpc_possible(pipe_config): 1

anything suspicious? What do you need to go on?

First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

Closing, please re-open if occurs again.

problem still exists

Ville should look at this.

8bpc vs. 12bpc eh? Which probably means there's a broken component somewhere in the signal path. Could be the level shifters in the source, cable, dongle, or the monitor itself.

The workaround I've been suggesting is to add a knob for the user to limit the color depth. The problem for cases like this where there is no output (as opposed to just glitchy output) is that a connector property would have to be changed by the user blind. The alternatives would be to change the default to 8bpc, or add a modparam (or something like it) to force the 8bpc already when the driver loads. Hmm. Maybe we should extend the "awesome" video= cmdline syntax a bit?

I have ASUS Zenbook UX303U. This laptop has Intel i7-6500 CPU @2.5GHz, 12GB RAM, and the integrated graphics card. 
It's running under OpenSUSE 15.0 (kernel 4.17.7). Some time ago, I used OpenSUSE 42.3 with kernel 4.3 and HDMI worked fine with every my devices, e.g., TV set, monitor LCD, and projector.

After installing  Leap 15.0, the HDMI output works only with monitor LG LG FLATRON IPS234V-PN. The other devices (projector ACER H6518BD and TV set PANASONIC VIERA TX-42AS650E) aren't connecting to HDMI in my notebook.

On the other hand, if I try to connect the projector or the TV set after working with LG monitor, I observed that the settings of video outputs (xrandr) returned to the default states (disconnected).

I think that it is still the same issue as in the 4.4 kernel.

Anusha - what are the next steps here?

@james(In reply to James Ausmus from comment #31)
> Anusha - what are the next steps here?


James, let me reproduce this on HSW. There could be some PLL calculation that we are doing wrong.

(In reply to stef@zechner77.de from comment #23)
> but do you have a workaround for me like setting a kernel parameter?
> 
> So that I can run the latest Debian kernel without recompiling.
I could not reproduce the issue. But,

Can you try this 2 patch series https://patchwork.freedesktop.org/patch/251249/
and https://patchwork.freedesktop.org/patch/251248/ ?

It seems to be addressing your issue.

(In reply to anusha from comment #33)
> Can you try this 2 patch series
> https://patchwork.freedesktop.org/patch/251249/
> and https://patchwork.freedesktop.org/patch/251248/ ?

and to which kernel version do I have to apply these patches?
Tried 4.9 and 4.19 and both don't even have a file drm_atomic_uapi.c

Understood. I need the mainline.
Tried 4.20.0-rc7 with the two patches but it stops booting after 5s with several ACPI device range conflicts.
I will try again after some time when the kernel is more stable.

Meanwhile the max_bpc patch reached the kernel master branch and brings back my beamer:
xrandr --output HDMI-3 --set "max bpc" 8

Thus issue is solved by future kernel v4.21

(In reply to stef@zechner77.de from comment #36)
> Meanwhile the max_bpc patch reached the kernel master branch and brings back
> my beamer:
> xrandr --output HDMI-3 --set "max bpc" 8
> 
> Thus issue is solved by future kernel v4.21

Closing this bug. Please reopen if this issue appers on drmtip.
(https://cgit.freedesktop.org/drm-tip)