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

[Alec Leamas]

On 05/06/15 01:32, Kirk Bocek wrote:

> On 6/4/2015 1:18 PM, Alec Leamas wrote:

> Well I am confused on this kernel decoding issue. I thought the choice
> was LIRC using /dev/lirc0 or devinput using /dev/input/eventXX. I
> thought only one or the other uses kernel decoding. Now you tell me
> *both* uses kernel decoding.

You got me wrong (my bad?) When using the devinput user-space driver, 
lirc gets it's input from the kernel decoding. When using other 
user-space drivers, lirc makes the decoding internally.

>> 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 :)
>
> Finally! Some output
>
> space 900
> pulse 750
> space 2550
> pulse 800
> space 6146
> pulse 550
>
> The receiver is active and getting input from my remote. But I knew this
> from the error messages.
>
>>
>> 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 is (I think) what I started with. Not specifying the device means
> LIRC uses /dev/lirc0.

To be sure you need to enable debugging, which on 0.9.0 means rebuilding 
lirc. In your situation I would certainly explicitly set the device to 
be sure.

> Not specifying the driver means it uses whatever
> is loaded, mceusb in my case.

Here is some confusion about "driver". Using lirc means there are two 
drivers involved: The kernel driver (here mceusb) and the lirc 
user-space driver. The default user-space driver is a driver which works 
on top of lirc-aware kernel drivers such as mceusb.

For usb devices, the kernel automatically loads the correct kernel 
driver, we don't have to mess with this. We must still specify the 
user-space driver, though.

The term "user-space driver" is actually a misnomer. See it as a plugin, 
it's a better idea. The term is just historical.

> $echo 'lirc' >/sys/class/rc/rc5/protocols
> $cat /sys/class/rc/rc5/protocols
> rc-5 nec rc-6 jvc sony [lirc]

This looks fine. The [lirc] here means that lirc is the enabled protocol

> Reset /etc/sysconfig/lirc to:
> LIRC_DRIVER=""
> LIRC_DEVICE=""

 From above, set DEVICE=/dev/lirc0 and DRIVER=default.

> $service lirc restart
>
> And more of the same with irw:
>
> Jun  4 16:28:05 marble lircd-0.9.0[12108]: failed on bit 1
> Jun  4 16:28:05 marble lircd-0.9.0[12108]: failed on bit 5
> Jun  4 16:28:05 marble lircd-0.9.0[12108]: failed on bit 13
> Jun  4 16:28:05 marble lircd-0.9.0[12108]: failed on bit 13

So, lircd cannot decode the input... try first with correct 
configuration. Otherwise, we will need to use irrecord to make a new 
lircd.conf

> So when you say "fix kernel decoding" is this what you meant?

No. I meant using ir-keytable and it's various options without setting 
the kernel driver protocol to lirc. Perhaps, you could then make the 
kernel decoding work, which then could be shown using ir-keytable -t, 
not involving lirc in any way. But again, this is unchartered territory 
for me. It's also  a completely other route than the rest of this 
message possibly involving the devinput driver, changing device names, 
udev rules and so forth.


Cheers!

--alec