[mythtv-users] Anyone Using LIRC on CentOS 6.6?

[Alec Leamas]

On 04/06/15 18:11, Kirk Bocek wrote:

> Argh... still no output from ir-keytable.
>
> $ir-keytable
> Found /sys/class/rc/rc4/ (/dev/input/event14) with:
>          Driver mceusb, table rc-rc6-mce
>          Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
>          Enabled protocols: RC-6
>          Name: Media Center Ed. eHome Infrared
>          bus: 3, vendor/product: 0471:0815, version: 0x0000
>          Repeat delay = 500 ms, repeat period = 33 ms
>
> $ir-keytable -t -d /dev/input/event14
> Testing events. Please, press CTRL-C to abort.
> ^C

IMHO, you are trying to do too many things at once: Checking the 
ir-keytable status, create a udev rule and other things. The 
configuration is really a decision tree, and we need to bring some order 
into this.

As far as I understand, the kernel decoding just doesn't work for your 
remote. This is demonstrated by above, and is probably related to the 
decoding bit error messages in one of your first posts.

One way could be to try to fix this. The ir-keytable manpage mentions 
several options, notably the protocol to use. However, I have no 
experience with this, sorry.

If you just accept that the kernel decoding doesn't work this also means 
that the lirc devinput driver won't work (since it uses the decoded 
kernel output).

You then could trry to use the lirc decoding instead. This requires that 
you can enable the lirc protocol by doing something like "sudo echo 
'lirc' >/sys/class/rc/rcX/protocols. This should work, the possible 
caveats are permission problem or wrong device (use the rc/rcX device 
reported by ir-kaytable).

Once this this works you should be able to check the raw timing data on 
/dev/lirc0 using mode2. This is described in a link I won't repeat :)

If you have this data, you could run lircd using "--device /dev/lirc0 
--driver default". With a proper lircd.conf file should be fine. You 
could also use irrecord(!) to try to roll your own.

This also means that as long as you don't plan to fix the kernel 
decoding there's no point with a udev rule for fixed device names.

Cheers!

--alec