Adding support of "third party" IR remotes

[SolarWarez]

Hello,
first of all excuse me for my English.

My goal is to add support of "third party" IR remotes to our devices.
The stock remote, IMHO, are ugly. They even doesn't have play/pause buttons etc.
But I have much better remote from my old popcorn hour clone media box.
There are how it's looks: http://cdn-static.cnet.co.uk/i/c/blg...orn_hour_3.jpg

I am already found kernel source module that respond to remote controls, so I need modify it and all must work as I think.

But now, my main problem are to get worked kernel source to work on.
I am already found many RK3188 kernel sources but all of them are slightly differents from each other because many devices based on RK3188 are exist.

I successfully compile kernel from this sources https://github.com/omegamoon/Rockchip-GPL-Kernel but unfortunately my device wont boot with this kernel. :-(
I have MK888b (with AP6210 radio IC).

So, if I will try different kernel sources and configs I guess that I waste huge amount of time to only compile working kernel and only after that I may start to working on remotes support.

But some peoples (I mean wasser and lewy20041) already has done this step and have working kernel sources and configs for them. So my idea that it would be great if they will agree to share they work with others for a common cause. And it would be in the spirit of open source software development...

I wrote to wasser PM but he did not answer...

So, if you have some information about already working kernel sources or right configurations for our devices then let share this information to make my (and maybe others) work more efficiently.

I am sure, that I solve this problem but it take longer time if someone help me.

[Deviant-AUT]

Maybe this could help you

http://www.freaktab.com/showthread.php?6835-Kernel-config-for-K-R42

[SolarWarez]

Thank you for helping but I already saw this thread.

I am successfully compile kernel from different available sources but all of them works similar: no anything on video outputs and reboots in cycle (I think so because power led flashing one times in 20-30 seconds infinite while device stay power on).

Maybe I do something wrong while compile kernels, eg. use wrong toolchain or something else.

To debug this situation I found serial port output on our board, so now I will try to understand why my kernels are rebooting in cycle.

About serial port, if it is interesting to someone I wrote there: http://www.freaktab.com/showthread.p...l=1#post141705

[JoKeRz]

To compile your own android linux kernel, you can start from generic RK3188 sources which are based on leaks / official Rockchip versions. I am not sure why your compiled kernel from omegamoon did not work, but the below could give you a different starting point:

• Wasser mentioned in that other thread he uses the Android Linux source code from here: https://github.com/thesawolf/android...ockchip_rk3188
• If you install one of his (wasser) ROMs which works for your device, after you boot into the rom you can get the .config file he used to compile the kernel by grabbing the /proc/config.gz and uncompressing it.
• From there you can make your own required modifications for your extra IR remote support.

I also heard the android linux source for the mk908 can be used with success for android set top boxes.

[SolarWarez]

I already try this sources too.

Wasser's ROMs that I try to flash in my device doesn't contain /proc/config.gz Maybe some early ROMs contain this configs?

In my most successfully attempt I receive kernel that doesn't reboot device in cycle and it seems that it boot completely but unfortunately still nothing on video outputs.

So, until I stopped waste my time trying to compile the kernel and solve the puzzle with .config file.

Instead of that I now working on kernel module that can run on existing kernel.
It is much harder than if I had working kernel sources because existing remote control driver are built-in into kernel instead of being kernel module.
Kernel module you can unload and load another but built-in drivers can't be unloaded. And the main problem is that built-in driver require IRQ corresponded the IR input pin in exclusive mode, so I can't attach another IRQ handler to receive notification when the IR pin receive signal.

But I solved this problem in some quite "dirty" way, so now my kernel module successfully register IRQ handler and receive IR pin signal.

Especially shame that I could make it much easier and faster if anyone help me with kernel compilation.

PS: And unfortunately I concluded that I should not wait for help on this forum...

[SolarWarez]

Just for information, if it's interesting to someone...

I wrote a kernel module that translates the IR signals from corresponding GPIO pin to userspace in LIRC format through /dev/lirc0
Also I compile lircd for my device and now lircd sucessfully can receive IR signal from remotes and generate key events.
I tested it with different remotes that I have in home, looks that all works fine.

Now I will try to link lircd with XBMC.

[B00gieman]

Please post your developments.
hope to use the popcornhour ir with my 3188.

[JoKeRz]

Yes, please post a link to your kernel module that sends the ir signals to lirc as well as your compiled lirc daemon.

I am also looking for a solution to have a different remote control working with the embedded IR receiver that comes with the device. I do not have the popcornhour remote, so I am trying to enable extended buttons in XBMC for my JP1.x remote (Atlas URC 1055). So your kernel module might be the missing piece into this equation.

