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

[Tom Dexter]

On Thu, Aug 24, 2017 at 10:28 AM, Tom Dexter <digitalaudiorock at gmail.com> wrote:
> On Thu, Aug 24, 2017 at 3:15 AM, Alec Leamas <leamas.alec at gmail.com> wrote:
>>
>>
>> At this point, the general idea is that something changed in the kernel
>> output in the 4.9.34 to 4.12,5 transition, right? Then, IMHO, we need to
>> first establish this fact. This could be done by comparing the output from
>> mode2 with the different kernels, pushing exactly one remote button. It's
>> not a simple diff, one needs to manually compare them side by side, but it's
>> doable.
>>
>> If indeed there is a difference, it's a confirmed kernel issue. You must
>> then approach the kernel devs.  The first they will want is a git bisect
>> pinpointing the bad kernel commit causing this, so you might as well do that
>> bisect in advance.  You 'll need some cycles also for that but again, it's
>> doable.
>>
>> After all, I have done it :)
>>
>> Cheers!
>> --alec
>
> Good idea. I've attached those. I'm assuming that being basically raw
> pulses this is far from exact, but it certainly appears to me
> scrolling these side by side in vi that these are every bit as close
> to each other as I get from multiple attempts with the same kernel and
> the same IR button. Tell me if it looks that way to you.
>
> Would that point instead to some decoding issue? If so, where exactly
> does that even occur? I'm still very confused on all that, as I
> originally assumed that was in drivers/media/rc/ir-lirc-codec.c.
>
> Tom

A user on the gentoo forum (thanks P.Kosunen) noticed something in my
logs that at least clears up part of this: The serial_ir does in fact
use ir-lirc-codec (via rc0 and lirc_dev):

Aug 24 09:50:57 mythfront kernel: rc rc0: lirc_dev: driver
ir-lirc-codec (serial_ir) registered at minor = 0

This also explains why I got no /dev/lirc0 device at all without
having that loaded.

The old kernel with the staging lirc_serial (which again, still works)
uses a driver of lirc_serial (via lirc_dev, with no rc):

Aug 24 11:01:32 mythfront kernel: lirc_serial lirc_serial.0: lirc_dev:
driver lirc_serial registered at minor = 0

Also note that the working lirc_serial does in fact use /dev/lirc0 and
the default driver. That, combined with the fact that the mode2 data
from /dev/lirc0 and the default driver from both the old and the new
setup seem to jive would seem to imply that my setup is correct. That
would seem to imply that something in the new decoding is somehow off,
despite the fact that I have all known patches to ir-lirc-codec
applied:

--- drivers/media/rc/ir-lirc-codec.c-old        2017-08-21
22:51:33.000000000 -0400
+++ drivers/media/rc/ir-lirc-codec.c    2017-08-24 02:48:54.000000000 -0400
@@ -263,10 +263,7 @@
                return 0;

        case LIRC_GET_REC_RESOLUTION:
-               if (!dev->rx_resolution)
-                       return -ENOTTY;
-
-               val = dev->rx_resolution;
+               val = dev->rx_resolution / 1000;
                break;

        case LIRC_SET_WIDEBAND_RECEIVER:
@@ -370,11 +367,8 @@
        if (rc)
                goto rbuf_init_failed;

-       if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+       if (dev->driver_type != RC_DRIVER_IR_RAW_TX)
                features |= LIRC_CAN_REC_MODE2;
-               if (dev->rx_resolution)
-                       features |= LIRC_CAN_GET_REC_RESOLUTION;
-       }
        if (dev->tx_ir) {
                features |= LIRC_CAN_SEND_PULSE;
                if (dev->s_tx_mask)

So that's where I'm at with this.

Tom