Posts by HiassofT

    Did you enable lircd in LE settings?

    Just did a quick test, Milhouse build 0508 on RPi3, with some FTDI serial dongle, a lircd.conf file in .config and this lirc_options.conf and it worked fine:

    lircd and lircd-uinput started up fine:

    Code
    349 root       2:54 /usr/sbin/lircd -O /storage/.config/lirc_options.conf --nodaemon --release /storage/.config/lircd.conf
      350 root       0:00 /usr/sbin/lircd-uinput -O /storage/.config/lirc_options.conf

    But of course lircd was logging errors because there was no UIRT2 adapter connected:

    so long,

    Hias

    Usually you have manually switch the screen to 16:9/anamorphic mode. Check the manual of your screen if there's some setting in a menu, a switch or something like that.

    Automatic switching to anamorphic mode in (PAL) TVs relies on information transmitted in the video signal during vertical blank (or in one of the cut-off overscan lines, can't remember) but AFAIK RPi doesn't generate these signals.

    I'm using my RPi 3 on a 16:9 CRT TV, connected via composite, and had to manually put my TV into anamorphic 16:9 mode as well.

    so long,

    Hias

    Enable debug logging in kodi and check kodi.log if it reported errors about the keyboard.xml file. Also check if the remote presses actually show up as keyboard events. If they show up as lirc events in the log, eventlircd is still translating the events.

    BTW: If you change anything it's best to reboot, this is the easiest way to make sure all new config files are picked up.

    so long,

    Hias


    To debug I created a ./config/lirc_options.conf which was identical to the one in /etc/lirc
    but changing
    output = /run/lirc/lircd.socket2

    and only /run/lirc/lircd.socket was created (no "2").


    The socket is the one thing you shouldn't change in lirc_options.conf - it's managed by systemd. Actually lircd is a socket managed service, systemd creates the socket and when the first client, lircd-uinput in this case, connects to it systemd will start lircd - that's exactly the same setup as in other linux distributions.

    I'd also recommend to keep eventlircd running, this picks up the input events generated by lircd-uinput, translates these again into lirc events and feeds them to the standard lirc socket which is used by kodi.

    You could change the kodi startup to use the /run/lirc/lircd.socket directly, but then kodi can't be controlled by other IR remotes (eg USB IR receivers which send out input events).

    Yes, the setup is rather awkward, but as kodi doesn't play too well with linux input events it's currently the only way to support all remotes in kodi.

    so long,

    Hias

    Just did a quick test here with my justboom remote and ran into an interesting issue, kodi didn't detect any button presses at all if eventlircd was bypassed.

    lsof clearly showed that kodi was using the input event device, but nothing at all showed up in kodi log (debugging enabled)

    Code
    LibreELEC:~ # lsof | grep /dev/input
    1350 /usr/lib/kodi/kodi.bin /dev/input/event0
    1350 /usr/lib/kodi/kodi.bin /dev/input/event1
    LibreELEC:~ # evtest
    No device specified, trying to scan all of /dev/input/event*
    Available devices:
    /dev/input/event0: Logitech K400
    /dev/input/event1: gpio_ir_recv
    Select the device event number [0-1]: ^C

    As I was pretty sure it worked with my hauppauge remote before I dug into that and could make it work if I added a (dummy) keymap entry for KEY_NUMERIC_0 - looks like this is enough to make kodi detect the remote as a keyboard (maybe kodi thinks this is a game controller otherwise - don't know for sure).

    Here's the working .config/rc_keymaps/justboom I've used for testing:

    With this keymap longpress-OK worked out of the box with kodi, default kodi keymap contains an entry to map longpress-enter to context menu.

    BTW: I needed to restart kodi after changing the keymap with ir-keytable -w ... on-the-fly, kodi only seems to test for "keyboard/non-keyboard" when it accesses the input device the first time.

    Snippet from default kodi keyboard.xml:

    Code
    <enter>Select</enter>
    <enter mod="longpress">ContextMenu</enter>

    And also visible in kodi.log :)

    Code
    17:36:39.358 T:1962061824 DEBUG: Keyboard: scancode: 0x1c, sym: 0x000d, unicode: 0x0000, modifier: 0x0
    17:36:39.891 T:1962061824 DEBUG: Previous line repeats 1 times.
    17:36:39.891 T:1962061824 DEBUG: OnKey: long-return (0x100f00d) pressed, action is ContextMenu

    BTW: I think you need to have both <key ...> and <key mod="longpress"...> in keyboard.xml to make longpress working in kodi. Also, the ~500ms delay for the first key-repeat showing up in evtest/ir-keytable is normal - this is the initial repeat delay:

    so long,

    Hias


    Is it possible to use longpress? Having an extra set of commands would be very handy.

    Not as long as Kodi is using lirc input.

    Currently eventlircd translates linux input events (as generated by gpio-ir) into lirc events which are then read by kodi. This is done so that button translation can be done for a few remotes and because kodi doesn't support several buttons (like KEY_OK or KEY_CHANNELUP/DOWN) in "keyboard mode".

    You can disable eventlircd by creating an empty /storage/.config/udev.rules.d/98-eventlircd.rules file, then remote button presses will show up as keyboard events in kodi and longpress works.

    If you do this you also have to install a custom rc_keymap and change the KEY_OK mapping to KEY_ENTER - kodi without an "OK" button won't be too much fun :)

    so long,

    Hias


    This is all really strange. My MCE remote (via harmony) stopped yesterday. have been trying to get it back to work for an hour now (Hope I haven't messed up Harmony settings now). Trying a restore first, made a kodi backup two weeks ago.

    Running 8.0.1 on Pi2 device, did not update this last week.


    Please do the checks as outlined in post #2 of this thread: thread-8016-post-48094.html#pid48094

    Also please post what kind of IR receiver you are using (USB or GPIO) and in case of a GPIO receiver which driver you are using (lirc-rpi or gpio-ir).

    so long,

    Hias

    Can you do a test with the latest Milhouse build?
    LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)

    LE9 adds support for setting lircd options via /storage/.config/lirc_options.conf and thus make it a lot easier to configure the driver and device (just copy /etc/lircd/lirc_options.conf to the .config dir and change driver= and device=).

    You might also need to create a /storage/.config/lircd.conf file, by default lircd is configured to support MCE and xbox remote codes.

    BTW: with userspace lirc you won't use ir-keytable, configuration is handled by lircd.conf and lirc_options.conf.

    so long,

    Hias


    I will try this. BTW, is possible that the remote is broken, in a way that it sends different signals now? A longshot?


    As I wrote before, it could be that the controller inside the remote can be configured to different "addresses" (scancodes), either by a hardware-switch, solder-bridge or by some magic button combination (the latter should usually be reset by removing batteries). But this is just a wild guess (consumer electronics remotes often can do that, so you can control 2 TVs/VCRs/DVD-players etc in the same room without interfering), not sure if this is true for your remote at all.

    [quote]Edit: I tried it, and it didn't work. But when I read the thread you linked to, they say that since irw doesn't do anything itself (not without killing stuff, they have done some more stuff.)[/code]
    Could you be more specific what you had done?

    After creating the keytable try to read it in via ir-keytable

    Code
    ir-keytable -c -w /storage/.config/rc_keymaps/my-mce


    Then read it back and verify it's the same you created (ir-keytable will silently ignore some errors when "loading" a keytable, so it could be that some or all keys were missed):

    Code
    ir-keytable -r

    When that had worked, check if loading via rc_maps.cfg works. But first clear the current table:

    Code
    ir-keytable -c


    Then run ir-keytable in auto-load mode with your rc_maps.cfg:

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


    Now, again read it back (via ir-keytable -r) and verify it's the one you created.

    If all that worked so far, check if it's being picked up automatically on boot (note that this only works in LE 8.0.1 and newer, older versions didn't support this). Reboot your box and then read back the keytable and verify it's the same (or try pressing buttons and check if that works).

    If the reboot-test failed, please post your journalctl -a output.

    If you get any errors from the commands above or if the output differs from the expected one please post your keymap file, the rc_maps.cfg file and any errors/warnings you got on the console.

    so long,

    Hias


    That sounds interesting, how do I do that? Just change in the config.txt or what?

    Yes, exactly. This'll use the same gpio as lirc-rpi per default, so if you've been using lirc-rpi before your IR receiver will work with gpio-ir as well.

    Details about the gpio-ir DT parameters can be found in the overlays README (/flash/overlays/README) or here: linux/README at rpi-4.9.y · raspberrypi/linux · GitHub

    Instructions how to customize configuration via ir-keytable are in the thread linked by bubba2017: thread-7152-post-43745.html#pid43745

    BTW: gpio-ir can be used with userspace lirc as well if your remote isn't supported via in-kernel decoding.

    so long,

    Hias


    I've added device_tree_overlay=lirc-rpi to the last line of config.txt.


    FYI: I'd recommend using the gpio-ir overlay instead of lirc-rpi.

    gpio-ir uses the upstream Linux gpio_rc_recv driver and supports in-kernel decoding (aka ir-keytable configuration) - so MCE remotes (plus a few others) will work out of the box and you don't need to use userspace lirc.

    so long,

    Hias

    The puzzling thing is I have no idea how that remote could work before if it always transmitted 0x800f2xxx scancodes. These scancodes were never supported by in-kernel decoding and I also don't think they'd work when using userspace lirc.

    Googling for the scancode brought up and older post on the OE forum, there a user had a similar issue:
    OpenELEC Mediacenter - OpenELEC Forum - Rosewill RHRC-11002 MCE remote not working (1/2)

    If you can't find out what changed on your setup you could just copy /usr/lib/udev/rc_keymaps/rc6_mce to /storage/.config/rc_keymaps/my-mce, change the 0x800f0xxx codes to 0x800f2xxx, and activate that via /storage/.config/rc_maps.cfg:

    Code
    * rc-rc6-mce my-mce

    so long,

    Hias


    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