Jump to content

usual user

Members
  • Posts

    317
  • Joined

  • Last visited

Community Answers

  1. usual user's post in [HELP] LYRICS MONITOR PROJECT was marked as the answer   
    The hard work is already done, the kernel enumerates your IR device. Basically, only a suitable keymap is missing to emit the key codes you want. Each IR remote control sends different scan codes and each user expects different keycodes that are triggered at the touch of a button, so it is up to each user to create a corresponding keymap. Use ir-keytable -s rc1 -tp all from the v4l-utils ackage to determine the scan codes and assign them a keycode in e.g. a MXQ-PRO-4K.toml (man rc_keymap). If the MXQ-PRO-4K.toml located in the /etc/rc_keymaps directory is also registered in /etc/rc_maps.cfg, it will be loaded at system startup and the remote control will work out-of-the-box, e.g.:
    * rc-empty MXQ-PRO-4K.toml  
  2. usual user's post in Converting file to ISO was marked as the answer   
    I don't know Android and can't therefor help here, but I'm sure an experienced Android user can also use it to transfer an image to an sd card. However, if you are able to write an image to a USB flash drive, use a micro SD to USB adapter with a device whose system you are familiar with to write to an SD card. It is then the same procedure that you already know.

  3. usual user's post in Odroid N2+ - Forever Circle was marked as the answer   
    I have prepared an extlinux.conf. Mount the Armbian SD card partition and create an /extlinux directory in the root filesystem of the Armbian SD card. Then copy the attached extlinux.conf in.
    Download this  kernel package and unpack it with this command in your Armbian SD card /usr/lib/modules/ branch:
    tar -C ${mountpiont}/usr/lib/modules/ -xzf 5.19.0-0.rc6.46.fc34.aarch64.tgz Boot with the SD card and report if this changes anything.
  4. usual user's post in Muxing GPIO on Hummingboard i2eX on 5.x kernel was marked as the answer   
    IMHO I think from version 5.10.0 the path won't change again because generic node names have been around since then. Therefore, the same DTBO can always be applied. But as long as the hardware setup doesn't change, there's no reason to ever change the DTB. Therefore, after an update, restoring the DTB from a persistent location  would also be an option.
    But I guess you will have more fun to keep having the boot.scr magic in place. And tinkering with boot.scr magic opens even the option to load the DTB from the persistent location direct or choose a different DTB file name that wouldn't be overwritten.
×
×
  • Create New...