[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