Posts by HiassofT
-
-
VDPAU has been deprecated for quite a while now, Nvidia's moved to the CUDA based nvdev/nvenc API.
As kodi doesn't support nvdec the nvidia-vaapi-driver is now used - kodi uses vaapi and the nvidia-vaapi-driver "translates" that to nvdec.
Nvidia RTX50XX (plus future models) aren't supported in LE as they would require a different kernel driver (which only supports very recent nvidia cards so we can't just switch to that as it would drop support for a lot of older cards).
Trying to support nvidia cards has been a huge PITA in the last year (even more painful than before) and is bloating our images a lot (all the proprietary nvidia libraries and firmwares are huge) so I wouldn't be surprised if we end nvidia support sooner than later.
so long,
Hias
-
Likely you pulled the plug too early - wait until firmware update in LE settings comes back with the "OK" dialog (this takes about half a minute or so), then reboot using the reboot option in kodi's power menu. Never ever just pull the plug!
On RPi5 the update is performed as soon as you choose "yes", the reboot is then only necessary to activate the updated bootloader.
so long,
Hias
-
The LE12.2 build just finished and is now available for download:
https://test.libreelec.tv/12.2/RPi/RPi5/LibreELEC-RPi5.aarch64-12.2-nightly-20251031-335d190.img.gzso long,
Hias
-
We've now added the iwlwifi (and rtw88/89 PCIe wifi) drivers in the LE12.2 and LE13 branches. If things go well you should be able to test with official nightlies from https://test.libreelec.tv/ in a couple of hours.
Note: we haven't included firmware files, you have to add them on your own. For the ty firmware variant the 6.12 kernel now seems to want the 89 api version:
Coderpi5:~ # modinfo iwlwifi | grep firmware | grep ty firmware: iwlwifi-ty-a0-gf-a0.pnvm firmware: iwlwifi-ty-a0-gf-a0-89.ucodeso long,
Hias
-
Thanks for the log!
The log shows you have hyperhdr running, better stop that to ensure it's not accessing the /dev/leds0 device node.
Also you seem to have some "99-com.rules" udev rules - what do you set up there?
We're building the kernel straight from the RPi kernel repo - only with modified config. AFAICT everything should be in place in our kernel so I have no idea what could be causing the issue. As the ws2812 driver doesn't log any errors/warnings it's hard to tell what the issue may be.
Device major/minor numbers shouldn't matter at all, they are dynamically allocated nowadays.
Before opening an issue on the RPi kernel repo better triple-check that it's not some configuration/setup issue on your side, eg try with a plain LE installation on a separate SD card with just the dtoverlay added - and nothing more. Also maybe try asking on the RPi forum first, the Interfacing section might be a good place.
so long,
Hias
-
Please provide a full log: ssh in, run "pastekodi" and post the URL.
I don't have any WS2812 LEDs here so can't test with real hardware, but just adding the dtoverlay with default settings shows both the rp1-pio and ws2812-pio-rp1 drivers being successfully loaded:
Coderpi5:~ # dmesg | grep rp1 [ 1.978635] rp1 0002:01:00.0: bar0 len 0x4000, start 0x1f00410000, end 0x1f00413fff, flags, 0x40200 [ 1.987721] rp1 0002:01:00.0: bar1 len 0x400000, start 0x1f00000000, end 0x1f003fffff, flags, 0x40200 [ 1.996988] rp1 0002:01:00.0: enabling device (0000 -> 0002) [ 2.003186] rp1 0002:01:00.0: chip_id 0x20001927 [ 2.395815] genirq: irq_chip rp1_irq_chip did not update eff. affinity mask of irq 161 [ 2.712353] rp1-firmware rp1_firmware: RP1 Firmware version eb39cfd516f8c90628aa9d91f52370aade5d0a55 [ 2.722320] rp1-pio 1f00178000.pio: Created instance as pio0 [ 12.224635] /axi/pcie@1000120000/rp1/spi@50000/wm5102@0: Fixed dependency cycle(s) with /axi/pcie@1000120000/rp1/spi@50000/wm5102@0/ldo1 [ 12.422735] ws2812-pio-rp1 ws2812_pio@4: Instantiated 60 LEDs on GPIO 4 as /dev/leds0```BTW: We can't build rp1-pio as a module as that would result in the RPi5 DPI DRM driver being built as a module instead of builtin to the kernel - which means DPI displays wouldn't have display output during boot. If building rpi1-pio as builtin indeed is the culprit then that's a bug in the rp1-pio or ws2812-pio-rp1 driver and should be reported as an issue on the RPi kernel repo.
so long,
Hias
-
Have you tried resetting the CEC settings to default? If in doubt, stop kodi and delete the CEC settings file (systemctl stop kodi; rm /storage/.kodi/userdata/peripheral_data/cec_CEC_Adapter.xml) and reboot.
LE 12.2 ships with a newer libcec (latest version 7.1.1 instead of the ancient 4.0.7 in LE12) and some of your old settings may be incompatible or wrong.
so long,
Hias
-
Not sure if we have some best practice guide where to put user scripts, you can store them anywhere in /storage, keep in mind though that only the .config and .kodi folders will be backed up by the backup/restore function in LE settings.
We have a "Showcase" forum here, guess that'd be a good place to present your scripts/settings
so long,
Hias
-
-
Unfortunately no, kodi uses a hardcoded set of button codes.
There is/was an attempt to improve kodi input handling and support remotes via keyboard input handling but it wasn't finished and hasn't been updated for quite a while now...
[input] fallback to direct libinput mapping by oliver · Pull Request #26039 · xbmc/xbmcDescription This is a possible fix for #16834 when using the GBM system. This approach adds a fallback mapping table, which is used when XKB cannot map a key…github.comso long,
Hias
-
You have to use the remote section of the keymap and map kodi remote button codes, not keycodes, to actions.
See the devinput section of /usr/share/kodi/system/Lircmap.xml to see how input key codes are mapped to button codes
so long,
Hias
-
Hmm, you seem to have masked the lircd.socket unit - that's not good, it's needed as lircd is a socket activated service and lircd-uinput starts it by connecting to the socket.
Remove /storage/.config/system.d/lircd.socket and also /storage/.config/system.d/multi-user.target.wants/eventlircd.service and /storage/.config/system.d/multi-user.target.wants/lircd-uinput.service (the latter two are already enabled by the system), then reboot.
so long,
Hias
-
Please post a full system log. After system bootup ssh in, run "pastekodi" and post the URL you got.
so long,
Hias
-
Setup a whitelist and enable "Adjust refresh rate" - see eg here https://wiki.libreelec.tv/configuration/4k-hdr (it applies to non-4k setups as well).
Also enable "allow double refresh rates" and/or "Allow 3:2 pulldown" if needed - this can help kodi picking the correct resolution if it doesn't have an exact match (but has 2 or 3:2 times the refresh rate).
If kodi can't find any matching resolution/refresh rate it will use the one that you configured for the GUI.
so long,
Hias
-
This doesn't look right, you also should see lircd-uinput running (and, yes, eventlircd also has to run):
Code# ps | grep lirc 489 root 0:00 /usr/sbin/eventlircd -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd 932 root 0:00 /usr/sbin/lircd --nodaemon /storage/.config/lircd.conf 933 root 0:00 /usr/sbin/lircd-uinput --add-release-events 2115 root 0:00 grep lircAs for key naming: you have to stick to the standard linux input keynames (eg KEY_LEFT etc) - see eg /usr/lib/udev/rc_keymaps/rc6_mce.toml
so long,
Hias
-
To enable lirc simply copy your lircd.conf file to /storage/.config/lircd.conf and create an empty rc_maps.cfg with touch /storage/.config/rc_maps.cfg then reboot.
Another option you can try is to use lircd2toml.py (it's included in LE) to convert your lircd.conf file to an ir-keytable toml file - this supports some additional protocols via bpf decoder and may or may not work with your remote. If it works, better use that instead of lircd.
so long,
Hias
-
BTW: I did a quick test with LE on a PC and verified that the PrepareForSleep dbus events (which hyperhdr is supposed to listen on) are properly sent on suspend/resume:
Code
Display More# dbus-monitor --system "type='signal',sender='org.freedesktop.login1',interface='org.freedesktop.login1.Manager'" signal time=1761147172.212817 sender=org.freedesktop.DBus -> destination=:1.15 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.15" signal time=1761147172.212914 sender=org.freedesktop.DBus -> destination=:1.15 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost string ":1.15" Broadcast message from root@hpmini on pts/1 (Wed 2025-10-22 15:33:04 UTC): The system will suspend now! signal time=1761147184.732127 sender=:1.0 -> destination=(null destination) serial=34 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true signal time=1761147191.650691 sender=:1.0 -> destination=(null destination) serial=38 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean falseI also checked our hyperhdr build and verified power management is properly enabled.
So I highly suspect this is some bug in hyperhdr code, you might want to bring that to the attention of the hyperhdr author's - it should work on LE just like on any other linux distro.
so long,
Hias