Posts by HiassofT


    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


    I've killed these two process before starting eventlircd, and, before plugged in the USB stick:

    Code
    Mar 28 19:42:54 LibreELEC lircd-0.9.4c[749]: Info: closing '/dev/input/event14'


    Ah, sorry, I've missed that before.

    Logs and config all look fine: the eventlircd udev rule is processed correctly by udevd (it calls wakeup_enable) but for some reason eventlircd doesn't want to pick up the input device.

    I ran an identical test on my RPi with a Hauppauge USB dongle and eventlircd picked up the input device just fine.

    Very odd, no idea what's going wrong here - maybe I missed something or maybe there's a bug hiding somewhere.

    So until we have a better fix just stick to the lircd devinput workaround, at least this seems to be working fine :)

    so long,

    Hias


    Ok. maybe libreelec detect the wrong device?

    Code
    LibreELEC:~ #  /usr/sbin/eventlircd -vvv -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd
    eventlircd[966]: /etc/eventlircd.d/default.evmap: using 0 valid keyboard shortcut mappings
    eventlircd[966]: input device /dev/input/event2: grabbed

    This text was displayed before I plug my device. No more text was displayed after I plugged it.

    journalctl -> dZDA


    Saw in the log that you also had lircd running. Could you repeat the test with lircd/lircd-uinput disabled?

    The "/dev/input/event2: grabbed" output is normal, this is eventlircd handling your powerbutton. But in addition to that event14 should be listed there, too after you plugged in the receiver. Could be that lircd grabbed the input device before eventlircd, therefore the need to run the test without lircd in the background.

    so long,

    Hias


    I've posted the output of udevadm here: GIGX

    Thanks! The output looks OK and the remote should have been picked up by eventlircd (or kodi). Very strange, not sure what's going on there.

    Could you try the following:

    Unplug the Terratec receiver, then power up your libreelec box. When it's up ssh in and run these commands:

    Code
    systemctl stop kodi
    systemctl stop eventlircd
    udevadm control -l debug
    /usr/sbin/eventlircd -vvv -f --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd

    Then plug in your Terratec receiver. After a few seconds eventlircd should have detected the IR receiver and output some info. If it succeeded it should look like this:

    Code
    eventlircd[801]: /etc/eventlircd.d/default.evmap: using 0 valid keyboard shortcut mappings
    eventlircd[801]: input device /dev/input/event3: events of unsupported event type EV_MSC will be discarded
    eventlircd[801]: input device /dev/input/event3: event code 0x04 of unsupported event type EV_MSC will be discarded
    eventlircd[801]: input device /dev/input/event3: events of unsupported event type EV_REP will be discarded
    eventlircd[801]: input device /dev/input/event3: grabbed

    Then stop eventlircd with CTRL-C and post the output you got on the terminal and the journal

    Code
    journalctl -a | paste

    so long,

    Hias


    I've a Terratec USB Cinergy HTC Stick which stopped working when I upgraded my install from 7.95.1 to 8.0. I've already read other post related to Remote Control issue, but, I did not find a simple guide to solved my issue:

    ir-keytable seems to be OK:

    > Found /sys/class/rc/rc0/ (/dev/input/event14) with:

    Could you please post the output of

    Code
    udevadm info -a -n /dev/input/event14


    First check the exact event number via ir-keytable, it might change, so you'll have to adjust the command above.

    so long,

    Hias

    Very puzzling. Could you run a few more commands and post the output?

    Code
    ls -la /storage/.config/
    ls -la /storage/.cache/services/
    ls -la /dev/lirc*
    systemctl -a | paste
    udevadm info -a -n /dev/lirc0 | paste

    It would also be interesting if starting lircd manually works. Open 2 ssh sessions, in the first one run this (it's a single line, forum display will break it but copy-paste should work):

    Code
    /usr/sbin/lircd --nodaemon --loglevel=debug --driver=default --device=/dev/lirc0 --output=/run/lirc/lircd-lirc0 --pidfile=/run/lirc/lircd-lirc0.pid --release=_LIRCUP /storage/.config/lircd.conf

    If this worked (you should see "Notice: lircd(default) ready, using /run/lirc/lircd-lirc0") run the following command in the second ssh session:

    Code
    /usr/sbin/lircd-uinput --loglevel=debug --release=_LIRCUP /run/lirc/lircd-lirc0

    At this point you should have a working remote in kodi.

    Please also post the console output you got from these commands.

    so long,

    Hias

    Good news, everyone!

    I'm happy to announce that we integrated support for the Wolfson and Cirrus Logic cards into LibreELEC. Starting with today's 8.0.1 release these cards will work with official builds.

    LibreELEC (Krypton) v8.0.1 MR – LibreELEC

    If you've been using my 8.0.0 build just do a manual update to the official 8.0.1 version. This is going to be a seamless update, all your configuration settings will be preserved.

    HOW TO:Update LibreELEC - LibreELEC

    If you are new to this and do a fresh install with 8.0.1 don't forget to enable the card in config.txt via

    Code
    dtoverlay=rpi-cirrus-wm5102

    so long,

    Hias