Posts by HiassofT

Quote from Poida

So is it possible to add a udev rule for the ir-keytable settings or does that have to go in autostart.sh ?

Both variants will work but I recommend creating a udev rule.

If you connect another device with an IR receiver, eg a DVB USB stick, autostart.sh may configure the wrong receiver (rc names can change across reboots). With a udev rule you can apply the settings to all receivers, or only meson-ir.

If meson-ir is your only IR receiver then it doesn't really matter, use what's easiest for you.

so long,

Hias

autostart.sh should work, but it' be better to create a udev rule for that. Copy /utsr/lib/udev/rules.d/70-input-repeat.rules to /storage/.config/udev.rules.d, and then add this line at the end (all in a single line, after the LABEL="end" line):

ACTION=="add|change", KERNEL=="lirc*[0-9]", DRIVERS=="meson-ir", RUN+="/usr/bin/ir-ctl -d $devnode -t 50000"

so long,

Hias

Quote from zbigzbig20

bubblegum57 , yes I know. I tested many configurations with repeats and adjusted it little bit . Now is better but still not this same like in older build. I will have to get used to it.

Another knob you can turn to improve remote response is the idle timeout. By default it's set to 200ms on Amlogic / meson-ir, which is quite long - other IR receiver drivers use 125ms.

This value determines how long it takes until Linux recognizes that you released a button. By lowering this value you'll get faster response to very short button presses and also the repeat delay will work more accurately (and you can set it to lower values, if you like).

As a rule of thumb 50-100ms should be safe, you can also try going down to 20-30ms. Low values can be problematic when the system is loaded and timeouts lower than 20ms will most certainly break IR reception completely. I'd start with 50ms and then test and adjust it to your liking.

You can change the timeout with ir-ctl -t , but note that the value is in microseconds. So, for 50ms you have to use a value of 50000:

ir-ctl -t 50000

so long,

Hias

The rc-map-name isn't that important, it defines which keymap the kernel should load (if you leave it out it'll default to rc-rc6-mce). As we'll usually override that via rc-maps.cfg in userspace you can just ignore that.

In the gpio controller block you setup a pin configuration to configure a pin as GPIO.

This GPIO configuration is then referenced in the gpio-ir-receiver block via the pinctrl property and activated when the ir-receiver module loads.

The gpios property in ir-reciever is also important as that will tell the gpio-ir-receiver which gpio to use. It has to match the GPIO referenced in the pinctrl handle.

so long,

Hias

Here's a script that should simplify that task: Install or remove addon from command line

so long,

Hias

Tinkerboard / Rockchip doesn't support device tree overlays like RPi. Also there's no config.txt on these devices.

You'll have to create your own .dtb file, eg by applying the needed changes to the dts/dtsi files in the kernel tree and then compiling your own LibreELEC image or by decompiling/modifying/compiling the existing dtb using the devicetree compiler.

Sorry, I can't help you there, as I don't have a Tinkerboard and am not really familiar with the RK3288 devices.

so long,

Hias

Use the gpio-ir-recv driver and activate it in device tree. Guide for configuring the userspace part is in the wiki: Infrared Remotes [LibreELEC.wiki]

so long,

Hias

IIRC this error is caused by building with a non-UTF-8 locale (eg LANG=C or LANG=POSIX). Check you are using a UTF-8 locale like en_US.UTF-8

so long,

Hias

I'm building on Debian Stretch (amd64), works just fine as well.

so long

Hias

You can avoid colons in filenames by selecting advanced or expert level in Tvheadend, then going to Configuration -> Recording and tick "Use Windows-compatible filenames" in the recording profile.

so long,

Hias

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

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:

# 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

Quote from boot2k3

HiassofT, Is there any example of usage? What files to modify in this case for longpress actions?

By default you'll have longpress-enter = context menu and a bunch of other stuff. Just follow the kodi wiki Keymap - Official Kodi Wiki if you want to change that.

so long,

Hias

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:

: > /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

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

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

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

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