remote controllo original cubox

[skelosParticipant]

Hello,
In my originale cubox i would to setup a generic windows media center remote control.

This model is not supported from Solid-run and many references are broken.

Could you list me steps i need to do form this?

Tjank you.

[Warped RudiModerator]

I have the “Microsoft with Teletext” as shown in this article and it works out of the box using the Cubox’ built-in IR receiver. At least last time I tried ? I *think* that the Zotac shown here might work as well…

Edit: The Zotac remote seems to have a problem causing every second keystroke to be ignored. The Microsoft one works fine. The MCE Keyboard also works to some degree. But I have not yet figured out how to use the keyboard/mouse functionality within XBMC.

[skelosParticipant]

Wonderfull! I found a lirc.conf file with mapped all my remote keys! I test it with irw and it works fine: kaye are sniffed successfully. But I think to have miss last step.
I changed device name in Lircmap.xml to one in lirc.conf but XBMC appears not be interested to this: each key pressed I don’t see reactions from XBMC.

I need to enable something in XBMC GUI?

[Warped RudiModerator]

I changed device name in Lircmap.xml to one in lirc.conf

I would try to avoid this. I.e. use the “legacy” lircd/lircd.conf approach only when your IR receiver is not supported by the kernel rc_core subsystem. Instead:

1.) Figure out if your remote is listed in /etc/rc_keymaps
2.) If your remote is present, modify /usr/bin/change-rc accordingly and execute it.
3.) If your remote is not present in /etc/rc_keymaps
3a.) Use systemctl to stop the ‘kodi’ and ‘eventlircd’ services.
3b.) Run ir-keytable -t and check if key codes are arriving.
3c.) If not, check the man pages for ir-keytable on how to activate different RC protocols.
3d.) Once keycodes are showing up, use them to create your own config file in /etc/rc_keymaps
3e.) Restart the services and continue with step 2.) or simply reboot.
3f.) If you have created a new config file, let us know and share it with us.

[skelosParticipant]

My remote is not present. So, I made my own file (named ‘samsung’ ) with keys :

# table rc6_mce, type: RC6
0x40BF BTN_POWER     
0xD827 BTN_TV        
0x20DF BTN_1         
0xA05F BTN_2         
0x609F BTN_3         
0x10EF BTN_4         
0x906F BTN_5         
0x50AF BTN_6         
0x30CF BTN_7         
0xB04F BTN_8         
0x708F BTN_9         
0xC43B BTN_MINUS     
0x8877 BTN_0         
0xC837 BTN_PRE_CH    
0xF00F BTN_MUTE      
0x807F BTN_SOURCE    
0xE01F KEY_VOLUMEUP  
0xD02F KEY_VOLUMEDOWN
0x48B7 BTN_CH+       
0x08F7 BTN_CH-       
0xD629 BTN_CH_LIST   
0x58A7 BTN_MENU      
0x22DD BTN_FAV_CH    
0xD22D BTN_TOOLS     
0x1AE5 BTN_RETURN    
0xF807 BTN_INFO      
0xB44B KEY_EXIT      
0x06F9 BTN_UP        
0xA659 BTN_LEFT      
0x46B9 BTN_RIGHT     
0x8679 BTN_DOWN      
0x16E9 BTN_ENTER     
0x36C9 BTN_RED       
0x28D7 BTN_GREEN     
0xA857 BTN_YELLOW    
0x6897 BTN_BLUE      
0x7C83 BTN_PSIZE     
0xF20D BTN_GUIDE     
0xA45B BTN_CC

These keys are recognized from irw. I changed /usr/bin/change-rc file to point to my samsung file and executed it: nothing change…
After execution irw doesn’t reply any more. So I think that my remot don’t use mce/rc6 protocol: change-rc execution change it.

So, how I can discorver what protocol is ok?

This is output of my ir-keytable command:

root@geexbox:~# ir-keytable command

Found /sys/class/rc/rc0/ (/dev/input/event0) with:
        Driver gpio-rc-recv, table rc-empty
        Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC RC-5-SZ other
        Enabled protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC RC-5-SZ other
        Repeat delay = 500 ms, repeat period = 125 ms

[Warped RudiModerator]

Please use the key names as found in the rc6_mce and rc_mce2 files (and in Lircmap.xml section ‘devinput’).
Furthermore give the table a distinctive name (first line). The output of ir-keytable shows that you have all protocols enabled. I think the only way to figure out which one is really used is to disable them selectively. Remotes from Samsung TVs appear to be using the NEC protocol. But if it’s a remote specifically made for Microsoft Mediacenter, then RC6 is more likely.
I assume the hex values in your table were obtained from the output of ir-keytable -t, right?

[skelosParticipant]

I solved, now my remote works fine.

I reply to you quesrtion and after I speack about solution I found hoping this will be usefull in feature for other people.

Hex values are not been obtained from ‘ir-keytable -t’ but from this file http://lirc.sourceforge.net/remotes/samsung/BN59-00685A

My assunmption was that same Samsung remote key has same hex code. So, Samsung hex code doesn’t depend from remote model. This was true. I get mentioned file from sourceforge website and applied to my original cubox.
My fault was I name differently keys in /etc/lirc/lircd.conf file (in cubox it is /etc/lirc/myremote.conf) and /root/root/.xbmc/userdata/Lircmap.xml file. So, in lircd.conf key was named BTN_OK and in Lircmap.xml it was KEY_OK. Names doesn’t matches and therefore system doesn’t work.

Newbye error! ^_^

Just check if all remote button where correctly sniffed and chenged in Lircmap.xml file. Rebooted and it works.

You can close thread.

[Warped RudiModerator]

Great. However, it’s not the solution I wanted to describe.

In geexbox there are two basic approaches how IR remotes are handled: By default (i.e. /etc/lirc/myremote.conf does not exist), we are *NOT* using lircd (and the files in /etc/lircd) at all! Instead we, rely on the rc-core subsystem. That means the protocol decoders are kernel drivers that directly feed /dev/input/eventX. The config files in /etc/rc_keymaps are used, which get loaded into the kernel by ir-keytable -w. The key codes listed in /etc/rc_keymaps/* are *NOT* identical to the ones found in /etc/lirc/remotes/*. However, they can be obtained by running ir-keytable -t. A lircd-compatible interface is provided by eventlircd, which also handles HID-compatible remote control receivers. You can see this approach in the two leftmost columns of the picture on this page. On the XBMC/KODI side, all remotes that go though this end up in the same section ‘devinput’ in Lircmap.xml using standardized KEY_xxxx names.

Creating /etc/lirc/myremote.conf switches the whole thing to a completely different flow of information. It enables lircd, which does the protocol decoding outside the kernel and does make use of the files in /etc/lirc/remotes. The files in /etc/rc_keymaps as well as /usr/bin/change-rc are now ignored. Unlike shown in the picture mentioned above, we do not provide lircd2uinput. We use lircd and eventlircd alternatively. Thus XBMC/KODI in this case will connect directly to lircd and use the other sections of Lircmap.xml. Note that lircd needs a different type of device driver for the IR receiver hardware than rc-core. However, rc-core can expose an emulated /dev/lirc0. This will happen on the Cubox for it’s gpio-ir-recv device.

Both approaches have advantages and disadvantages. The rc-core subsystem with it’s in-kernel protocol decoders is pretty much self-contained and provides a more standardized system-wide interface to all supported remotes. However, it does not have all the functionality of the classic lirc. Especially when it comes to “non-standard” protocol variants used by some remotes.

[Author]

Posts