Posts by HiassofT

    This is rather odd, serial_ir is nothing you'd be using on RPi.

    That module is not included in default RPi kernel config but seems to be coming via the dvb drivers / media tree. Still, it shouldn't be loaded, even on x86 (where that driver is occasionally used) you need to manually load it via modprobe or modules-load.d

    Could you check if you have something in /storage/.config/modules-load.d or /storage/config/autostart.sh that would load that driver?

    so long,

    Hias

    Sorry for a rather basic question. I like to go through pages pretty quick, and use time skip often (repeat right arrow) during viewing. But with the setting above, when i click the arrows fast (ie, 4x) some are missed (ie 3x are recognized). what variable and which direction would i go to help resolve this? I have also lowered each of the above, and still has the behavior. Thank you.

    ir-ctl timeout is important, but if you use a NEC protocol remote presses quicker than 4 times a second (250ms) won't be recognized as distinct repeats - NEC protocol doesn't have a toggle bit like rc-5 or rc-6/MCE protocols. Use an rc-5 or rc-6/MCE remote if you want better response to quickly repeated button presses.

    so long,

    Hias

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

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


    so long,

    Hias

    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:

    Code
    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

    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

    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

    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


    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

    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