EDID NUC + LibreELEC 10.0.1

  • Hello, I've been searching for info on how to resolve my black monitor-problem.

    When I activate my TV, LG 9500 via HDMI to my Intel NUC 7i5BNB, I get the botupsequence and then Libreelec bots fine with picture and all.

    If I turn on the Libreelec before the TV I get no signal. Which I understand is based on that Libreelec queries the active monitor and uses the EDID-response.

    So I ventured into getedid-territory as described in several posts on the net.

    When I SSH in and run Getedid create it dutifully with no reported errors reboots but the screen is black, I SSH in again and getedid delete, which restores functionality.

    When I dig into the matter it seems my EDID for my intel are stored under :

    LibreELEC:~ # find /sys -name "edid"

    /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1/edid

    /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-2/edid

    /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/edid

    With DP-1 as active on current Monitor/TV

    tail /sys/class/drm/*/status

    ==> /sys/class/drm/card0-DP-1/status <== connected

    ==> /sys/class/drm/card0-DP-2/status <==disconnected

    ==> /sys/class/drm/card0-HDMI-A-1/status <==disconnected

    In getedid-script Github Getedid

    it states:

    cat "/sys/class/drm/$card/edid" > /tmp/cpio/lib/firmware/edid/edid.bin

    When looking there I get:

    LibreELEC:/sys/class/drm # ls

    card0 card0-DP-2 renderD128 version card0-DP-1 card0-HDMI-A-1 ttm

    And when I enter card0-DP-1

    I get dumped back in sys/devices (Symlink?)

    LibreELEC:/sys/class/drm # cd card0-DP-1

    LibreELEC:/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1 # ls

    device drm_dp_aux0 enabled modes status uevent

    dpms edid i2c-3 power subsystem


    Could this be why it fails to extract the relevant EDID?

    Or is the TV not responding adequately to the requests, I read that EDID could get corrupted.

    Would appreciate some guidance on how to proceed since I believe the solution is within my hand. :)

    (I'm no Linux-wiz as is patently obvious.)

    Also would it be possible to integrate some sort of EDID-management inside LibreElec to make life easier? Apart from adding the SSH-script.

  • Kodi only searches for the active DRM device at startup, so if you connect (or power on) the monitor afterwards the kernel will detect it and reconfigure itself for the new active connection but Kodi will remain fixed on whatever it saw at boot. And it looks like the DP-1 port is seen to be active when HDMI is not connected.

    The getedid script should work, but you will need to ensure HDMI is connected and the monitor powered on before you power on the NUC, else the script will probably find the DP-1 device active and then you get the EDID for the DP-1 port, maybe?

    It's also possible to set "video=HDMI-A-1:1920x1080M@60" in kernel boot params, which should force output to the HDMI connector with some standard timings. Other random thoughts are to disable the DP ports in BIOS, if that's possible?

  • Kodi only searches for the active DRM device at startup, so if you connect (or power on) the monitor afterwards the kernel will detect it and reconfigure itself for the new active connection but Kodi will remain fixed on whatever it saw at boot. And it looks like the DP-1 port is seen to be active when HDMI is not connected.

    The getedid script should work, but you will need to ensure HDMI is connected and the monitor powered on before you power on the NUC, else the script will probably find the DP-1 device active and then you get the EDID for the DP-1 port, maybe?

    It's also possible to set "video=HDMI-A-1:1920x1080M@60" in kernel boot params, which should force output to the HDMI connector with some standard timings. Other random thoughts are to disable the DP ports in BIOS, if that's possible?

    Thanks for the reply. If I run GetEdid and reboot, the monitor stays on all the time. Still kodi doesn't detect it after the Getedid-sequence.

    I guess it misconfigures the Edid it saves, so the monitor/TV isn't activated properly.

    I also note after reading your answer that the only actual actual connection from the NUC is HDMI, so the active connection DP seems weird, maybe it's some sort of conversion going, it supports DP via USB-c thunder bolt which is not connected.

    It's a bit strange that when it's working ok, it detects DP as active instead of HDMI, then when GetEdid tries to save that config it suddenly breaks down?


    I'll try to run

    tail /sys/class/drm/*/status

    after doing the getedid to see if it stays on DP as expected or if it switches.

    I thought maybe the BIOS in the NUC might be messing things up through some exotic video setting, but haven't poked around much.

    How do I easily go about changing the Kernel boot params, can it be done from UI or is it easier from SSH?

  • If I disconnect HDMI, the DP-1 is disconnected and when HDMI reattached it shows DP-1 is connected again.

    weird

    If I run: tail /sys/class/drm/*/status

    after Getedid create, and reboot with black monitor, it shows DP-1 as Connected even if I unplug HDMI, which I suppose is expected behaviour, since GetEdid locks in on a Edid.

    Found this on another forum:

    • nuc ~> hdmi-out ~> monitor1 (works, although xrandr detects it as a displayport monitor for some reason)

    so I ran Xrandr

    LibreELEC:~ # xrandr

    Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767

    DP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm

    1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29 .97 23.98

    1920x1080i 60.00 50.00 59.94

    1280x1024 60.02

    1152x864 75.00

    1280x720 60.00 59.81 50.00 59.94

    1024x768 60.00

    800x600 60.32

    720x576 50.00

    720x480 60.00 59.94

    640x480 60.00 59.94

    720x400 70.08

    DP2 disconnected (normal left inverted right x axis y axis)

    HDMI1 disconnected (normal left inverted right x axis y axis)

    VIRTUAL1 disconnected (normal left inverted right x axis y axis)


    Maybe it's a Linux thing where it detects the Video as DP, which messes up the real DP for those using it?

  • If I disconnect HDMI, the DP-1 is disconnected and when HDMI reattached it shows DP-1 is connected again.


    weird

    according to this doc:

    https://objects.icecat.biz/objects/mmo_36674449_1496735571_8567_29150.pdf

    page 21

    one internal DP goes through an ~"DP to HDMI converter"~ (LSPCON)

    and the other two through an "PCIe-Data-lane-multiplexer (?)" to an USB-C (Data/Display signal)

    from my NUC (also with an LSPCON) connected via HDMI (-cable)

    tail /sys/class/drm/*/status

    ==> /sys/class/drm/card0-DP-1/status <==

    connected

    ==> /sys/class/drm/card0-DP-2/status <==

    disconnected

    ==> /sys/class/drm/card0-HDMI-A-1/status <==

    disconnected

  • If the NUC has LSPCON it makes sense that DP-1 is seen as connected, althoug it's a bit of a mystery why HDMI-1 is not active at the same time since (in theory?) it's the active output. Have you tried an LE11 nightly image? .. newer drivers might give different results (grasping at straws in the dark).

  • JoeAverage: Good find, this seems highly likely for the unexpected DP/HDMI.

    Chewitt: I guess I could try the Nightly 11 but they seem pretty flakey.

    What would be interesting to know is why LE and NUC play along as expected when monitor is turned on beforehand, even though it reports DP instead of HDMI?

    And then when the Blackbox GetEdId does its thing it suddenly breaks even though it still connects to DP-1?

    Is there any way to Log what differences GetEdId causes in the output?

    It'd also be interesting to try Forcing HDMI as per kernel-boot params to see what happens, as you suggested.

    But I'm a bit out of my depth on how to edit and then restore that.

  • I guess I could try the Nightly 11 but they seem pretty flakey.

    running nightly since some weeks (and btw. the above output is from nighty too):

    nothing flakey here.

    I've no idea why the kernel ~sees~ the HDMI Port as inactive when only HDMI is connected.

    things might change if we see in LE a 5.16 kernel (a lot of GPU driver work went in)

    at least on my desktop (i5-11400, UHD Graphics 730, MB: B560 Chipset) connect via HDMI it looks like this [1]:

    tail /sys/class/drm/*/status:

    ==> /sys/class/drm/card1-DP-1/status <==

    disconnected

    ==> /sys/class/drm/card1-HDMI-A-1/status <==

    disconnected

    ==> /sys/class/drm/card1-HDMI-A-2/status <==

    connected

    [1]

    so far I couldn't figure if my desktop has a LSPCon too...

  • Up to (and including) their 10th generation Comet Lake processors Intel only have HDMI 1.4 interfaces implemented. For HDMI 2.0 output the LSPCon Display Port to HDMI converter are used and required. As consequence the limited native HDMI interface is not used at all in most cases.

    Is there any way to Log what differences GetEdId causes in the output?

    As good start always use the pastekodi script and post the URL (enabling Kodi debug logging can likely be omitted here).

  • Up to (and including) their 10th generation Comet Lake processors Intel only have HDMI 1.4 interfaces implemented. For HDMI 2.0 output the LSPCon Display Port to HDMI converter are used and required. ...

    slighty OT, but out of interest:

    it seems Intel uses a sorta LS and PCon in some NUC11 too:

    scroll to the picture "Block diagram" 

    Intel NUC 11 Performance Kit - NUC11PAHi5 - Panther Canyon (RNUC11PAHI50002) ab € 540,75 (2022) | heise online Preisvergleich / Deutschland

    => PCON

    and

    Intel NUC 11 Pro Kit NUC11TNHi7 - Tiger Canyon (BNUC11TNHI70002) ab € 649,93 (2022) | heise online Preisvergleich / Deutschland

    => PCON and LS/Retimer

    were I translate:

    PCon := protocol converter

    LS:= level shifter

    LSPCon:= Level Shifter/Protocol Converter

    I wonder what heitbaum (owner of an NUC11; (11 right ?)) see if he connects his display via HDMI and "tail /sys/class/drm/*/status"

  • I also have the NUC11PAHI5, and the HDMI connection doesn't get any signal on the display. It shows a connection through DP, but no output. The only way I got a decent connection was through a miniDP to HDMI converter, and then still had issues with HD audio, which apparently is an Intel issue (which they're working on per the link below).

    HD audio passthrough on NUC11PAHi5 not working
    I have the same issue that seems to be happening on previous models of NUCS as seen here for…
    community.intel.com
  • Hi GDPR-7

    This is the model - I have

    - https://ark.intel.com/content/www/us…nuc11pahi7.html

    - https://www.intel.com/content/dam/su…ation_Guide.pdf

    And I am connected to the HDMI port.


    [ 0.000000] DMI: Intel(R) Client Systems NUC11PAHi7/NUC11PABi7, BIOS PATGL357.0041.2021.0811.1505 08/11/2021

    After a clean boot 5.16.1-rc1 (with HDMI and displaying on LG4K TV)

    - card0-DP-3 shows connected when the cable is connected.

    nuc11:~ # tail /sys/class/drm/*/status

    ==> /sys/class/drm/card0-DP-1/status <==

    disconnected

    ==> /sys/class/drm/card0-DP-2/status <==

    disconnected

    ==> /sys/class/drm/card0-DP-3/status <==

    connected

    ==> /sys/class/drm/card0-DP-4/status <==

    disconnected

    ==> /sys/class/drm/card0-HDMI-A-1/status <==

    disconnected

  • Thanks heitbaum - are you getting HDR and HD Audio passthrough output succcessfully? Is that going through a receiver?

    I have the i5 version of that, and I can't get any output to my receiver (Denon 3700h) from HDMI. When I do use the miniDP to HDMI and @smp's development build, I can get 4K/HDR, but HD Audio has no output, and after trying to play a file with HD Audio, the system must be rebooted to get any sound whatsoever.