Posts by HiassofT

    It looks like mainline has fixed the issue:

    media: rc: meson-ir: add timeout on idle · torvalds/linux@8d7a77c · GitHub

    They, fittingly, call these keypresses "ghost" keypresses. It looks to be caused by the hardware not generating a timeout after each keypress, so they added it in software.

    My question is this:

    Can we get this fix backported to our kernel in the official odroid C2 (and generic amlogic devices) builds?

    The fix is already in the LE amlogic-3.14 tree, see these 2 PRs: fix in-kernel decoding with meson-ir by HiassofT · Pull Request #83 · LibreELEC/linux-amlogic · GitHub fix flush_timer by danielkucera · Pull Request #98 · LibreELEC/linux-amlogic · GitHub

    LE 8.2.5 uses an older version of the 3.14 kernel without these fixes, but the current LE 9.0 development branch has these built in.

    so long,

    Hias

    Support for non-NEC remotes, like RC6 MCE remotes, is rather lacking in the 8.2.x Amlogic tree, you might have more luck configuring your remote as a Xbox One remote and then using a rc_maps.cfg with "* * xbox_one" - the Xbox One remote uses the NEC protocol.

    I fixed the kernel remote to support MCE and other remote handling in January, but these changes are only available in the 9.0 (preview) versions - this is why LE9.0 and CE9.0 preview builds work better than the 8.2 ones in this respect.

    I'm not sure why Lirc sometimes doesn't work on 8.2, IMHO it should be fine (unless you have some "killall lircd" or similar commands in your autostart.sh). But then I'm not really experienced with Amlogic boxes and the old 3.14 kernel, my only contact with these so far was getting in-kernel / ir-keytable decoding working (which I did "blind", without actual hardware to test).

    so long,

    Hias

    If you are using irsend it could be that you are hit by this lirc bug: LIRC / Tickets / #315 irsend / lircd hang when using repeats A proposed fix has been posted but it hasn't made it's way into lirc yet.

    Do you also get the error when you don't use irsend?

    I'm not familiar with usb-uirt so I won't rule out a bug in the uirt2-raw lirc driver, or it could also be a RPi USB issue (we saw plenty of those, also with serial usb devices). The checksum error certainly is odd.

    Also check dmesg for USB related errors and run "vcgencmd get_throttled" (you should get "0x0") to check if the power supply is OK.

    so long,

    Hias

    hmm, only rc-core is loaded but no there's no sign of a rc0 device being registered - and also no error message. Maybe some module is missing?


    fasigno could you grab dmesg and lsmod form a working Arch installation, maybe that'll give us some hints.

    so long,

    Hias

    I am using exactly the files boot2k3 was posting in #229. In Coreelec 8.90.1 it works in nightly-20150428 not.

    When using nightly ir-keytable is saying this for example:

    Thanks for testing!

    I was just told that there's currently an Amlogic specific bug in Kodi which prevents lirc events (which is used by default in LE for remote handling) from working.

    A workaround for that issue was PRed here: [aml]Register lirc in AML after #13761 by gelotus · Pull Request #13798 · xbmc/xbmc · GitHub - but it looks like it needs a bit of rework.

    It'll probably take a couple more days until this issue is fixed in Kodi, then a bit until Kodi is updated in LE. Until that's resolved IR remotes will stay broken in nightly Amlogic LE builds.

    so long,

    Hias

    I

    Thanks for your support. I tried both 1. and 2. but the remote won't work. I also tried the "original" odroid remote (see code below). Same result. So it is a general problem I think. I am testing with libreelec 9.0 nightly-20150428. But also with coreelec it's the same behaviour :(. What else could it be?

    Is that your complete keymap? If yes it can't work as it doesn't contain the header with the protocol. The first line of the file must always contain a line like this:

    Code
    # table odroid, type: NEC

    With out the "type: PROTOCOL_NAME" the IR remote protocol won't be configured which in case of Amlogic/meson-ir means that no protocol decoded is enabled.

    so long,

    Hias

    It's odd that enabling mce_kbd kills other input in kodi, this shouldn't happen. I haven't seen this on RPi yet and on x86 it also should work fine. Have you checked if restarting kodi helps?

    Combining MCE remote and MCE keyboard functionality is possible, and it's also rather easy to make that persistent.

    Copy the stock mce keymap from the system to .config/rc_keymaps, and give it a unique name so you later know what it's doing :)

    Code
    cp /usr/lib/udev/rc_keymaps/rc6_mce .config/rc_keymaps/mce_plus_keyboard

    then edit this file and add the "mce_kbd" protocol in the very first line - it should then look like this:

    Code
    # table rc6_mce, type: RC6,mce_kbd
    0x800f0400 KEY_NUMERIC_0
    0x800f0401 KEY_NUMERIC_1
    ...

    Now create a .config/rc_maps.cfg to activate that keymap. eg

    Code
    * * mce_plus_keyboard

    so long,

    Hias

    For mce_kbd everything's a lot simpler: just enable the mce_kbd protocol and Kodi should automatically pick up the device and everything should work.

    So just running "ir-keytable -p mce_kbd" (while kodi is running) should be enough. If not, try restarting kodi (systemctl restart kodi).


    so long,

    Hias

    mce_kbd is a bit different than the other IR protocols, if it's enabled a separate input event device will be created.

    To check if signals are properly received and decoded it's best to install the system tools addon and then use "evtest" (with kodi and eventlircd stopped) instead of "ir-keytable -t". Just select the event device that reads "MCE IR Keyboard/Mouse".

    eg:

    so long,

    Hias

    Thanks for the log!

    Unfortunately I can't help you here as you seem to be using a community build and I'm not aware of what changes there might be applied compared to official LibreELEC builds.

    So I'd suggest you ask the build maintainer, or maybe someone else familiar with these builds can chime in here.

    so long,

    Hias

    The output looks fine so far, kodi picked up both event devices and the udev info of the mouse device looks exactly like the one from the VRC-1100 remote (which works fine on LE 8.2.5 with eventlircd disabled, thus kodi accessing the mouse device - this remote also exposes KEY_HOMEPAGE and KEY_VOLUMEUP/DOWN via the mouse device).

    The kodi debug log should reveal what's going on.

    so long,

    Hias

    First check if kodi picked up both event devices - be careful, the numbers (event4/event5) might change across reboots, so verify via evtest or /proc/bus/input/devices that the numbers are correct. Run the following command and post the output

    Code
    lsof | grep /dev/input

    The output should look similar to this:

    Code
    749     /usr/lib/kodi/kodi.bin  /dev/input/event0
    749     /usr/lib/kodi/kodi.bin  /dev/input/event1
    749     /usr/lib/kodi/kodi.bin  /dev/input/event2
    749     /usr/lib/kodi/kodi.bin  /dev/input/event3

    You should see /usr/lib/kodi/kodi.bin both in the event4 and event5 lines

    Then we need some more info about both input devices. Run the following commands and post the output as well. This will tell us if the devices were classified as keyboard, mouse, joystick etc

    Code
    udevadm info /dev/input/event4
    udevadm info /dev/input/event5

    If kodi had picked up the /dev/input/event5 device (where you got HOMEPAGE, VOLUME, PLAYPAUSE) enable debug logging in kodi, then reboot, then press the HOME and PLAY buttons, then ssh in and post the kodi log file. This will tell us if kodi received the input and if yes if and how it processed it

    Code
    paste .kodi/temp/kodi.log

    so long,

    Hias

    When testing things make sure you have stopped kodi and eventlircd so no process is grabbing (taking away the events) from you. evtest will warn you if you try to access an input device which is grabbed, so it should be pretty obvious if that happens.

    evtest should then show all events that come from the input devices.

    The IR thing is not quite clear to me, did you see an IR receiver device when running "ir-keytable"? It's a bit unlikely that the USB receiver would expose both HID plus IR devices but you never know.

    so long,

    Hias