This disables an essential HDMI 2.0 feature. Also, the issue seem to be specific to Gemini Lake. I couldn't reproduce it with Alder Lake/Tiger Lake.
Thanks for your help on this.
Do you think it would be useful if I open a bug in the i915 kernel repo (https://gitlab.freedesktop.org/drm/i915/kernel/-/issues)? This product is probably EOL, so I wouldn't expect much progress from intel engineers, but maybe someone there might have an idea about this.
HDMI 2.0 on Gemini Lake is finicky. I came up with this kernel hack to make it work without random black screens on a Samsung TV:
Diffdiff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 2fa9ba3..b258e1d 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -2549,7 +2549,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder, pipe_config->hdmi_scrambling = true; if (pipe_config->port_clock > 340000) { - pipe_config->hdmi_scrambling = true; + pipe_config->hdmi_scrambling = false; pipe_config->hdmi_high_tmds_clock_ratio = true; } }No idea if this would help in your case.
Will probably test a bit more, but so far no screen blackouts after applying this patch. Any reason this isn't merged in upstream?
Well, it reads exactly like a cable issue. Also make sure you have the latest BIOS and graphics firmware that might be available. Intel have a long history of buggy firmware.
I tried other cables and had the same issue. The Amlogic device also worked fine with the same cables. According to this chart https://www.rtings.com/images/reviews…able-medium.jpg, 4k60 8b RGB (17.82 Gb/s) has a higher bandwidth requirement than 4k24 12b RGB (13.37 Gb/s). Given that the higher bandwidth mode was working fine, i thought that the cable wasn't an issue.
I am running the latest bios (https://support.hp.com/us-en/drivers/…mId/vc-328930-1), but HP's changelogs aren't really an indication of whether they fixed any HDMI related issues. There doesn't seem to be any separate graphics firmware listed either.
Are there any other logs I can look at?
I am trying out LibreELEC 12 on an Intel N4020 (Gemini Lake Refresh) with a LG TV and I keep getting repeated occurrences of 2-3 seconds of black screens during playback when I switch to a 4k24 HDR mode (RGB 12b). These black screens also appears when I go back to the menu after playback has stopped (4K24 RGB 12b SDR). If I set the resolution to 4k60 HDR (RGB 8b) these black screens go away. I have tried the same HDMI cable on a AMLogic device and it is able to output up these modes (albeit YCbCr) fine, so I don't think it's a cable issue.
The kodi debug logs don't really seem to have anything in them 4K24(https://paste.kodi.tv/umixasocej.kodi) 4K60(https://paste.kodi.tv/sapeyakaja.kodi). `dmesg` also has nothing appearing in it. Are there any other logs I can look at?
https://bugs.freedesktop.org/show_bug.cgi?id=111032
There was supposedly a fix/improvement back in 2019.
Yes, the comments here seemed to indicate that the bug was fixed, but there are no references to what fixed it (and it's still present for me).
I can try rebuilding with the change you suggested, is it going to a night and day difference or something minor?
Edit: Just to add, the gpu frequency hack seems to mostly fix things to for me. My question is about whether we have a clearer understanding of the bug and whether it can be fixed upstream somewhere.
I recently acquired a HP T430 Thin Client with an Intel Celeron N4020 CPU. Running a clean install of Libreelec 12 on it, I can notice that there are clearly some dropped frames while navigating through the menus. Enabling the logging setting shows an FPS in the 20-30s range. The reason I even got this system was that x86 machines are reportedly much smoother and faster than arm machines for minimal kodi boxes.
There's been a bunch said already about this on the internet, and the solution has been to force the minimum gpu frequency to the max value supported.
111032 – Need to set gt_min_freq_mhz to max value to avoid sync issues on Gemini Lake N5000/J5005
The lack of further responses to any of the above tickets seem to indicate that the issue no longer exists, but it's clearly present for me. Is this a linux kernel issue or a buggy bios/firmware for my device?
I know I haven't posted any logs here, and it's because I wasn't sure what exactly to put. If the devs want something particular to look at, please let me know.
Sidetrack: I tried to do some further testing running kodi wayland in ubuntu desktop. I could swear that I noticed that the UI was buttery smooth when the default audio device wasn't HDMI, and only started dropping frames when I changed the the output device to HDMI audio in gnome settings. I tried replicating this a few more times to get some logs, but couldn't get it to consistently reappear. dmesg and journalctl logs didn't show anything either. If anyone has thoughts on this, please let me know.
