Posts by HiassofT

I think I know now what's going on and it does look like a kodi bug to me:

Even with a SDR display connected (which doesn't report support for BT2020) kodi sets the Colorspace connector property to BT2020 - and my HDFury also shows that in the received AVI infoframe.

2026-06-15 19:59:50.957 T:935     debug <general>: virtual void KODI::WINDOWING::GBM::CWinSystemGbm::SetColorimetry(const VideoPicture*): setting connector colorspace to BT2020_RGB (source BT2020_YCC)

But as the connector doesn't have the HDR_OUTPUT_METADATA property kodi it detects it as a SDR display and performs tonemapping:

2026-06-15 19:59:50.957 T:935     debug <general>: LinuxRendererGLES::Configure: HDR passthrough: off
...
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: Requested render method: 0
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using shader format: NV12 red/red/green
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using tonemap method: reinhard
2026-06-15 19:59:51.210 T:935      info <general>: GLES: Selecting YUV 2 RGB shader
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using shader format: NV12 red/red/green
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using tonemap method: reinhard

I'm not familiar with the inner details of kodi's tonemapping implementation but I highly suspect that will do both PQ->gamma EOTF transformation and also BT2020->BT709 colorspace transformation.

So I guess kodi outputs a standard BT709/gamma SDR image, but signals BT2020 colorspace which doesn't quite match.

smp could you have a closer look at the kodi code?

so long,

Hias

Quote from smp

The log shows that HDR passthrough is now enabled. If the TV does doesn't switch to HDR mode then the theory that HDMI 1.4 can output HDR metadata is wrong.

Just for the kicks I gave your build a try on an ancient gen6 system and got the same result:

The HDR_OUTPUT_METADATA connector property now appears on the HDMI connector, and kodi set it, but I get the same kernel splat as in the OP's log and my HDFury Vrroom didn't report any HDR metadata - so the infoframe wasn't generated (as expected from the kernel splat)

[   57.150415] i915 0000:00:02.0: [drm] *ERROR* [CRTC:59:pipe A] mismatch in infoframes.enable (expected 0x000000f1, found 0x00000071)
[   57.150423] i915 0000:00:02.0: [drm] *ERROR* [CRTC:59:pipe A] mismatch in drm infoframe
[   57.150426] i915 0000:00:02.0: [drm] *ERROR* expected:
[   57.150428] i915 0000:00:02.0: HDMI infoframe: Dynamic Range and Mastering, version 1, length 26
[   57.150431] i915 0000:00:02.0: length: 26
[   57.150433] i915 0000:00:02.0: metadata type: 0
[   57.150434] i915 0000:00:02.0: eotf: 2
[   57.150436] i915 0000:00:02.0: x[0]: 34000
[   57.150438] i915 0000:00:02.0: y[0]: 16000
[   57.150440] i915 0000:00:02.0: x[1]: 13250
[   57.150441] i915 0000:00:02.0: y[1]: 34500
[   57.150442] i915 0000:00:02.0: x[2]: 7500
[   57.150444] i915 0000:00:02.0: y[2]: 3000
[   57.150445] i915 0000:00:02.0: white point x: 15635
[   57.150447] i915 0000:00:02.0: white point y: 16450
[   57.150448] i915 0000:00:02.0: max_display_mastering_luminance: 1000
[   57.150450] i915 0000:00:02.0: min_display_mastering_luminance: 200
[   57.150451] i915 0000:00:02.0: max_cll: 0
[   57.150453] i915 0000:00:02.0: max_fall: 0
[   57.150454] i915 0000:00:02.0: [drm] *ERROR* found:
[   57.150458] ------------[ cut here ]------------
[   57.150459] i915 0000:00:02.0: [drm] pipe state doesn't match!
[   57.150460] WARNING: drivers/gpu/drm/i915/display/intel_modeset_verify.c:225 at intel_modeset_verify_crtc+0x323/0x540, CPU#0: kodi.bin/792
[   57.150467] Modules linked in: 8021q bnep ntfs bluetooth ecdh_generic ecc snd_hda_codec_intelhdmi snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic snd_soc_avs snd_soc_hda_codec intel_rapl_msr snd_hda_ext_core intel_rapl_common snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core x86_pkg_temp_thermal intel_powerclamp snd_hwdep cfg80211 rfkill pkcs8_key_parser fuse dmi_sysfs
[   57.150495] CPU: 0 UID: 0 PID: 792 Comm: kodi.bin Not tainted 7.1.0 #1 PREEMPT 
[   57.150499] Hardware name: HP HP EliteDesk 800 G3 DM 65W/829A, BIOS P21 Ver. 02.50 07/14/2024
[   57.150501] RIP: 0010:intel_modeset_verify_crtc+0x329/0x540
[   57.150504] Code: 77 9a fe 48 85 ff 74 04 48 8b 7f 08 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 94 75 11 00 48 8d 3d 8d 2c ae 0b 4c 89 e2 48 89 c6 <67> 48 0f b9 3a 48 c7 c2 95 1d d7 b0 31 f6 4c 89 f7 e8 91 23 f9 ff
[   57.150507] RSP: 0000:ffffb82601503a58 EFLAGS: 00010282
[   57.150510] RAX: ffffffffb0d7652b RBX: ffff9be4d141f000 RCX: 0000000000000027
[   57.150512] RDX: ffff9be4d13985b0 RSI: ffffffffb0d7652b RDI: ffffffffb13d4e40
[   57.150513] RBP: ffffb82601503ac0 R08: 3fffffffffffefff R09: 0000000000000000
[   57.150515] R10: bffffffffffff000 R11: 3ffffffffffff000 R12: ffff9be4d13985b0
[   57.150516] R13: ffff9be4d1098270 R14: ffff9be4e5e5c000 R15: ffff9be4d141f000
[   57.150518] FS:  00007f31cc8140c0(0000) GS:ffff9be82d53d000(0000) knlGS:0000000000000000
[   57.150520] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   57.150522] CR2: 00007f310f08d000 CR3: 0000000123806002 CR4: 00000000003706b0
[   57.150524] Call Trace:
[   57.150526]  <TASK>
[   57.150529]  ? intel_pin_eld_notify+0xa6/0xc0 [snd_hda_codec_intelhdmi]
[   57.150533]  intel_atomic_commit_tail+0x14ed/0x1b70
[   57.150540]  intel_atomic_commit+0x2bc/0x300
[   57.150543]  drm_atomic_commit+0xb1/0xe0
[   57.150547]  ? __pfx___drm_printfn_info+0x10/0x10
[   57.150552]  drm_mode_atomic_ioctl+0xb23/0xd80
[   57.150556]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[   57.150559]  drm_ioctl_kernel+0xaa/0x100
[   57.150563]  drm_ioctl+0x286/0x560
[   57.150566]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[   57.150569]  ? vfs_write+0x25b/0x4e0
[   57.150572]  ? vfs_write+0x25b/0x4e0
[   57.150574]  __x64_sys_ioctl+0x4e4/0xa90
[   57.150578]  ? __f_unlock_pos+0x16/0x20
[   57.150580]  ? ksys_write+0xce/0x100
[   57.150583]  x64_sys_call+0xf1f/0x1dd0
[   57.150587]  do_syscall_64+0xbc/0x480
[   57.150591]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   57.150594] RIP: 0033:0x7f31d09cbd58
[   57.150597] Code: 00 00 48 8d 44 24 08 48 89 54 24 e0 48 89 44 24 c0 48 8d 44 24 d0 48 89 44 24 c8 b8 10 00 00 00 c7 44 24 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 07 89 d0 c3 0f 1f 40 00 48 8b 15 69 c0 0c
[   57.150599] RSP: 002b:00007fff2d980a48 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[   57.150602] RAX: ffffffffffffffda RBX: 00000000395974f0 RCX: 00007f31d09cbd58
[   57.150603] RDX: 00007fff2d980a90 RSI: 00000000c03864bc RDI: 0000000000000017
[   57.150605] RBP: 00007fff2d980a90 R08: 0000000000000002 R09: 0000000000000079
[   57.150606] R10: 00007f31d0a990f8 R11: 0000000000000246 R12: 00000000c03864bc
[   57.150608] R13: 0000000000000017 R14: 0000000037dec710 R15: 0000000000000017
[   57.150611]  </TASK>
[   57.150612] ---[ end trace 0000000000000000 ]---

