Adding support of "third party" IR remotes

[SolarWarez]

If you don't use lircd then don't forget to generate and load into kernel appropriate key table mapping file that consist of "scan code"="key code" pairs for your remote. Without right key table driver will not generate EV_KEY events!
To learn scan codes use "ir-keytable -t".
To clear already loaded key table use "ir-keytable -c".
To load your key table use "ir-keytable -w key_table.file".
Also I recommend to turn off unneeded protocols using "ir-keytable -p PROTOCOL".
In my archive you may found example of key table that I use and script remote.sh that do all work.

After making and loading right key table you may check that all Ok using "ir-keytable -t" again. You must see EV_KEY events with right keys codes and mnemonics.

[AlexVallat]

Great work! Thanks for this. I've successfully got ir-tables raising scancode events for the NEC1-based remote control with the Minix NEO x7 mini using your code. As there are very few buttons on the supplied remote control, this is going to be very handy. Now I just need to create a good map for it.

I have to admit to being a bit new to this, though, so can I check some dumb questions? I assume that in order to make this persistent over reboots, I need to add a script to run at boot time? Presumably in init.d? Is it remote.sh that needs to be run, so it installs the module, sets the protocol, clears the keymap and loads the custom map every time?

If that's all true, then the files need a more permanent home than /data/local/tmp - I assume no problem in just creating a /data/local/rockhip_cir/ for them and keeping them in that instead?

Could you also please clarify rockchip_cir.kl for me - does this need to be moved into /system/usr/keylayout as a keylayout file? Or isn't the .map file (once populated with appropriate scancodes) sufficient?

Thanks for any help you can give me!

Alex

[jmak]

I have to admit to being a bit new to this, though, so can I check some dumb questions? I assume that in order to make this persistent over reboots, I need to add a script to run at boot time? Presumably in init.d? Is it remote.sh that needs to be run, so it installs the module, sets the protocol, clears the keymap and loads the custom map every time?

Yes, that script can do it. I still have to sort out mine for reboot since placing it in /etc/init.d did not initially work, but it might just have been a permission issue.

If that's all true, then the files need a more permanent home than /data/local/tmp - I assume no problem in just creating a /data/local/rockhip_cir/ for them and keeping them in that instead?

Did the same on my side

Could you also please clarify rockchip_cir.kl for me - does this need to be moved into /system/usr/keylayout as a keylayout file? Or isn't the .map file (once populated with appropriate scancodes) sufficient?

The driver reads the hardware codes from the IR device (typically around 2 to 4 bytes from what I could tell), decodes them and then write an appropriate scan code (range 0..255) to the standard input device to be read by the GUI interfaces. This is where the A-100.map file comes in (name of file may be changed). It takes the hardware code transmitted by the remote and converts it to a scancode. The keylayout file is then used by the Android eventing system to (re)map that scancode and decide what to do with the key.

So in summary... A-100.map translates hardware codes to scancodes, and the rockchip_cir.kl then maps the scancodes to Android keys.

