NUC6AYH : No-go for HDR.
NUC7i3BN : Works with HDR (on the previous build you posted about roughly a week or two ago)
That's interesting.
According to Intel's support pages for those NUCs they use the same MCDP2800 LSPCON chip.
Can you retest NUC6AYH with the build from post #502?
Also note that there is an issue with those builds. If you turn the TV off and then on (while the NUC is connected and working) - HDR will stop working until Kodi is restarted (maybe a bug in EDID parser code).
You can install LE to a USB drive.
I'd rather not.
Master branch is almost identical to a Matrix branch at this point anyway.
Yes, that one is working.
Haven't tested it properly yet though but I did saw the HDR icon show up on my tv.
That's good news. You are the first one who reported a working HDR on older LSPCON hardware. It looks like that NUC has MegaChips MCDP2800BC LSPCON.
I uploaded an updated image.
- Linux kernel 5.12-rc4
- Kodi e04f7d6
Everything else is identical to a build from post #494.
No. I forked lrusak repo and merged kodi master branch into drmprime-2img-no-ffmpeg-bump branch.
Updated build with HDR:
Current Kodi master (83387b9)
Linux kernel 5.11.7
Mesa 21.0.0
Full-feature Intel media-driver with fixed VAAPI DI
HDR patches from Commits · lrusak/xbmc · GitHub
how can a NUC decode audio same then a 1k AV.
Very easily. If you extract the same .rar archive on a $10000 computer and on a $100 computer - the extracted content of the archive will be bit-identical on both PCs.
Same goes with lossless audio formats.
Those HBR audio formats like DTS-HD MA, Dolby TrueHD or flac are merely a lossless compression of data. It makes no difference where the decompression takes place. Bitstreaming and decoding to LPCM are just 2 different methods of delivering the same audio data to the AVR.
Bitstreaming makes sense on those devices that for whatever reason cannot decode the above mentioned formats. Since Kodi can do a lossless decode of any HBR format - the absence of bitstreaming should never be an issue.
What is the advantage of bitstreaming the audio vs.sending the decoded LPCM to AVR? Just trying to understand why people care so much about audio passthrough. I'd like to hear a valid technical reason why bitstreaming is supposed to be better than decoding to LPCM. Since Kodi can decode all known HBR audio formats and send LPCM 7.1 over HDMI I don't see a single good reason why anyone should bother with passthrough.
I stayed with using the iHD/i915 driver.
intel-vaapi-driver (i965) doesn't work at all on Tiger Lake, so you don't really have much choice 
It's been 2 years and 4 months since you opened that PR. 
Hopefully nobody would object this time if you reopen it 
Nvidia users are better off using Windows 10. Actually, my main PC is Ryzen 5 3600 with Nvidia GTX 1650 running Windows 10
Discrete graphics doesn't make sense for a dedicated LibreELEC box anyway. Low-power APUs and SoCs is what LE is all about IMO.
Not sure about the AMD situation.
AMD works fine on GBM
afaik at least di and scaling are not there
Both DI and scaling are fully functional with GBM + VAAPI (DRM PRIME disabled.) There is absolutely no reason to use X11 on Intel hardware
depends at not upstreamed patches for kodi and ffmpeg
Those are only DRM PRIME stuff. GBM VAAPI is fully functional (without HDR) in current LE master without those non-upstreamed patches.
Your build, would it work on a NUC6CAYB to enable HDR output ?
Try the build from post #426. It includes Linux HDR patches for MCA LSPCON. No idea if it will work or not.
Does anyone here use a Gemini Lake box with a Samsung 4K TV (2019 or 2020 model)?
After experiencing some annoying HDMI issues with 4K modes (e.g. intermittent white dots after a mode change, with known good cables) I decided to poke around in Intel driver and found the problem. Apparently, my Samsung TV doesn't like Intel's implementation of HDMI Scrambling.
I disabled scrambling with a below patch and all issues are gone.
diff --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;
}
}I hope X11 would be dropped after LE 10 is branched out. I feel like it is holding back the development of Generic x86.
I don't understand what you mean by that. My builds are compiled from LE git master + HDR patches from lrusak's git repo + some minor changes to make it all compile and work.
Deinterlacing is not implemented (yet) for DRM PRIME.