[mythtv-users] lirc_serial move to serial_ir nightmare in kernel 4.12

Tom Dexter digitalaudiorock at gmail.com
Tue Aug 22 20:30:25 UTC 2017


On Tue, Aug 22, 2017 at 4:06 PM, Tom Dexter <digitalaudiorock at gmail.com> wrote:
> On Tue, Aug 22, 2017 at 3:38 PM, Alec Leamas <leamas.alec at gmail.com> wrote:
>>
>>
>> On 22/08/17 21:26, Tom Dexter wrote:
>>>
>>> On Tue, Aug 22, 2017 at 2:48 PM, Alec Leamas <leamas.alec at gmail.com>
>>> wrote:
>>>>
>>>>
>>>> You have noted that here are two paths, right? One which uses the kernel
>>>> decoding (ir-lirc-codec etc), an event device and the devinput driver.
>>>> And
>>>> one bypassing the kernel decoding, using the /dev/lirc0 device and the
>>>> default driver? And that the latter part requires that the kernel
>>>> decoding
>>>> is disabled i. e., that only the lirc protocol is enabled in the
>>>> /sys/class/rc/rc0 device?
>>>>
>>>>
>>>> Cheers!
>>>>
>>>> --alec
>>>
>>>
>>> Wow...I'm a bit confused, but this may be the whole issue. If you're
>>> saying that the latter...that is the use of /dev/lirc0 and the default
>>> driver...should NOT be using ir-lirc-codec at all, and should be
>>> bypassing the kernel decoding, then that's clearly my problem right
>>> there. However it brings up the other issue I mentioned in the first
>>> post:
>>>
>>> When I first enabled serial_ir in the kernel (IR_SERIAL, which I
>>> enabled built in, and not as a module), I didn't get ANY /dev/lirc0
>>> device at all. The only way I could get it to create /dev/lirc0 was by
>>> enabling IR_LIRC_CODEC, which seemed odd. If I'm understanding what
>>> you're saying correctly, then that was clearly a mistake. However I'd
>>> also need to know why I'd get no /dev/lirc0 with SERIAL_IR enabled
>>> directly in the kernel.
>>>
>>> OGM...I think I may have just figured it out. I probably shouldn't
>>> have RC_DECODERS enabled at all should I. Would that prevent
>>> /dev/lirc0 from getting created without enabling a decoder?
>>
>>
>>
>> This is basically an internal kernel/driver issue above my paygrade. IIRC,
>> most drivers actually create the /dev/lircX device when loaded, but only
>> send data to it if the lirc protocol is enabled in
>> /sys/class/rc/rc0/protocols.
>>
>> When so, the other protocols should be disabled - if not for other reasons,
>> anything decoded by the kernel is just a pain when using the lircd decoding.
>>
>>
>>
>> Cheers!
>> --alec
>
> Maybe you cat at least clear me up as to what I actually should have
> enabled in the kernel, as I'm more confused than ever looking at the
> config options:
>
> Here's what I have:
>
> grep LIRC .config
> CONFIG_LIRC=y
> # CONFIG_IR_LIRC_CODEC is not set
>
> grep IR_SERIAL .config
> CONFIG_IR_SERIAL=y
> # CONFIG_IR_SERIAL_TRANSMITTER is not set
>
> grep RC_SUPPORT .config
> CONFIG_MEDIA_RC_SUPPORT=y
>
> Do you now of anything else I should need?
>
> With that however I still get no /dev/lirc0 device. It's possible that
> could be somehow related to the fact that I have it built into the
> kernel. At least I'm clear that using CONFIG_IR_LIRC_CODEC was totally
> wrong in this case.
>
> Tom

I just tried changing both the lirc_dev and serial_ir to modules
loaded at boot time:

lsmod
Module                  Size  Used by
nvidia_modeset        811008  3
serial_ir              16384  0
lirc_dev               16384  0
nvidia              11517952  61 nvidia_modeset
nvidia_drm             16384  0

Still no /dev/lirc0 getting created. Awful.

Here's what I get when starting lircd:

/etc/init.d/lircd start
 * Starting lircd ...
 * Setting lirc protocol active for rc0

That last line is echoing to this:

cat /sys/class/rc/rc0/protocols
rc-5 nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp [lirc]

Is that how thats intended to look? I think you said that it should
only have lirc?

Tom


More information about the mythtv-users mailing list