Posts by HiassofT

    Audio is a bit tricky.

    It's best to leave the EDID of the second HDMI port as is (using "getedid create" to fetch and force the EDID read from the AVR etc is fine), so it's using the info from the connected AVR/audio extractor/... - it you use some display mode not supported by the AVR, force some speaker allocation that doesn't match what's connected to the AVR etc things will go south.

    For the EDIDs used by the first HDMI port / monitor it's best to create 3 different ones for 2.0, 5.1 and 7.1 setups (this is eg also what my HDFury VRROM offers in it's built-in EDIDs).

    Enabling higher sample rates than 48kHz or compressed formats like AC3, DTS, MLP etc shouldn't hurt but keep in mind that there are audio bandwith limitations on the lower res modes. 720p50 and above will do 192kHz 8ch fine, but modes below are quite limited (eg 640x480p60 only allows up to 8ch 48kHz or 2ch 192kHz) - IIRC there's some info about that in HDMI or CEA specs.

    If you use some HDMI audio extractor or similar (or even just a TV/monitor with audio capability) you'll also have to test if it actually works with the custom modes you added - some may only work fine with the standard HDMI modes but not with anything else.

    so long,

    Hias

    There isn't really anything we can do here.

    Modifying EDIDs would be something that needs to be done deep down in the linux kernel and that has a high risk of breaking things - just look at the cheap chinese HDMI audio splitters which modify EDID on the fly and break stuff because they didn't get it 100% right.

    Also adding modes that are not supported by a monitor may at best confuse users (I did a test with your EDID and my monitor didn't like 1440 × 1080 and 640 × 480 96Hz modes - signal out of range) or even worse interfere with kodi's whitelist because it may pick one of the additional modes instead of the actually supported modes reported by the display.

    The way forward is that you create a curated, known working set of EDIDs that pepole can choose from - similar to what HDFury is doing, see eg https://hdfury.com/tools/HDfury_EDID_collection.zip

    People can then pick one of those EDIDs that match their setup (eg either 1440x1080 or 640 × 480 96Hz), verify on their own that it really works with their display device and use one of the standard methods to inject it - either the edid override you get "for free" with linux, with an external "EDID fixer" device like the HDFury Dr.HDMI, VRROOM or similar ones, or by patching/reprogramming the HDMI sink (the latter would risky and often might not be possible to do though).

    so long,

    Hias

    I couldn't find any info what the Hifiberry folks changed between rev 2.1 and 2.2 but I found a post where a user got his Digi+ pro working with a slight hardware modification - something similar might work with the Digi2 Pro as well:

    https://support.hifiberry.com/hc/en-us/community/posts/15842018863261/comments/16381227323677

    From the looks of it Hifiberry messed up their hardware design and I'm wondering why they didn't wire up the WM8804 reset to a GPIO pin like outlined in the reference design in the WM8804 datasheet, this likely would have avoided the powerup issues.

    The Linux driver supports this and the Allo DigiOne and the Cirrus WM5102 dtoverlays use this, just not the Hifiberry and other WM8804 based SPDIF soundcards.

    so long,

    Hias

    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

    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:

    Code
    rpi5:~ # modinfo iwlwifi | grep firmware | grep ty
    firmware:       iwlwifi-ty-a0-gf-a0.pnvm
    firmware:       iwlwifi-ty-a0-gf-a0-89.ucode

    so 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