Posts by HiassofT


    Thanks, this is looking interesting:

    Code
    Event: time 1493835120.131142, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f2421
    Event: time 1493835120.870720, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f241e
    Event: time 1493835121.486192, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f2420
    Event: time 1493835122.144904, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f241f
    Event: time 1493835123.086740, type 4 (EV_MSC), code 4 (MSC_SCAN), value 800f2402

    The scancodes (value in the lines above) are looking similar to the rc6-mce scancodes, except they start with 0x800f2 instead of 0x800f0. Here's a snipped from /usr/lib/udev/rc_keymaps/rc6_mce:

    Is there maybe some switch or key-combination on your remote to switch between different "remote addresses" (like on old VCR remotes where you could switch between VCR1 and VCR2)?

    You could also try downgrading to LE8.0.0 but I don't think that'll change much - can't remember there being any changes in kernel rc-6 decoding between the 8.0.0 and 8.0.1 kernels.

    so long,

    Hias


    Not some more protocols was enabled, but the remote still doesn't work.

    Here the url's.
    jigA
    EdZj
    ifdF
    EOeC

    Thanks once again..

    /Söder

    Could you repost the ir-keytable output? I'm always forgetting we need 2>&1 there :)

    Code
    ir-keytable 2>&1 | paste

    ir-keytable -r output and dmesg/journalctl output is looking fine, not sure what's going wrong.

    BTW: please also try to install the "System tools" addon (from the LibreELEC repository), then stop kodi and eventlircd and do a test with evtest

    Code
    evtest


    select the event device corresponding to your remote and press some keys, then post the output here

    so long,

    Hias

    With mode2 outputting something we know that your remote and the IR receiver is working, but somehow it's not decoding the signals.

    Make sure lirc is disabled in LE settings, reboot once then ssh in and post the output of the following commands:

    Code
    ir-keytable | paste
    ir-keytable -r | paste
    dmesg | paste
    journalctl -a | paste

    so long,

    Hias

    Could you tell us more about your setup, did you add special config files, how are you starting irexec, did you update LibreELEC or something else before it stopped working? Have you actually been running lircd before, i.e. was lirc enabled in LE settings (irexec can work without lircd, too).

    With an MCE remote and the builtin receiver it's generally recommended to disable lirc. The kernel then takes care about decoding the remote signals. Lirc is only needed for remotes with odd protocols that aren't supported by the kernel.

    First check with irw:

    Code
    irw


    This checks the remote buttons right before they enter kodi. If you see buttons here, check with kodi conf.

    If you are using lirc to decode remote buttons (check with ps if lircd and lircd-uinput processes are running) you can use irw to see if lircd is working correctly:

    Code
    irw /run/lirc/lircd-lirc0


    if this works, then either lircd-uinput or eventlircd aren't working correctly.

    If you get nothing, test with mode2 to see if the IR receiver receives any signals:

    Code
    mode2

    In case you are not running lircd you first have to stop kodi and eventlircd - if they are running they'll interfere with the tests.

    Code
    systemctl stop kodi
    systemctl stop eventlircd

    Run ir-keytable to see if the kernel IR decoder is setup properly. The output should look like this:

    Code
    LibreELEC:~ # ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event1) with:
            Driver gpio-rc-recv, table rc-rc6-mce
            Supported protocols: unknown other lirc rc-5 rc-5-sz jvc sony nec sanyo mce-kbd rc-6 sharp xmp
            Enabled protocols: lirc nec rc-6
            Name: gpio_ir_recv
            bus: 25, vendor/product: 0001:0001, version: 0x0100
            Repeat delay = 500 ms, repeat period = 125 ms


    Check that you have the "rc-rc6-mce" table and "nec" and "rc-6" listed amongst the enabled protocols.

    Also test the kernel can decode the remote signals:

    Code
    ir-keytable -t

    If you still don't see anything and lirc is listed under supported protocols you can use "mode2" as above as well to check if any IR signals are received.

    so long,

    Hias


    Interesting. This looks like eventlircd isn't picking up the input events from lircd-uinput and instead kodi is processing them - which can't handle KEY_OK.

    Which system are you using, is this x86?

    Pllease post some logfiles and infos about your system:

    Code
    dmesg | paste
    journalctl -a | paste
    lsof | grep /dev/input | paste
    grep . /sys/class/input/event*/device/name | paste

    Then, we need some infos about the lircd-uinput event device. First find out which of the event devices is the one of lircd-uinput:

    Code
    grep -l lircd-uinput /sys/class/input/event*/device/name


    You should get a single line like this /sys/class/input/event1/device/name

    Then run the following two commands, replace event1 with the eventXX name you got from above, and post the output:

    Code
    udevadm info -a -p /sys/class/input/event1 | paste
    udevadm test -a add /sys/class/input/event1 2>&1 | paste

    so long,

    Hias

    Your remote presses are both decoded by the kernel and by lirc. In this case disable lirc in LE settings so that only in-kernel decoding is used. If needed you can change remote button configuration via ir-keytable (instead of lircd.conf) - see here for more details about it:
    thread-7152-post-43745.html#pid43745

    Before you disable lirc in the LE settings it would be great if you could upload some logs:

    Code
    systemctl status lircd.service | paste
    journalctl -a | paste
    dmesg | paste
    ir-keytable | paste

    When lirc is started it should disable in-kernel decoding - at least it's doing this in my test setups. So it would be great to know why this isn't happening on your setup.

    so long,

    Hias

    I don't have an Odrioid C2, but just tested irrecord on my RPi3 (running LE 8.0.1) and it worked fine with a RC-5 protocol remote.

    It looks like there are issues with the IR receiver driver in the kernel. See for example here: thread-7376-post-46075.html#pid46075

    To further narrow down the issues please try 2 things:

    - test with ir-keytable, this uses in-kernel decoding, which means lirc is not involved at all. A step-by-step guide how to do this is here: thread-7152-post-43745.html#pid43745 But note, not all remotes are supported via ir-keytable (it depends on the IR protocol), so it could be that you have to test with different remotes or - if you are unlucky - none of remotes will work at all

    - test with irrecord from LE 7.0: downgrade LE to 7.0.x, then copy irrecord to the storage partition

    Code
    cp /usr/bin/irrecord /storage/irrecord-7


    then upgrade again to 8.0.1 and start the old irrecord with

    Code
    /storage/irrecord-7

    so long,

    Hias


    I am using the community build with retroplayer integrated.


    Thanks for the info!

    Just checked the git tree, that build seems to be mostly on 8.0.0 so the rc_maps.cfg functionality isn't available there.

    No need to run any other tests, everything's clear to me now, just keep your autostart.sh for the time being.

    so long,

    Hias
    [hr]


    If I understand you correctly, then loaded/not loaded kernel keymap shouldnt interfere with ir-keytable -t / evtest results.


    Yes, exactly. The only thing that matters is the enabled protocol(s) (changeable with ir-keytable -p).

    Quote


    So I am back on the start, why the heck I am not able see any input from any remotes which I tried :)


    That was probably just bad luck, try some other remotes :)

    If it makes you feel better: did a quick test, checked with my (older) Panasonic TV and Denon amp remotes and they didn't work with ir-keytable either. My Philips VCR remote worked fine though, could even see codes from the jog/shuttle control :)

    so long,

    Hias


    I ran the commands as asked as I currently have it setup.
    Here is what the results were --> LcGV

    Hmm.. which build(s) are you using?

    Code
    Linux version 4.10.9 (trondah@lifebook) (gcc version 6.3.0 (GCC) ) #1 SMP Sun Apr 9 21:35:26 CEST 2017

    Could be that this community build doesn't yet include the rc_maps.cfg changes - they were quite recently included in LibreELEC and first appeared in 8.0.1. If that build is based on 8.0.0 you'll be missing the new features.

    Can you test with the official 8.0.1 build?

    so long,

    Hias


    Ah, mea culpa, I thought that /usr/lib/udev/rc_keymaps/samsung is enough. Still didnt catch all things around this IR kernel support I guess :( But, does it affect just "testing" button codes? I thought, that those maps are just "preconfigured" - hardcoded remote codes of brands remotes, it is actually affect possibility to use TSOP in general? If yes, that would mean just ir-record -p protocol choice isnt enough, and I must restart Rpi with all of .ko types and test if some of them will communicate with IR :s

    I am little bit confused around rc vs. ir things, I see .ko's on both /lib/modules/4.4.13/kernel/drivers/media/rc and /lib/modules/4.4.13/kernel/drivers/media/rc/keymaps.


    The kernel keymap (eg. drivers/media/rc/keymaps/rc-rc6-mce.ko) is automatically loaded by the kernel. For example an mceusb IR reciever has an hardcoded default for loading the rc-rc6-mce map.

    With gpio-ir-recv it's a little bit different, here you can configure the default kernel keymap.

    The effect of this is that for example you'll be able to use your (original) MCE remote out of the box, everything is setup by the kernel without having to use userspace tools like ir-keymap.

    On LibreELEC (and a lot of other Linux distributions) ir-keytable is available to change the default kernel configuration. For example, if you'd like to use another remote with your MCE IR receiver.

    If you use the gpio receiver and don't care about the kernel keymaps or even protocols, eg if you plan to setup everything with ir-keytable or use lircd you can simply use the rc-empty keymap - then no keycode entries will be installed by the kernel.

    ir-keytable configuration via rc_maps.cfg is an easy way to make the config permanent, that's the reason why I added it in 8.0.1 :)

    Quote


    And also, why there appears two new inputs, after enabling dtoverlay=gpio-ir.

    /dev/input/event0: gpio_ir_recv
    /dev/input/event1: MCE IR Keyboard/Mouse (gpio-rc-recv)


    I only get the "MCE IR Keyboard" here (LE 8.0.1, kernel 4.9) if I manually enable the mce_kbd protocol - kernel 4.4 loads all protocol decoder modules by default so this is probably why you are seeing it.

    so long,

    Hias

    Does it mean that I (on 7.0.3) cant use custom codes at all, or just I need to use existing filename (I mean copy /usr/lib/udev/rc_keymaps/XXY into /storage/.config/rc_keymaps/XXY and modify it for custom IR codes?

    On old systems you can, for example, use the override method. But you should really update to 8.0.1, do you have any particular reason why you are still using 7.0.3?

    Quote


    I also tried

    Code
    dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=1,rc-map-name=rc-samsung


    You have to use a valid kernel map, i.e. one of the kernel modules in /lib/modules/*/kernel/drivers/media/rc/keymaps/ (without the .ko at the end).

    rc-samsung doesn't exist, therefore the kernel falls back to rc-empty:

    Quote


    Found /sys/class/rc/rc0/ (/dev/input/event0) with:
    Driver gpio-rc-recv, table rc-empty

    With ir-keytable you can only use the user space keymaps, eg the samsung one in /usr/lib/udev/rc_keymaps

    Code
    ir-keytable -c -w /usr/lib/udev/rc_keymaps/samsung


    Quote


    Could you elaborate this little bit more? I didnt find it in the github gpio-ir-recv description. I would like to try every option which I have to conclude it as: "Mysteriously, IR doesnt react on anything, except running under lirc" :)


    This means most rc subsystem drivers support both the new method with in-kernel decoding and the old method with userspace lircd. So you can use lirc tools like mode2 to debug IR issues or run lircd if you want to use a remote that's not supported by the kernel protocol decoders.

    The old lirc_xxx kernel drivers from the staging directory are currently being converted to rc drivers - or removed if noone cared about them.

    For you as a user this means (besides a name change, eg lirc_serial -> serial_ir) that you'll still be able to use lirc as before or use in-kernel decoding - if your remote protocol is supported.

    so long,

    Hias


    Yes, I have the same feeling with RAWs (Samsung Remote), but what wonders me, I didnt get anything even with year old Panasonic remote (I even tried Pioneer AVR remote bought 6 months ago, still big nothing). I believe at least Panasonic's remote protocol should be pretty standardized; my Pioneer AVR remote has learning capabilities (actually can learn practically any other remote's button code), and has even pre-hardcoded like tens of codes from other brands, and when I tried just for fun use one of panasonic for it, at least arrows works out of the box. I mean, I told AVR remote: use panasonic code, and I would able to control Panasonic TV with it.

    No, I dont use berryboot, I am using pretty clean instalation of 7.0.3 LE (SDcard /flash, USB flasdrive /storage).. Could it be that this feature is avaible only from LE >= 8 ?

    Bottom line: I am perfectly fine with using lirc :) I am just curious about other possible methods..

    I think (but I'm not 100% sure) LE 7.0.3 should work fine, but better upgrade to 8.0.1. Configuration via rc_maps.cfg is only available in 8.0.1, basic ir-keytable functionality worked before (I've been using gpio-ir with a hauppauge remote / rc-5 protocol for about a year).

    It's rather odd that you didn't get any output at all. (at least some) Samsung remotes use the NEC protocol, there's even a samsung keymap in /usr/lib/udev/rc_keymaps/samsung:

    Code
    # table samsung, type: NEC
    0x43532f KEY_NUMERIC_0
    0x435341 KEY_NUMERIC_1
    ...

    One nasty thing about ir-keytable is that it won't warn you if some other process (eg eventlircd) grabbed the event device - in that case you don't get any output from ir-keytable -t although decoding works perfectly fine.

    To check manually first run ir-keytable to see which event device it's using:

    Code
    LibreELEC:~ # ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event1) with:
    ...

    Then check with lsof if that device is used:

    Code
    LibreELEC:~ # lsof | grep /dev/input/event1
    566 /usr/sbin/eventlircd /dev/input/event1

    Ideally that command shouldn't output anything, here we see that eventlircd had grabbed the event device.

    Another possibility is to install the system tools addon and use evtest instead of ir-keytable -t - evtest will warn you if some process grabbed the device. You still have to use ir-keytable to select the protocol, but then use evtest to check for events.

    BTW: gpio-ir-recv (and several others of the ir receiver drivers in the rc subsystem) also supports a "raw" lirc device, /dev/lirc0, so you can use "mode2" to check if the driver is able to see any IR signals at all.

    so long,

    Hias

    Hi!


    I already post this to the OE forum (similiar topic about IR, and this topic was hinted for me by HiassofT), but as my platform is LE, I would post it also here:


    I also answered on the OE forum 2 days ago but it looks my post is no longer there. Ah, well...

    Quote


    I cant make IR work on Rpi2 platform without lirc.

    When I try ir-keytable -t, no input shown from NEC and Samsung remotes. I also tried all other (-p rc-5, then rc-6, sony, sanyo, nec) explicitly, and test with NEC, Samsung and even Panasonic TV remotes, and still, no info at all. I dont know, where could be a problem here. The TV (Panasonic remote) is quite new, like 2015/2016 model, so I think it should be recognized by something.


    This probably means the remotes use some proprietary or non-standard protocol and you have to use lirc - or another remote :)

    Quote


    Btw., Samsung remote (which I using with lirc) has this kind of codes inside lirc conf:

    Code
    name /storage/.config/lircd.conf
    flags RAW_CODES|CONST_LENGTH


    lircd.conf files with RAW codes is a strong indication of a non-standard protocol.

    BTW: your kernel log looks odd, like it's coming from a 4.4 kernel. Are you using berryboot? If yes, I can only advise to get rid of it. Berryboot is not supported in LibreELEC as you'll be missing a lot of fixes from the LibreELEC kernel, especially in the rc subsystem.

    so long,

    Hias

    I haven't seen this yet on systems with current Linux kernels (RPi, x86). It could be that this is specific to the rather ancient amlogic kernel or the meson-ir device driver.

    Better ask in the Amlogic subforum, that's where the amlogic gurus hang around :)

    so long,

    Hias


    I needed to add

    Code
    ir-keytable -a /storage/.config/rc_maps.cfg


    to the autostart.sh file to make it work after rebooting.

    Thanks for the feedback!

    It's odd that you needed to add that command to autostart.sh, the system should pick up .config/rc_maps.cfg automatically on boot.

    Could you please run the following commands and post the URL you got from the last one?

    Code
    udevadm control -l debug
    udevadm trigger --action=add -s input
    journalctl -a | paste

    so long,

    Hias

    Since the remote is supported by the kernel it's best to create an ir-keytable file instead of using userspace lircd.

    First stop eventlircd and kodi so they don't interfere:

    Code
    systemctl stop kodi
    systemctl stop eventlircd

    Then we need to find out which protocol the remote is using. To do that we need some info about the IR receiver which we can get with "ir-keytable". The output should look like this:

    Code
    LibreELEC:~ # ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event1) with:
    Driver (null), table rc-dib0700-rc5
    Supported protocols: rc-5 nec rc-6
    Enabled protocols: rc-5
    Name: IR-receiver inside an USB DVB re
    bus: 3, vendor/product: 2040:7060, version: 0x0100
    Repeat delay = 500 ms, repeat period = 125 ms


    The important things are the supported and enabled protocols. Since you already got scancode output from "ir-keytable -t" you only need to test within the "Enabled protocols", otherwise you'd need to go through all "Supported protocols" (except "lirc", which isn't a real protocol).

    Now test with each protocol if you get scancode output. Run the following command (change the protocol after "-p") and press buttons on your remote.

    Code
    ir-keytable -p nec -t

    If you get no event output try the next protocol.

    If you set the correct protocol the output should look like this - note the EV_MSC events with "scancode = ..."

    Code
    LibreELEC:~ # ir-keytable -p nec -t
    Protocols changed to nec
    Testing events. Please, press CTRL-C to abort.
    1491293447.763188: event type EV_MSC(0x04): scancode = 0x847908
    1491293447.763188: event type EV_SYN(0x00).
    1491293448.029412: event type EV_MSC(0x04): scancode = 0x847908
    1491293448.029412: event type EV_SYN(0x00).
    1491293448.351181: event type EV_MSC(0x04): scancode = 0x847908
    1491293448.351181: event type EV_SYN(0x00).


    (BTW: the output above is with a WDTV live remote which I happened to have sitting in a box)

    Now that we have determined the protocol we can create a keytable file for the remote in /storage/.config/rc_keymaps/ - let's name it "wdtv-live". Open another ssh session and start an editor (keep "ir-keytable -t" running in the other session, we need that to get the scancodes).

    Code
    nano /storage/.config/rc_keymaps/wdtv-live

    In the very first line we have to put a header with the name of the table (the actual name is not important, better avoid blanks in it but you can name it anything you like) and the protocol (after "type: "). The protocol is the important thing here. The header should look like this:

    Code
    # table wdtv-live, type: NEC

    Now we have to map the buttons. Press a button on the remote, record the scancode you got from ir-keytable (the 0x... code after "scancode = ...") and add it to the keytable file together with the key name. Note: you have to use the official linux keynames as listed in linux/include/uapi/linux/input-event-codes.h - Elixir - Free Electrons

    When you're done the keytable file should look like this:

    Code
    # table wdtv-live, type: nec
    0x847905 KEY_UP
    0x847900 KEY_DOWN
    0x847907 KEY_LEFT
    0x847909 KEY_RIGHT
    0x847908 KEY_OK
    0x84791b KEY_BACK

    Save the file, stop "ir-keytable -t" and test if the keytable file is correct. Run the following command (it clears the current kernel keytable, loads your newly created one and then starts test mode) and press keys on the remote. Note that you should now also see EV_KEY events with the keycodes:

    To make this permanent create a rc_maps.cfg file in /storage/.config/

    Code
    nano /storage/.config/rc_maps.cfg

    Insert the following line to automatically load your keymap (on any ir receiver with any kernel default keymap):

    Code
    * * wdtv-live

    Save the file, then run the following command to test if everything's setup correctly:

    Code
    LibreELEC:~ # ir-keytable -a /storage/.config/rc_maps.cfg
    Old keytable cleared
    Wrote 6 keycode(s) to driver
    Protocols changed to nec

    so long,

    Hias


    [Edit]: Saw some interesting errors in the log files.

    Code
    mceusb 1-1.5:1.0: Error: urb status = -32


    This could be the culprit. Please upload the full dmesg

    Code
    dmesg | paste


    The majority of USB errors on RPi are caused by insufficient power supplies. Try another power supply and also check with the following command if an undervoltage condition has occurred

    Code
    vcgencmd get_throttled

    It should print "throttled=0x0", if you got anything else please post the full output.

    so long,

    Hias