Arokhaerr I'm not aware of any noteworthy changes to the SSH server between LE12 and LE13 but perhaps delete any stored profile or connection in the app and recreate in case there are cipher changes. Using a normal computer, check SSH in to prove the SSH service is enabled/running and that password auth is allowed. If yes, perhaps clear any stored connection/profile in the app and recreate. We don't change certs after initial boot but the accepted ciphers can/do change over time (albeit not often).
Posts by chewitt
-
-
Feel free to test, improve, and merge.
It's the responsibility of the submitter to submit something that is mergeable, not the responsibility of the maintinainer to accept all changes submitted. Your goal is not aligned with our goals; I've commented on the pull-request.
-
Update with https://chewitt.libreelec.tv/testing/LibreE…_64-12.80.2.tar and check/test again. I've enabled some more kernel modules; I'm intentionally doing them in bits to see which ones make a difference (or not). Also share the URL generated by "pastekodi" (run from the SSH console) after updating so I can see the system log.
Information on IR remotes is here: https://wiki.libreelec.tv/configuration/ir-remotes but an RC6/MCE remote should basically work out of box. Worst case you might need to swap some buttons around via XML maps. If you have some other kind of remote you'll need to create a toml keymap (not hard to do).
I'd advise against Amlogic purchases due to no LE support on anything recent. RPi5 is nice. Mine just has some standoffs fitted to the board with plastic bits top/bottom to give some basic protection. It sits in a cupboard out of sight though so appearance and protection aren't important, and I use a BT remote so line-of-sight with an IR remote isn't required (CEC is disabled in the AVR as I have too many CEC capable devices connected and this only causes problems).
-
Merged. Should be in the repo in the next 24h.
-
Download the same file again. It's updated.
-
LE and RPiOS use the same kernels but RPiOS uses wpa_supplicant whereas LE uses iwd and the issue is proven to not occur when using wpa_supplicant. Reverting LE images to wpa_supplicant can be done but aren't going to entertain that idea as wpa_supplicant has its own set of very-legacy-code problems and the Linux community is keen to iwd mature and replace it. Signal strength is the most important factor as poor signal introduces all kinds of errors and iwd is probably not handling all of them as gracefully as it needs to; although a specific issue with WPA3 on Broadcom cards (which RPi boards use) was resolved and things have generally improved to the point where invalid-key is rarely reported now.
Cables are always best. External dongles or anything with a proper antenna beats the RPi on-board one.
-
Hauppague cards are generally supported well in recent-ish kernels. Cross fingers and roll dice
-
It was updating library DB files to the newer version (the image is LE13/K22).
I've enabled the CEC build option and pushed an updated image.
-
Update using this tar file: https://chewitt.libreelec.tv/testing/LibreE…_64-12.80.2.tar
I've enabled CONFIG_DRM_DISPLAY_DP_AUX_CEC in the kernel config. The CEC config for HDMI appears to be enabled already but on cheap devices there's probably an LSPCON providing HDMI output so technically it's a DP connection and enabling CEC for DP might be needed (although I'm guessing a little here).
-
According to https://cateee.net/lkddb/web-lkddb/ASUS_WMI.html CONFIG_ASUS_WMI=m depends on CONFIG_HOTPLUG_PCI=y which you are not defining so the option is removed (unset) when the defconfig is saved.
The patch below resulted in it being built:
Diff
Display Morediff --git a/projects/Generic/linux/linux.x86_64.conf b/projects/Generic/linux/linux.x86_64.conf index 7307fb40f2..f703fc3145 100644 --- a/projects/Generic/linux/linux.x86_64.conf +++ b/projects/Generic/linux/linux.x86_64.conf @@ -1679,6 +1679,7 @@ CONFIG_GENERIC_PCI_IOMAP=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y +# CONFIG_HOTPLUG_PCI_PCIE is not set CONFIG_PCIEAER=y # CONFIG_PCIEAER_INJECT is not set # CONFIG_PCIE_ECRC is not set @@ -1709,7 +1710,11 @@ CONFIG_PCIE_BUS_DEFAULT=y # CONFIG_PCIE_BUS_PEER2PEER is not set CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 -# CONFIG_HOTPLUG_PCI is not set +CONFIG_HOTPLUG_PCI=y +# CONFIG_HOTPLUG_PCI_ACPI is not set +# CONFIG_HOTPLUG_PCI_CPCI is not set +# CONFIG_HOTPLUG_PCI_OCTEONEP is not set +# CONFIG_HOTPLUG_PCI_SHPC is not set # # PCI controller drivers @@ -3663,7 +3668,7 @@ CONFIG_SENSORS_W83627EHF=y # # CONFIG_SENSORS_ACPI_POWER is not set CONFIG_SENSORS_ATK0110=m -# CONFIG_SENSORS_ASUS_WMI is not set +CONFIG_SENSORS_ASUS_WMI=m # CONFIG_SENSORS_ASUS_EC is not set # CONFIG_SENSORS_HP_WMI is not set CONFIG_THERMAL=y @@ -5550,7 +5555,7 @@ CONFIG_HID_A4TECH=y # CONFIG_HID_ACRUX is not set CONFIG_HID_APPLE=y CONFIG_HID_APPLEIR=m -CONFIG_HID_ASUS=y +CONFIG_HID_ASUS=m CONFIG_HID_AUREAL=y CONFIG_HID_BELKIN=y # CONFIG_HID_BETOP_FF is not set @@ -6286,7 +6291,11 @@ CONFIG_WMI_BMOF=y # CONFIG_APPLE_GMUX is not set # CONFIG_ASUS_LAPTOP is not set # CONFIG_ASUS_WIRELESS is not set +CONFIG_ASUS_WMI=m +CONFIG_ASUS_NB_WMI=m # CONFIG_ASUS_TF103C_DOCK is not set +# CONFIG_EEEPC_LAPTOP is not set +# CONFIG_EEEPC_WMI is not set # CONFIG_X86_PLATFORM_DRIVERS_DELL is not set # CONFIG_AMILO_RFKILL is not set # CONFIG_FUJITSU_LAPTOP is not set
You probably don't need these:
-
Wondering if there'll be any support for this going forward.
The C5 requires downstream vendor u-boot/kernel and amcodec support being hacked back into Kodi, so it will be possible to create an image if that's your thing. CE will probably offer support, but not LE, as we long moved away from that kind of horrid.
-
-
Do you have Kodi settings in basic mode? - the option to configure audio to a different HDMI connection from the video connection is hidden in basic mode, but visible in advanced/expert mode.
-
We will **pause further testing until a newer kernel (e.g. 6.8+) explicitly introduces framebuffer export improvements, writeback support, or enhanced plane access.**
LE13 (nightlies) are using Linux 6.12.x (LTS) for some time already and if you need to go even newer RPi devs have Linux 6.14 and 6.15 branches in their GitHub repo.
-
To boot LE you need:
a) Bootloader installed to the disk. Can be syslinux or Grub2 or whatever you are using for the multi-boot; with a configuration file somewhere (as defined by the needs of that bootloader) that creates an LE item and tells it where the KERNEL and SYSTEM files are to be found.
b) Boot files partition containing KERNEL and SYSTEM. Can be VFAT or EXT4 and 512MB or 1GB sized.
c) Storage partition. Must be EXT4 and whatever size you like for your needs. No files required as the OS will populate anything it needs on /storage on first boot.
The complicated bit is A and we don't support multi-boot setups because it's a pain in the rear to figure out what's needed and then support the resulting mess and inevitable deletion of Windows + Music Collection + Photo's of kids that happens when things aren't done right. When we say not supported we mean "we are not even remotely interested in touching that problem" so you really do need to go figure out that bit for yourself.
-
As far as I can see the ID's of the device are mapped to the right drivers and those have probed and loaded.
I don't have anything to suggest, other than emailing the linux-asoc mailing list.
-
The GBM/V4L2 video pipeline is completely different to the previous method used with RPi boards so the approach also needs to be different and zero-copy rendering brings inherent problems for the ambilight use-case. The same issue also exists with Allwinner, Amlogic, and Rockchip devices that use the same DRM framework in the same way.
lrusak did some initial work on screenshot support a couple of years ago: https://github.com/xbmc/xbmc/pull/18741 but IIRC this had a problem level of impact on rendering and the effort stalled. It might be acceptable to resurrenct that for the kind of ad-hoc screenshot usage but IIRC it's the wrong approach for 60fps video.
Our advice is (and has been since LE10) that people wanting to use Ambilight should use an HDMI grabber device. It's not as cheap as past methods, but it's simple and works everywhere.
-
The error message itself is misleading and wireless being wireless there's a large number of potential variables including poor signal which RPi boards are inherently prone to. Over time things seem to have generally improved though, and you're the first person flagging an issue in this forumn for some time.
LE13 nightlies are running newer kernels and lots of other bits. Perhaps make a test install on a spare SD card and see if that helps.