[B00gieman]

@SolarWarez. Where are you?

[SolarWarez]

@SolarWarez. Where are you?

I am was quite busy during last days...

I attach archive with my driver and some tools and useful stuff.

I hope that your linux-related skills are great, because my writing English skill so weak and it's will be too difficult to me to explain all very detailed... But I will try if it needed.

Download archive, extract and transfer all files to your device. I made all tests in /data/local/tmp folder.
Don't forget to change file attributes to appropriate values e.g. set executable attribute on programs and scripts.

First of all you need to load my driver into kernel.
To do that execute "insmod /path/to/driver/rockchip-cir.ko"
If you place all my files in /data/local/tmp then run either "insmod /data/local/tmp/rockchip-cir.ko" or "cd /data/local/tmp" and then "insmod rockchip-cir.ko".

After that you may run "dmesg" and see some messages from my driver:

<6>[  589.230486]   remotectl GPIO found! GPIO = 170, gpio = 10
<6>[  589.235907]   Perform dirty hack...
<6>[  589.618741] ++++++++remotectl_init
<6>[  589.622244] Registered IR keymap rc-rc6-mce
<6>[  589.627674] input: rockchip_cir as /devices/platform/rockchip-cir/rc/rc0/input2
<6>[  589.635901] keychord: using input dev rockchip_cir for fevent
<6>[  589.641731] rc0: rockchip_cir as /devices/platform/rockchip-cir/rc/rc0
<6>[  589.648866] rc rc0: lirc_dev: driver ir-lirc-codec (rkxx-remotectl) registered at minor = 0

Also, you may run this command to see that driver registered successfully:

cat /proc/bus/input/devices

I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="rk29-keypad"
P: Phys=gpio-keys/input0
S: Sysfs=/devices/platform/rk29-keypad/input/input0
U: Uniq=
H: Handlers=kbd event0 keychord
B: PROP=0
B: EV=3
B: KEY=40008000 100000 0 0 0

I: Bus=0019 Vendor=071b Product=3226 Version=0001
N: Name="rockchip_cir"
P: Phys=gpio-keys/input0
S: Sysfs=/devices/platform/rockchip-cir/rc/rc0/input2
U: Uniq=
H: Handlers=kbd event1 keychord
B: PROP=0
B: EV=3
B: KEY=40000 1283c110 1e0040 0 0 0 100 200a000 102 c0012803 9e96c0 0 4000000 ffc

If all Ok, then now you may try to see if my driver see your remote or not.
By default in kernel built-in support of those IR signal decoders: NEC, RC-5, RC-6, JVC, SONY, RC-5-SZ.
I found that NEC protocol is most common (most of my tested remotes works using this protocol).

To check your remote use ir-keytable program with "-t" switch:

cd /data/local/tmp
./ir-keytable -t
Testing events. Please, press CTRL-C to abort.
86.845414: event type EV_MSC(0x04): scancode = 0x4cb01
86.845421: event type EV_SYN(0x00).
89.288102: event type EV_MSC(0x04): scancode = 0x4cb43
89.288111: event type EV_SYN(0x00).
90.150540: event type EV_MSC(0x04): scancode = 0x4cb06
90.150543: event type EV_SYN(0x00).
93.198825: event type EV_MSC(0x04): scancode = 0x809e
93.198834: event type EV_SYN(0x00).
94.056203: event type EV_MSC(0x04): scancode = 0x809d
94.056211: event type EV_SYN(0x00).
95.490676: event type EV_MSC(0x04): scancode = 0x809c
95.490684: event type EV_SYN(0x00).
105.447801: event type EV_MSC(0x04): scancode = 0x1007
105.447809: event type EV_SYN(0x00).
106.716291: event type EV_MSC(0x04): scancode = 0x1001
106.716299: event type EV_SYN(0x00).
108.358447: event type EV_MSC(0x04): scancode = 0x1055
108.358455: event type EV_SYN(0x00).

There I shown output example from three different remotes.

If you will see scancodes as I described, then all very good and we done half of work.
Test it please and let me know, if all Ok then I describe what to do next because I am a little tired by writing so much...

rockchip_cir.zip

[JoKeRz]

Thanks a lot! Will try that this evening and post results.

[B00gieman]

Thanks.
i'll try tomorrow as soon as i get home.

[JoKeRz]

I tested your module and pre-compiled lirc binaries and they work fine as described in your instructions. Awesome job and thanks for sharing!

