If you flip back to an image from https://test.libreelec.tv/ or the Python38 folder in my share those images are Linux 5.17.x - and the current ones in my share are Linux 5.18-rc2. If the keyboard works in the older image there's either a defconfig change or something hinky with one of the patch series I've picked into the 5.18 branch; which narrows the scope.
Thanks for confirming the remote works. I'll have a poke at WiFi things over the weekend.
The most common cause of "SSH refusal" is old versions of PuTTY on Windows (ciphers changed, no longer compatible) but that's rarely the issue with macOS/Linux clients. Did you enable "disable password auth" in LE settings?
CE should be functionally more complete than LE, but whatever boots and works out best for you is the one to use 
I posted an updated 'box' image to my file share. WiFi might need some more juju/tweaking to get working and I'm not sure what the issue with keyboard could be. In theory the IR remote should now work? .. and hopefully the BT stuff no longer shows up in dmesg. Please update and share "dmesg | paste" again.
I don't think you can do this in LE, but it may be possible in the Raspberry Pi OS which supports multi-display output.
Linux support is all about what chipset is used in the card, and whether that chipset has (PCI) drivers available. You need to start by telling us what the chipset is .. else we can only guess and then the answer is "maybe it works, maybe it doesn't" .. the other option is to boot LE from a USB stick and see for yourself.
The obvious Q is .. do you actually have 4K60 media (other than test media)? .. If the answer is 'no' then don't worry about something that you don't need. Most people do not need 4K60 modes. NB: Some TVs only support 4K60 on specific ports .. no idea about the C1 but it might be worth experimenting with different ports and seeing if needs to be enabled in menus on the TV side.
systemctl stop kodi
systemctl stop eventlircd
ir-keytable -p nec -t^ run the above commands over SSH to put the IR receiver in raw/test mode, then press remote keys one at a time starting top-left and going across then top-down on the factory remote until you have all keys recorded. It would be super helpful if you copy/pasted the keys into a text file and appended notes on what the keys look like; most are obvious, some might need a description. From this I can create a keymap that should get the remote working out of box. NB: I can see the older amremote keyfile in some remote keymap repos, but this document codes for more keys than the remotes I see in vendor pics have, and the codes generated by the upstream kernel are likely different, so best to get them fresh in the right format.
I'll make a guess at the LED setting. I suspect it's orange-red in off/standby and blue when on?
The dts is still inheriting something to do with Broadcom SDIO chips from somewhere, hence it's not probing for the Realtek WiFi chip. I will have a look and see what I can find.
NB: I don't see any mention of BT on the vendor specs, so is this a USB device that you added?
date -d "@$(( $(busybox date +%s) - 86400 * 14 ))" +%d/%m/%Y^ from https://stackoverflow.com/questions/4852…-date-x-day-ago .. not tested but I think should work.
The issue is not whether you can install LE on it (maybe) but whether it runs any good once it's installed. Old laptops are generally slower, noisier, with worse media support, and use more power than an older Raspberry Pi2/3 board. Experimenting is $free though 
Flirc requires the USB ports to be powered. Once you turn the board off, the USB is not powered so you cannot turn on again. Apart from that the flirc receiver is awesome.
bertiera please install (or update to) https://chewitt.libreelec.tv/testing/LibreE…85.0-box.img.gz for testing. I've added a device tree specifically for the box (meson-gxl-s905l-venz-v10.dtb) which should get WiFI working at least.
Does the box have power LEDs or power buttons on the case?
Is there an IR remote for the box? If yes, what keymap is used?
Looks interesting and makes sense for industrial users. If it's an official RPi Foundation created module? we can probably get a sample sent to HiassofT who has my Slice3 box in his collection since last summer now. That said, there are now only ~45 Slice boxes showing in stats (down from ~100 pre-Covid) so it's probably not high on the to-do list.
RPi has no native IR capability so needs an additional device with independent power and IR receiver that can control the main power to the board, either by being inline to the normal power connector or through driving power input pins on the 40-pin connector. It is not possible to use a GPIO receiver because the GPIO pins on the 40-pin connector need power before they can receive anything.
Our normal response would be that the 2GB RPi4 is the minimum RPi4, but that's considering 4K support which you probably don't/won't need in a space constrained RV installation. It has newer/better/more-efficient design and considerably more CPU grunt which is always a good thing. It also allows you to run LE10/LE11 so is more future proof (we already dropped support for Pi0W) and you'll have native HEVC hardware decoding. As long as it's not a crazy price it would definitely be an improvement. Then again, so would an RPi3B+ which you might be able to pick up cheaper/easier somewhere. Not as future proof, slower, and similarly 1GB RAM constrained but still a worthy bump.
Some of their containers are deliberately missing from the 'repo' list but I'm not aware that's one of them. There's no harm in trying to use it .. if it doesn't work just rm the container.
I don't maintain Rockchip stuff, but I add boards and such to Amlogic frequently, so:
https://github.com/chewitt/linux/commits/amlogic-5.18.y <= my kernel sources
https://github.com/chewitt/u-boot/commits/amlogic-2022.01 <= my u-boot sources
https://github.com/chewitt/LibreELEC.tv/commits/amlogic <= my LE sources
There are lots of previous examples of devices being added in GitHub.
It will either fix the issue or it won't .. so easy to test and try
LE patches generally follow <package>-<number>-description.patch but it depends on who created them and where they are used, e.g. for Amlogic kernel stuff I'm generating patches using "git format-patch" so things are number sequenced; other maintainers bundle patches together into large sets (which I don't like, but each to their own). Regardless of the naming convention the build-system applies patches in alphanumeric sequence.
If you intention is to submit the patches to our git repo; be advised that we will not accept/merge them unless we can see the same patches on a kernel and/or u-boot mailing list with acks from maintainers, i.e. we will accept a backport of an upstream accepted patch, we will not accept an orphan patch that only exists in LE (else we will never get to drop the patch in a future kernel/u-boot bump).