so long,

Hias

Well, about 1 month ago heitbaum reported an issue with the xe driver during video playback with pretty much the same log message (in our slack channel):

May 15 20:51:44.895554 nuc12 kernel: xe 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A][PLANE:33:plane 1A] fault (CTL=0x92001000, SURF=0x4000000, SURFLIVE=0x4000000)

Your post rang a bell, and I guess that pretty much proves that the Xe driver is considered to be experimental for gen1 Xe.

so long,

Hias

IIRC the essential bit in the dtblob for ethernet is that you provide a (25MHz?) clock on GPCLK1

The dtblob dts files for CM1 and CM3 that we shipped in LE are here:

And you can get the official RPi dts file from here (you'd need to drop all blocks except for the pins_cm4s block and then add pin and clock setup for GPCLK1):

firmware/extra/dt-blob.dts at master · raspberrypi/firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware. -…

github.com

The RPi forums is probably the best place to ask about details

so long,

Hias

This is somewhat expected, the xe driver is for the Xe2 (and later) GPUs.

Since you have a first gen Xe you need to use the i915 driver - just remove the force_probe options from your command line, the kernel will then automatically use the correct driver.

Note that the kernel config explicitly mentions that support for first gen Xe in the xe driver is experimental:

linux/drivers/gpu/drm/xe/Kconfig at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

config DRM_XE
    ...
	help
	  Driver for Intel Xe2 series GPUs and later. Experimental support
	  for Xe series is also available.

so long,

Hias

H264 decoding, deinterlacing and analog audio output are all handled by the RPi's VC GPU - and deinterlacing HD video plus audio output is just too much.

Go to Settings->Player, set settings level to Expert and disable "Allow hardware deinterlace with DRM PRIME".

The RPi will then do deinterlacing in software (using BWDIF which will be higher quality, too) and free up enough GPU cycles for analog audio out.

I strongly recommend though staying away from the on-board analog output on RPis, even a 3 EUR/USD USB audio adapter will have significantly better audio quality and cause fewer issues.

so long,

Hias

Quote from vpeter

And here it is

Sorry, I wasn't aware of this thread when I implemented flatpak support

so long,

Hias

Quote from chewitt

The "throttled" message would be a thermal issue not a PSU issue. You're thinking of "undervolt" perhaps.

The throttled bits report both undervoltage and temp limit throttling, see eg [How to] Interpret RPi vcgencmd get_throttled

When it comes to USB it gets a bit more complicated:

The USB ports on RPi4 have a total 1.2A current limit (all ports combined) and if that's exceeded there'll be a voltage drop on the USB ports - but that won't show up in the throttled bits as long as the power supply can deliver the 1.2A for USB plus the power needed by RPi.

If there's a voltage drop on the USB ports pretty much anything can happen. Depending on the USB device it might lock up, go into a (temporary) error state resulting in kernel log errors or silently corrupt data on the USB HDD/SSD.

As a rule of thumb don't connect more than a single bus-powered USB HDD/SSD/DVD to the RPi, use a powered USB hub in between - and if you see odd issues connect all USB devices to the powered USB hub.

so long,

Hias

The nightly with the fix is now available:
https://test.libreelec.tv/13.0/Generic/Generic/LibreELEC-Generic.x86_64-13.0-nightly-20260602-9c34052.img.gz

so long,

Hias

Quote from joe65

gputemp has vanished on pure Intel since ~2 weeks (System Info => Video)

This is fixed by the PR as well and will be included in the next nightly.

so long,

Hias

I've managed to identify the culprit, it's our custom gputemp script which gets called whenever you open the player process info overlay or the system info window.

I've created a PR with the fix:

Generic: gputemp: use nvidia-smi only if an Nvidia card is present by HiassofT · Pull Request #11414 · LibreELEC/LibreELEC.tv

Running nvidia-smi on a non-nvidia system causes a long delay as nvidia-smi will try to load the nvidia kernel driver if it's not present.

github.com

so long,

Hias

Can you please test with the 20260511 and 20260512 nightlies and report back if resolution switching works with those?

https://test.libreelec.tv/13.0/Generic/Generic/LibreELEC-Generic.x86_64-13.0-nightly-20260511-f6935c9.img.gz
https://test.libreelec.tv/13.0/Generic/Generic/LibreELEC-Generic.x86_64-13.0-nightly-20260512-e916680.img.gz

I have a gut feeling that the issue might be caused by the Intel hack-patch that was added in the 20260512 nightly.

If you get the garbled screen in both nightlies please test with earlier nightlies between 20260504 and 20260511 and post the first version where the issue occurs.

so long,

Hias

Use DEVICE=Generic, that's the official name and gbm

so long,

Hias

Quote from JohnWayne111

will HyperHdr v22 will be available if the beta status has gone?

Yes, I've already tested early betas here (and reported issues). Just waiting for v22 final to be released.

so long,

Hias

LibreELEC doesn't use wayland (and also not pipewire) so the link you mentioned is not relevant to LE.

Currently there's no reliable way to use it without an external grabber, there's an experimental drm-vc4-grabber but it has known issues (kodi crash after a few seconds) and a PR that's supposed to fix those is in limbo for quite a long time now:

GitHub - rudihorn/drm-vc4-grabber: A screen grabber using the DRM for the raspberry pi.

A screen grabber using the DRM for the raspberry pi. - GitHub - rudihorn/drm-vc4-grabber: A screen grabber using the DRM for the raspberry pi.

github.com

I haven't tested this software grabber yet, instead I use a HDMI splitter plus grabber (which cost me about 40 or 50 EUR total, can't remember) with HyperHDR on my RPi5.

so long,

Hias

Quote from Nofan Tasi

Now shall I install current official Team LibreELEC 12.80.7.0 or (and test again) or wait for a higher next version?

No, wait for the next version, it'll be 12.80.7.1 and Kodi should auto-update to it when it hits our repo.

It usually takes a day or two from PR merge until addons are uploaded to our repos.

so long,

Hias

Quote from Nofan Tasi

Just curious: LibreELEC-Generic.x86_64-13.0-nightly size jumped from 300 to 500 megabytes

We added support for Nvidia cards (which were previously only supported via the Generic-legacy builds).

Generic: add support for Nvidia by HiassofT · Pull Request #11306 · LibreELEC/LibreELEC.tv

Runtime tested on Generic with a RTX4060

github.com

And, yes, the driver is unfortunately HUGE.

so long,

Hias

If you want to play around with the remote:

Simply "systemctl mask eventlircd" and disable the eventlircd udev rule by creating an empty .config/udev.rules.d/98-eventlircd.rules file - then reboot.

If you configure the "OK" button to send "enter" (via ir-keytable) the up/down/left/right buttons will work like cursor keys and "OK" like the enter key on a keyboard.

so long,

Hias