Posts by HiassofT

    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:

    Code
    rpi5:~ # 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

    Showcase

    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/xbmc
    Description 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.com

    so 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

    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 lirc

    As 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:

    I 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

    What exactly did you do with the suspend script and what do you mean by "it didn't work"?

    After adding the systemd service file to /storage/.config/system.d you have to adjust it (if you changed the webui port number in hyperhdr) and then use "systemctl enable NAME_OF_THE_SERVICE_FILE" to enable it.

    There are two reasons why I didn't include the suspend script in the addon:

    First of all the addon system doesn't support multiple systemd units/services per addon so only the main one (service.hyperhdr) would ever get enabled automatically.

    Second, the suspend systemd file contains hard-coded port numbers of 8090 which won't work anymore (and could upset any other service running on that port) if you change the port number in the hyperhdr configuration. That's quite a PITA, even if you change it it would get overwritten on every addon upgrade.

    Therefore, just use the manual approach, you only have to do it once after installing and it'll survive addon updates as well.

    PS: I can't help testing / verifying if the suspend systemd service works as I don't have any LE systems that support suspend/resume here.

    so long,

    Hias

    Thanks a lot for reporting back, and glad to hear it's working for you, too!

    You can safely ignore (and actually should dtop) the ancient Linux patches, they are no longer needed nowadays.

    The mmc patch dates back long before we switched to reference the flash and system partitions by UUID, when the EMMC/SD card device ordering still mattered - with UUIDs it doesn't matter if the EMMC is /dev/mmc0 or /dev/mmc1.

    The cs4265 patch also predates changes to the upstream cs4265 driver and isn't needed anymore.

    And the alsa card conf was only needed for kodi so it recognises an IEC958/SPDIF capable device to allow AC3/DTS passthrough via Toslink(SPDIF. A few years ago I looked into improving the (incomplete) SPDIF support but realized a lot of important bits were missing in the cs4265 driver to transmit proper channel status information - then gave up and shortly afterwards SPDIF got broken again in the cs4265 driver due to changes in the upstream code. So better use HDMI if you need/want to pass through AC3/DTS/..., receivers with only SPDIF input are also quite rare today.

    so long,

    Hias

    Please give this slice-drivers branch a try: https://github.com/HiassofT/slice…/kernel-5.10%2B

    And here's an LE13 branch that pulls in the driver for RPi2 (you'll need to adjust the RPi4 options for your CM4s): https://github.com/HiassofT/LibreELEC.tv/tree/le13-slice

    A few years ago I tried to clean up the slice (soundcard) driver, I dug out the branch again and noticed a couple more fixes are required now and added those today (I also ran into the distorted sound issue).

    The RPi2 LE13 build worked fine on my Slice with CM3 with just dtoverlay=slice added to config.txt (this enables audio, IR and the RTC), analog audio out sounds fine now.

    Note: SPDIF out doesn't work since a change to the cs4265 upstream driver some years ago, I haven't looked at that.

    I also didn't care about the dt-blob.bin files from the slice-firmware repo, using the blobs from old Slice images works fine to get USB/ethernet working - you may need to create your own dt-blob for CM4s.

    so long,

    Hias