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
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).
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.
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
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):
When that had worked, check if loading via rc_maps.cfg works. But first clear the current table:
Then run ir-keytable in auto-load mode with your 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.
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 · GitHubCode
- Name: gpio-ir
- Info: Use GPIO pin as rc-core style infrared receiver input. The rc-core-
- based gpio_ir_recv driver maps received keys directly to a
- /dev/input/event* device, all decoding is done by the kernel - LIRC is
- not required! The key mapping and other decoding parameters can be
- configured by "ir-keytable" tool.
- Load: dtoverlay=gpio-ir,<param>=<val>
- Params: gpio_pin Input pin number. Default is 18.
- gpio_pull Desired pull-up/down state (off, down, up)
- Default is "down".
- rc-map-name Default rc keymap (can also be changed by
- ir-keytable), defaults to "rc-rc6-mce"
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.
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.
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:
This is the output of evtest: *********************************************** LibreELEC-NUC:~ # systemctl sto - Pastebin.com
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:Code
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.
Not some more protocols was enabled, but the remote still doesn't work.
Thanks once again..
Could you repost the ir-keytable output? I'm always forgetting we need 2>&1 there
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
select the event device corresponding to your remote and press some keys, then post the output here
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:
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:
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:
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:
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.
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:
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.
I am having a bit of a strange issue after upgrading this morning. The remote seems to work except the KEY_OK button.
Kodi Log shows no key press when I press this key but does for other keys, this is me pressing right.....
09:55:45.003 T:139858677500032 DEBUG: OnKey: right (0xf083) pressed, action is Right
09:55:45.180 T:139858677500032 DEBUG: Keyboard: scancode: 0x72, sym: 0x0113, unicode: 0x0000, modifier: 0x0
09:55:45.705 T:139858677500032 DEBUG: Previous line repeats 1 times.
09:55:45.705 T:139858677500032 DEBUG: OnKey: right (0xf083) pressed, action is Right
09:55:45.996 T:139858677500032 DEBUG: Keyboard: scancode: 0x72, sym: 0x0113, unicode: 0x0000, modifier: 0x0
if I run irw /run/lirc/lircd-lirc0 I get the following output:
000000037ff07bdd 00 KEY_OK URC-7980-MCE
000000037ff07bdd 00 KEY_OK_LIRCUP URC-7980-MCE
000000037ff07bdd 00 KEY_OK URC-7980-MCE
000000037ff07bdd 00 KEY_OK_LIRCUP URC-7980-MCE
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:
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:
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:
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:
Before you disable lirc in the LE settings it would be great if you could upload some logs:
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.
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
then upgrade again to 8.0.1 and start the old irrecord with
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.
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
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 ([email protected]) (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?
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.1Quote
And also, why there appears two new inputs, after enabling dtoverlay=gpio-ir.
/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.