Posts by HorzaSe

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.

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?

Quote from chewitt

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?

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.