Posts by chewitt

  • Lirc USB dongle Gen1, setup application search

    Quote from chewitt

    there's a flirc_uril add-on in the LE add-on repo (install then reboot to use it)

    The same flirc_util add-on is available for RPi3 and our Amlogic image (AMLGX) running on an N2 board. In both cases you install the add-on and reboot (until reboot ^ the binary is not in $PATH and will not be found) and then run "flirc_util" and the binary will output a bunch of info, for example:

    Code
    RPi5:~ # flirc_util 
flirc_util version 11d52588b5a4b3e5c88825888e18ef03ce8658ac [11d5258+]
 Firmware Detected
 FW Version: v4.6.3v4.6.3
    SKU:     Flirc 2.0 [dori]
    Branch:  master
    Config:  release
    Hash:    0x93A109D3

    ^ hardware detected.

    Quote from MrNice

    I understand Fliirc command doesn't exist, only flirc_util, not easy to record IR codes. Am I right?

    I'm using a macOS laptop and there's a simple macOS (and Windows) app for updating the firmware and configuring flirc dongles (easily downloaded from the flirc website) and for that reason I've never bothered or needed to use flirc_util and cannot speak for how easy or complicated it is to use.

    If you are sat behind a computer with macOS or Windows and a USB port. Are you using the right tool for the job?

  • Which version should I try for the old Amlogic S905(X) Plum-like box

    The AMLGX "box" image should work. Most devices with an RTL8189 WiFi chip seem to be S905 (no X) boards and the p200 or p201 device-tree files should work. If the device is S905X then start with p212 Read https://wiki.libreelec.tv/hardware/amlogic first as the instructions for AMLGX are different to other distros and older LE images that use the legacy (vendor) kernel.

    The test images here: https://chewitt.libreelec.tv/testing/ have support for the RTL8189 wifi chip. LE release images do not.

  • Lirc USB dongle Gen1, setup application search

    The "flirc_util" add-on (complete with flirc logo) is in our repo under 'Program Add-ons' and testing it against your flirc hardware will take 2 minutes. If your flirc hardware shows an error or is flagged as unsupported by flirc software you need to contact flirc, because it's their software. All LE did was compile code from https://github.com/flirc/sdk and package it as an installable add-on.

    I only have v2 flirc hardware and "it works for me" so /shrug

  • Lirc USB dongle Gen1, setup application search

    I assume you mean "flirc_util" and the flirc USB IR receiever device?

    If yes, there's a flirc_uril add-on in the LE add-on repo (install then reboot to use it). If for some reason that doesn't work with the flirc USB hardware that you have, contact flirc support and get them to investigate and fix that, and then we can update the add-on.

    There are also Windows/macOS/Linux (Debian based distros) installers downloadable from the flirc.tv website.

  • [Orange Pi 3 LTS] WiFi Support

    This shows how packaging could be done: https://github.com/Ran-Thegoth/uwe5622

    Might be a newer version? https://github.com/SUISHUI/uwe5622_driver

    This seems to have lots of patches: https://github.com/misuzu/uwe5622-nixos but also shows the driver has issues on recent kernels (would be normal for a downstream vendor driver).

    Some Armbian fixes: https://github.com/armbian/build/pull/7615

    However if you have no intention to work on improving the driver or even working your (not our) draft PR into better shape there's no point in leaving it open to rot on GitHub, so I've closed it.

  • [RPi4] FTPS not working on LE13 Nightly

    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).

  • [x86-64] HDMI-CEC not working on Intel N100

    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).

  • [RPi3] WiFi Broken (Invalid Key)

    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.

  • enable asus wmi and asus nb wmi in kernel

    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:

    You probably don't need these:

    Code
    CONFIG_SENSORS_ASUS_EC=m
CONFIG_ASUS_LAPTOP=m
CONFIG_ASUS_WIRELESS=m