On my side copying the rockchip_cir.kl keylayout file directly to the /system/usr/keylayout did not do the job and I had to rename the file to the Vendor_xxxx_Product_xxxx.kl format - more specifically Vendor_071b_Product_3226.kl (http://source.android.com/devices/te...out-files.html). Search for "KeyTest Android" to get a small app that can be run within the Android GUI system that will show you all the input events. It includes the scancode as well as a found mapping from the KeyLayout file in its output. This is quite helpful to know firstly if the correct scancode is received based on your mapping from the A-100.map file for each remote button, and then secondly if the keylayout file is actually picked up for the device and remapped to the correct Android key. Initially without the renaming of the keylayout file my home button with scancode 102 registered as a KEY_MOVEHOME key in place of KEY_HOME as an example.

Next step for me... XBMC after I have sorted out multiple keys registered for a single button push on my Harmony One remote.

Disclaimer: All above content written from memory since I don't currently have access to the systems and did the work last night.

[AlexVallat]

Thanks for the reply, jmak. After some trial and error yesterday, I got similar conclusions, although I eventually decided that with a well-written .map, the .kl file was unnecessary. There's a Generic.kl map that maps scancodes to keycodes in a sensible way, so if the map file is written to procude scancodes that match what it expects to find, that's sufficient. For example, mapping the home button to KEY_HOMEPAGE instead of KEY_HOME.

I had plenty of permission issues too (I think the .ko file needs to be 744?), and then another fun gotcha with windows line endings instead of unix ones in the script after I edited it! It works now, though - I chose to put a separate one-liner script in init.d that just calls /data/local/rockchip-cir/remote.sh so that if I need to make changes it's all in one place.

Further, I found that I was mistaken about the protocol support - I had thought that the idea was that this module supported various protocols, and would use the one that matched the hardware of the IR receiver (and that the Minix Neo X7 Mini was a NEC-hardware receiver). But it's much better than that, the IR receiver hardware picks up all the protocols, and you can choose which one(s) to use.

This turns out to be a very good thing, because the NEC protocol has been an absolute nightmare to get working with repeats. I've tried many combinations of number dittos on the end of the code, and repeats of the code sent and so on, but they are all unreliable and can produce extra unwanted keypresses, particularly when clicking the same button 3 times in a row. This might be a problem with my remote (an MX-780), but in any case I wasn't happy with the result.

Trying other protocols, I eventually found that the JVC protocol works a lot better, because it receives two different hardware codes - it gets one when the button goes down, and a *different* one while it is held down! If I reprogram the remote to send JVC codes then the repeat detection seems to be much more reliable, and I get the correct number of key events for the correct number of presses!

Next step for me too is XBMC :-)

[Eyal]

Double detection

Hi,

Sorry to wake this thread up.
I've set my Q7 device with the custom ir module.
I run the ir-keytable app with the NEC protocol via an init.d startup script (link).
It works great, except for double detection for every key I press.
Anyone has an idea how to fix it?

Thanks!

[mjan]

Almost working on RK3066

Hello everybody. I'm new in this forum. I want to thank @SolarWarez for all the great work he done!
My situation is as follows: I've changed the firmware of an Android box sold in my country. This box is almost the same as the Minix Neo 5 mini. I've backuped up the device, and flashed the firmware of the Minix. Everything works great, except for the remote control. The remote that came with my box is a complete remote, with plenty of buttons, really usefull.

I should add that this box is a RK3066, so maybe that is generating some kind of problem or incompatibility with this method.

I've tried to run the patch made by @SolarWarez, it loads ok, but I cannot get any results when I run

./ir-keytable -t

I've also tried to use lirc, but also with no results.

I've run dmesg | grep remote

<4>[    1.727421] ++++++++remotectl_probe
<4>[    1.727457] remotectl probe j=0x0
<4>[    1.727475] remotectl probe j=0x1
<4>[    1.727493] remotectl probe j=0x2
<4>[    1.727510] remotectl probe j=0x3
<4>[    1.727527] remotectl probe j=0x4
<4>[    1.727543] remotectl probe j=0x5
<6>[    1.727684] input: rkxx-remotectl as /devices/platform/rkxx-remotectl/input/input1
<6>[    1.930463] keychord: using input dev rkxx-remotectl for fevent
<6>[  253.512506]   remotectl GPIO found! GPIO = 353, gpio = 1
<6>[  253.730161] ++++++++remotectl_init
<6>[  253.759057] rc rc0: lirc_dev: driver ir-lirc-codec (rkxx-remotectl) registered at minor = 0

and I'm wondering if maybe the GPIO is getting wrong data. Can I somehow bypass the mannual detection? Can I set a manual GPIO? If I can have the sources I can try by myself and maybe make it work.

Once again, thanks for this incredibly useful solutions!