Posts by HiassofT

  • LE9.0 remote configs ir-keytable Amlogic devices

    BTW: before you start creating a keymap on your own have a look what's already shipping with LE in /usr/lib/udev/rc_keymaps.

    Xbox 360 and Xbox One are already there, so you can just put the name in rc_maps.cfg and don't need to create an rc_keymaps/MYREMOTE file first. Or you can use these as a template in case you want to modify something.

    so long,

    Hias

  • LE9.0 remote configs ir-keytable Amlogic devices

    Quote from atreyu

    Guys, what would be the best way to configure both a NEC and an RC-6 remote ?

    I have been reading and trying without any luck.

    Is it even possibe to have both an rc-6 and a nec driven remote activated at the same time?

    Thanks for any pointers.

    Yes, that's possible - and default LibreELEC configuration uses that to support both rc-6 remotes like MCE and NEC remotes like Xbox 360, One (crap, I always mix these up) Wetek Hub etc out of the box.

    All that's needed is that you put both RC6 and NEC into the header, after "type:". See for example the /usr/lib/udev/rc_keymaps/libreelec_multi_amlogic file:

    Code
    # table libreelec_multi_amlogic, type: RC6 NEC
# rc6_mce
0x800f0400 KEY_NUMERIC_0
...
# wetek_hub
0x77f1 KEY_POWER
0x77f2 KEY_HOME

    So, simply create a separate keymap for each remote and then combine the content into a "multi" keymap file and use a header like above.

    so long,

    Hias

  • LE9.0 remote configs ir-keytable Amlogic devices

    Quote from Gregoir3


    This pointed me into the right direction. Unfortunately I have not figured out (yet) how to use <mod="longpress"> which would add a lot more functionality.

    Longpress in kodi only works for keyboards, not remotes that reach kodi as lirc events.

    You can disable the Linux event -> lirc event translation, eg by creating an empty eventlircd udev rule:

    Code
    : > /storage/.config/udev.rules.d/98-eventlircd.rules

    then the remote buttons/keys reach kodi like standard keyboard input.

    There's one drawback though: kodi currently can't deal with a lot of keycodes used on remotes, eg KEY_OK, KEY_CHANNELUP/DOWN and a bunch of others won't work. So you'll have to use different keycodes in your keymap (eg KEY_ENTER instead of KEY_OK).

    so long,

    Hias

  • Sudo no available

    IR remotes are really easy. Just add dtoverlay=gpio-ir to config.txt (you may need to add the gpio_pin parameter if you connect the IR receiver to some other GPIO than the default 18).

    If you are using an MCE or one of a few other standard remotes then you are already finished.

    If it's some other remote you may need to set up an ir-keytable configuration - see the wiki Infrared Remotes [LibreELEC.wiki]

    And if it's a really odd remote with a non-standard IR protocol you may need to use userspace lircd instead - i.e. create a .config/lircd.conf file - and in LE 8.2 also enable lirc in LE settings.

    Everything's on board already, no need to tinker.

    so long,

    Hias

  • LE9.0 remote configs ir-keytable Amlogic devices

    To get scancodes of other protocols than NEC and rc-6 (which are the current default setup) you can also simply use

    ir-keytable -c -p all -t

    But note that unfortunately ir-keytable -t doesn't show the protocol for decoded scancodes. That's a pity because for proper operation the protocol has to be included in the header of the keymap file.

    So, in general, when creating a keymap file it's best to manually set a single protocol, eg

    ir-keytable -c -p nec -t

    A lot of the boxes from asia seem to ship with NEC protocol remotes, so -p nec is a good start. If that doesn't work try -p rc-5 or -p rc-6, these are also very popular protocols. If you still get nothing try the other ones.

    so long,

    Hias

  • Sudo no available

    Changing /flash/config.txt entries on RPi is rather safe. Even if you completely mess it up and have a non-booting RPi you can simply put the card in a reader on your PC, clean it up, and have a working setup again.

    If you want to hook up a DAC, GPIO IR receiver and an LCD the bigger problem is that most HATs on RPi don't give you easy access to the unused GPIOs (and sometimes you even don't know which ones are unused). So that typically involves soldering some wires to the GPIO pins on the HAT or RPi.

    I'm regularly using a sound card (the Cirrus Logic Audio Card) and a GPIO IR receiver on RPi. Fortunately the sound card brings out the unused GPIOs to a separate header block.

    A few days ago I tested with a HD44780 compatible VFD, connected via a I2C expander but the I2C pins aren't grought out separately on the card. I added a 40-pin header to the soundcard in my testing setup some time ago (to easily access all signals) so getting to the I2C pins was easy. Without the header I would have needed to solder 5 wires to the pins.

    Changing config.txt was easy though, I2C was already enabled via the sound card overlay, otherwise a simple "dtparam=i2c=on" line would have done it.

    So, don't be afraid of config.txt, most of the changes are simple and hard to mess up.

    so long,

    Hias

  • Sudo no available

    warp2 no problem at all and I certainly don't take it as an insult.

    Actually some of the design decision of OE/LE, like the read-only rootfs without overlayfs and the lack of a package manager, seemed and partly still seem a bit odd to me.

    But I also have to say the approach makes sense for what LE is meant to be - an OS for running kodi that is simple to use for users.

    We use kodi's addon system instead of a separate package manager - that makes it simple for users to install additional stuff, as they only have to deal with a single UI (kodi) and we don't need to add a package manager ourselves and write a GUI for it.

    The root filesystem being read only also means that chances of users messing up the whole system (whoops, I accidentally replaced/deleted libc) are slim. Users can't easily shoot themselves in the foot and we have less support issues.

    OTOH we developers often have to jump through hoops as well to work with the current setup.

    Last year I implemented support for optional kernel module packages (mainly used for DVB drivers) and the lack of overlayfs support (Amlogic kernel is too old and doesn't include that) or a package manager (kodi's addon/dependency system is rather simple) meant we had to put a lot of thought into how we could practically use that. It also involved quite a lot of discussion and design decision as the goal was to have something that's both easy to use for users and support for us devs.

    As we don't have plans (and the resources) to drastically change the OS design of LE it's best you familiarize yourself with the possibilites how you can adapt LE to your needs:

    1. Some things may already be supported and you just need to find/change the right config file
    2. You can create an addon if you want some additional programs / services / ... added to LE
    3. Using docker is an alternative to #2
    4. If none of the above works for you you'll have to adapt the LE source code and build your own version

    so long,

    Hias

  • Sudo no available

    ssh root@libreelec will log you in as full root user. But keep in mind that the root filesystem (/etc, /usr ...) is read-only and can't be changed. /flash is mounted read-only as well, but you can modify the files there after you remount it rw.

    so long,

    Hias

  • [solved] No driver for ir receiver is loaded.

    There's nothing you need to configure, this remote is supported out of the box in LE. Just tested that on RPi3 running LE 8.2.2.

    Keep in mind though that the IR receiver only works with the remote it came with. When you press a button on the remote both the LEDs on the remote and on the IR receiver dongle should flash.

    so long,

    Hias