Let me post here my steps to test and results obtained. I used an MCE Remote (RC6 protocol) to test.
Your lircd has the following paths hardcoded:

/var/run/lirc/lircd
/var/run/lirc/lircd.pid
/var/log/lircd

since I did not want to create /var/run in my android root filesystem, I ended up modifying the binaries so they point to a folder more suitable for this: /data/mylircd

$ cd <folder_I_unpacked_your_package>/lirc
$ sed 's:/var/run/lirc/lircd:/data/mylircd/lircd:g' licrd > lircd.new
$ sed 's:/var/run/lirc/lircd:/data/mylircd/lircd:g' irw > irw.new
$ chmod 755 *.new

Created folders and a first lirc.conf (got it from lirc list of supported remotes)

$ mkdir /data/mylircd/
$ chmod 777 /data/mylircd
$ mount -o "remount,rw" /system
$ cd /etc
$ wget [URL]http://lirc.sourceforge.net/remotes/mceusb/lircd.conf.mceusb[/URL]
$ mv lircd.conf.mceusb lircd.conf
$ chmod 644 lircd.conf
$ mount -o "remount,ro" /system

Load the module and start lircd:

$ cd <folder_I_unpacked_your_package>
$ insmod ./rockchip-cir.ko
$ cd lirc
$ ./lircd.new -L /data/mylircd/lircd.log -d /dev/lirc0

Lirc daemon is running fine and I can receive / check buttons pressed on my mce remote via irw.new.

Next I tried to use those buttons in XBMC (which has a lirc client compiled within it) but that part was not successful yet.
Some buttons (like arrow keys and <enter>) work both in Android dalvik environment as well as XBMC however majority of the other buttons are not detected (do not even show in xbmc log after I enable xbmc debug).

Anyways, I will check further in the next few days. For anyone interested in doing the same I did, I followed the steps described in here:

http://wiki.xbmc.org/index.php?title=Userdata/lircmap.xml

Note that the users's Lircmap.xml go under /sdcard/Android/data/org.xbmc.xbmc/files/.xbmc/userdata/Lircmap.xml
Also note XBMC for android comes with a system Lircmap.xml which already includes the mceusb remote keys. So in theory you do not need to add another one to userdata folder.

[SolarWarez]

Your lircd has the following paths hardcoded:

/var/run/lirc/lircd
/var/run/lirc/lircd.pid
/var/log/lircd

since I did not want to create /var/run in my android root filesystem, I ended up modifying the binaries so they point to a folder more suitable for this: /data/mylircd

I didn't change default paths becuse I compile lirc only for tests and all this parameters may be controlled through lircd command line parameters.
If it's nedeed then I may compile lirc with right paths.

But now, my goal it's to don't use lirc at all.
There are two things why I don't want to use lirc:
1. I found that lirc works bad with my remotes that use NEC protocol. I don't know where is the problem, but when I test remote signals from /dev/lirc0 using mode2 utility then all works fine and I see results by pressing any button on remote. But when I try to learn scancodes using irrecord utility and then run lircd and check it by irw, then almost every second time lirc miss keys that I pressed on remote. So it is very uncomfortably to press buttons twice almost every second time.
But when I tests Samsung TV remote that use they own protocol, then in that case lirc works perfectly and not missing any one keys pressing.
So I think that problem somewhere in lirc space/pulses decoding algorithms.

2. Decoding algorithms that built-in into kernel works well with my remotes and there no needing to use lirc because it become only unnecessary step.

But if you still want use lirc, then I recommend to turn off built-in protocols and use only LIRC protocol that is simply bridge between kernel mode driver and /dev/lircd0 user space device.
To do that you may run "ir-keytable -p LIRC"

So now I want to test XBMC with my remote without using lirc as described there http://forum.xbmc.org/showthread.php?tid=114124 or there http://wiki.xbmc.org/index.php?title=Keymap

PS: IMHO, there is pitfall in how android works with key input subsystem. I don't know is it common case or it is a result of rockchip's modifications (I am not professional in Android) but when I made my driver and make sure that pressing on remote generates appropriate key events with right values then I noticed that some keys didn't cause reaction from android environment. For example left/right/up/down keys works fine but home/back/ok keys didn't works. I found that solution is to create appropriate *.kl file (you may find it in my archive). After that all buttons begin works fine. But maybe reason in wrong key codes assigned with scancodes? I didn't have time to investigate so deeply.

[hpm76]

Great work and idea SolarWarez. I hope we can soon use virtually any remote with our devices, and I also hope rom devs will bring this in by default in their next releases. I will also play around with this module and share my findings trying to make a xbox classic controller work. Regards, hpm76