[Bug 106659] [hdmi retimer?] No signal after switch from HDM1 to HDM2 and return in HDM1

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106659

--- Comment #37 from Imre Deak <imre.deak at intel.com> ---
(In reply to fatez from comment #34)
> (In reply to Imre Deak from comment #33)
> > (In reply to fatez from comment #31)
> [...]
> Hi,
> 
> My system is nuc7pyh and has two native HDMI 2.0 port.
> I only use the first HDMI(A-1) port and it is linked to Denon AVR-X2400H;
> the second HDMI(A-2) port is empty, it is not connected.
> When I pass from hdmi1 to hdmi2 and vice versa, I never unplug the cable
> from the NUC but I use Denon's remote to switch from Sky (hdmi2) to Kofi Nuc
> (hdmi1).
> When I pass from Kodi to Sky and I'll be back in Kodi i lost the signal
> forever. I have to reboot the Nuc so I can see again.

Ah ok, so for reference, IIUC you have (please confirm/correct it):

- Two HDMI sources, one of them is the NUC7PJYH2 GLK NUC. (If so what is the
other source?)
- The two sources are connected to the AVRs two HDMI inputs (HDMI1/HDMI2).
- To the AVR there is one HDMI display connected.
- Switching between the two AVR inputs with the AVR's remote causes the
problem.

>From the log I can see the following sequence:
1. successful modeset on HDMI-A-1                (AVR is switched to HDMI1)
2. hotplug with HDMI-A-1 becoming disconnected   (AVR is switched from HDMI1 to
HDMI2)
   There is no modeset at this point, so HDMI-A-1 should continue to output a 
   valid signal.
3. hotplug with HDMI-A-1 becoming connected      (AVR is switched back to HDMI1
from HDMI2)
   Again no modeset, though a few successful detect cycles. HDMI-A-1 should
   still continue to output a valid signal from the mode set at 1.

It's a bit strange that Kodi doesn't disable the output in 2., but in theory
things should still work, as the mode remains the same in 3. as what was set in
1. In any case it's possible that we need to force a mode disable/re-enable
cycle to make things work.

Could you try finding a way to force Kodi to disable the output after you
switched the AVR from HDMI1 to HDMI2 and then make it re-enable it in Kodi
after you switched back to HDMI1? (For ex. by setting some video output setup
option in Kodi from and back to HDMI-A-1).

If that doesn't fix it, to rule out that this is an AVR/display issue, could
you try the following two things in the bad state when you switched the AVR
back to HDMI1 (keeping the GLK NUC powered all the time)?:
A.
1. unplug the display from AVR and power cycle the display
2. plug the display directly to the GLK NUC

B.
1. power off both the AVR and the display
2. power on the AVR, make sure it's switched to the HDMI1 input (the GLK NUC)
3. power on the display

Does A. or B. resolve the problem?

Did you try to upgrade the firmware of your AVR [1], and your display?

[1] http://firmware.denon.eu/

> If it helps, I did a hw-probe of my "clean" system here:
> https://linux-hardware.org/index.php?probe=a9b6f206ab
> And here I did a hw-probe with "drm.debug=0x1e log_buf_len=4M" :
> https://linux-hardware.org/?probe=94f2aa43b7
> 
> so here :
> NucBox:/sys/class/drm$ cat card0-HDMI-A-1/status 
> connected
> 
> NucBox:/sys/class/drm$ cat card0-HDMI-A-2/status 
> disconnected
> 
>   - Product code = BOXNUC7PJYH2
>   - Project code = ??
>   - Date of manufacture = 28MAR2018

Thanks, so not a pre-production device.

> 
> The problem comes every time I move from hdmi2 to hdmi1 and I go back to
> hdmi2 (always through Denon, I repeat, I never unplug the Hdmi cable from
> the Nuc)
> 
> And AFTER SIGNAL LOST :
> 
> $ sudo cat /sys/class/drm/card0-HDMI-A-1/status
> connected

Right, this was never a problem then, the output is in the connected state when
it's supposed to be.

> 
> $ sudo cat /sys/class/drm/card0-HDMI-A-2/status
> disconnected

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180719/58fdc8d8/attachment.html>