# Kernel 4.12.5 and lirc_serial move to serial_ir

## tld

I posted most of this to the mythtv mailing list. I hope maybe someone has a clue what could be wrong here:

I've been using lirc_serial compiled into my kernel with lircd-0.9.4a with no problems for quite some time now. I'm trying to upgrade from kernel 4.9.34 to 4.12.5. Apparently lirc_serial was moved out of the staging drivers and was renamed serial_ir:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa5dc29c1fcc9151c3bcfd9e291a2899ae15f61d

...but from what I'm running into it appears it must me more complex than that. First I enabled the new driver:

```
IR_SERIAL

   Location:

     -> Device Drivers

       -> Multimedia support (MEDIA_SUPPORT [=y])

         -> Remote Controller devices (RC_DEVICES [=y])

Label: Homebrew Serial Port Receiver
```

However with that I got no /dev/lirc0 device at all. I was able to correct that by adding this:

```
IR_LIRC_CODEC

   Location:

     -> Device Drivers

       -> Multimedia support (MEDIA_SUPPORT [=y])

         -> Remote controller decoders (RC_DECODERS [=y])

       -> LIRC interface driver (LIRC [=y])

Label: Enable IR to LIRC bridge
```

That at least corrected that issue and I'm now getting a /dev/lirc0 device. What's perplexing is why, if this was just a move and rename, did I NOT require that before? This may be related to the mess below regarding the kernel rc0 crap.

So now here's where I'm at: I CAN in fact get raw output with "cat /dev/lirc0" when hitting remote buttons, and the mode2 program seems to indicate that my /etc/lirc/lirc_options.conf, most notably the "default" driver is apparently correct.

Yet I get NOTHING in irw, or in any applications (including mythtv). Mind boggling. Everything else just plain looks fine.

Here's what the lircd startup looks like:

```
/etc/init.d/lircd start

 * Starting lircd ...

 * Setting lirc protocol active for rc0
```

...with this in the message log:

```
Aug 21 18:47:03 mythfront lircd-0.9.4a[1526]: Info: lircd:  Opening log, level: Info

Aug 21 18:47:03 mythfront lircd-0.9.4a[1526]: Info: Initial device: /dev/lirc0

Aug 21 18:47:03 mythfront lircd-0.9.4a[1526]: Info: [lirc] protocol is enabled

Aug 21 18:47:03 mythfront lircd-0.9.4a[1526]: Info: Initial device: /dev/lirc0

Aug 21 18:47:03 mythfront lircd-0.9.4a[1526]: Info: [lirc] protocol is enabled

Aug 21 18:47:03 mythfront lircd-0.9.4a[1526]: Info: lircd:  Opening log, level: Info

Aug 21 18:47:03 mythfront lircd-0.9.4a[1526]: Warning: Running as root

Aug 21 18:47:03 mythfront lircd-0.9.4a[1526]: Info: Using remote: TIVO34.

Aug 21 18:47:03 mythfront lircd-0.9.4a[1527]: Notice: lircd(default) ready, using /var/run/lirc/lircd
```

That all looks perfectly normal, and it's using the correct TIVO34 remote configurtation. Here are log messages regarding serial_ir:

```
grep serial_ir /var/log/messages

Aug 21 18:56:49 mythfront kernel: serial_ir serial_ir.0: auto-detected active low receiver

Aug 21 18:56:49 mythfront kernel: rc rc0: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0

Aug 21 18:56:49 mythfront kernel: rc rc0: lirc_dev: driver ir-lirc-codec (serial_ir) registered at minor = 0

Aug 21 18:56:49 mythfront kernel: input: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0/input1
```

I think this confusing mess is related: The init script is generating the message "Setting lirc protocol active for rc0" based on the existence of /sys/class/rc/rc0/protocols which is clearly related to the /devices/platform/serial_ir.0/rc/rc0 referenced above. However with the old kernel and lirc_serial, none of that exists at all, and I don't get those messages at all. The lirc_serial device appears to be under /sys/devices/platform/lirc_serial.0/lirc/lirc0, /sys/class/rc is empty, and there appears to be a /sys/class/lirc/lirc0 directory with nothing resembling that protocol entry at all.

So clearly there's something radically different about this serial_ir driver...or it sure looks that way.

I don't think I've ever been this stumped. Any help would be appreciated.

Tom

----------

## tld

Just update this a little bit. Still no luck. However I have figured out one part of this based on inf from Alec with the LIRC project (at least I think I have this right). Apparently when using /dev/lirc0 and the default driver, the kernel decoding should NOT be used at all. So my addition of IR_LIRC_CODEC was apparently altogether wrong.

So now my issue is that, without it, /dev/lirc0 never gets created and I have no idea why. Here's what I have in the kernel:

```
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
```

As far as I can determine that's correct. I tried changing lirc_dev and serial_ir to modules to see if that would affect the creation of /dev/lirc0 but no luck.

If anyone has any insight as to what's even supposed to create that, let me know. This is, without ANY question, the single most horrible thing I've ever wrestled with in 17 years using Linux. Nothing else is even in the same universe.

TomLast edited by tld on Wed Aug 23, 2017 4:46 am; edited 1 time in total

----------

## Hu

For the benefit of future readers, could you provide direct links to the relevant MythTV mailing list posts?

----------

## tld

 *Hu wrote:*   

> For the benefit of future readers, could you provide direct links to the relevant MythTV mailing list posts?

 Yup...will do that later today. Also note that it appears my previous post was correct after all. That is, that no kernel decoders are in use when using /dev/lirc0 and the "default" driver. That is, when it's using the lirc protocol. For whatever reason, that setup for me is clearly getting radically different data from serial_ir as it was from the old lirc_serial and just refuses to work.

Tom

----------

## tld

Here's the painful ordeal on the mythtv-users mailing list:

https://lists.gt.net/mythtv/users/610757 [Moderator note, in case this site disappears or migrates, forcing future readers to search for alternate archives: thread title lirc_serial move to serial_ir nightmare in kernel 4.12 with first post Aug 21, 2017. -Hu]

There's a little more on the lirc list here:

https://sourceforge.net/p/lirc/mailman/message/36006423/ [Thread title Recent threads on lirc_serial serial_ir with first post 2017-08-22. -Hu]

One important note on that: As far as I've been told, it turns out that all the bugs mentioned regarding drivers/media/rc/ir-lirc-codec.c should be moot in my case where the /dev/lirc0 device and the default driver are in use, as that is supposedly only used in conjunction with the devinput driver and kernel decoding.

Tom

----------

## P.Kosunen

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/media/rc/ir-lirc-codec.c?id=v4.13-rc4&id2=v4.13-rc3

If lirc does not work at all, check that above fix is in your kernel source.

At least sys-kernel/gentoo-sources-4.12.8 is already fixed.

----------

## tld

Actually I do have that fix. As well a reversal of a commit that apparently caused  issues as well, and was changed in 4.12.6. However from what I've been told by Alec (from the LIRC project), that ir-lirc-codec is NOT used unless you're using devinput with kernel decoding, and not when you're using /dev/lirc0 and the default driver...which sort of surprised me. So theoretically in my case that's moot.

Thanks!

Tom

----------

## P.Kosunen

```
Aug 21 18:56:49 mythfront kernel: rc rc0: lirc_dev: driver ir-lirc-codec (serial_ir) registered at minor = 0
```

I think this means ir-lirc-codec is used with serial_ir. I use nuvoton-cir kernel driver with "driver = default" option and /dev/lirc0, but ir-lirc-codec and lirc-dev modules are also in use and cannot be disabled or lirc does not work.

```
/etc/conf.d/lircd:

LIRCD_SET_SYSCLASSRCS="lirc"
```

Did you have this option enabled when you tested different data between serial_ir and old lirc_serial? Did you test with irw at this point, no double commands etc?

----------

## tld

 *P.Kosunen wrote:*   

> 
> 
> ```
> Aug 21 18:56:49 mythfront kernel: rc rc0: lirc_dev: driver ir-lirc-codec (serial_ir) registered at minor = 0
> ```
> ...

 I'm sure you're correct. I knew that didn't sound correct. I just looked for that in my last test using the default driver:

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

 *P.Kosunen wrote:*   

> 
> 
> ```
> /etc/conf.d/lircd:
> 
> ...

 

Actually I don't, but I don't think that's correct. That setting is intended to have one or mode entries that will exist under /sys/class/rc/. You can even see that in the init script, and there's never anything other than, for example, rc0. It's clearly using the default driver, and the lirc protocol. Note that with the old lirc_serial driver here in fact WAS no rc0 created at all, and /sys/class/rc/ is empty. With lirc_serial I also did NOT need ir-lirc-codec at all, as it used it's own lirc_serial driver:

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

What's happening specifically is that mode2 is working, and just this morning, I tested the mode2 output from the same button using the old and new kernels (lirc_serial vs serial_ir) and they appear to be as close to being the same as you'd expect. However with serial_ir, irw recognizes nothing at all...and while I can generate a config with irrecord (which is wildly different from the one that should work for my remote), irw doesn't work with that either.

So it seems that the decoding is somehow broken.

Tom

----------

## tld

In case anyone's curious as to the final outcome with all this, I had to give up. Ultimately I ended up ditching LIRC in favor of ir-keytables which works fine with my home brew serial port IR receiver, the serial_ir kernel code, and my TIVO34 remote.

The whole ordeal was nothing short or mind boggling frankly. What especially makes no sense is that, despite the fact that everything implies this was simply a move of lirc_serial out of staging and a rename to serial_ir, it appears that serial_ir with lirc is requiring and using ir-lirc-codec, even though lirc_serial did not. Nobody seems to even know what lirc and serial_ir require in the kernel when used either with default driver or with devinput. Never mind that the public was totally blind-sided by this with no announcement whatsoever. I could have lived with that if I could have gotten it working.

The fact that lirc's mode2 works with the default driver and seems to be getting data identical to that from the old lirc_serial, combined with the fact that the data getting to both irw and even irrecord is RADICALLY different, seems to imply that there's totally broken decoding happening with lirc and serial_ir for some reason. The fact that ir_keytables with serial_ir and the kernels IR_NEC_DECODER (my remote uses and NEC protocol apparentl) work also supports that.

So there it is...still 95% mystery. I'm not sure I ever want to hear the term LIRC again.

TomLast edited by tld on Tue Aug 29, 2017 9:07 am; edited 1 time in total

----------

## tld

One other side note here: My first attempt using ir-keytable was with a new MCE USB receiver I bought, but that suffered from way too much lag with ir-keytable...totally unusable. This may simply be that the MCE doesn't like the signal from my remote...not sure about that. ir-keytable with my serial port receiver is flawless.

In fact, the MCE actually worked with LIRC...almost...but it would completely stop working for 30 seconds to over a minute periodically making it unusable for that too. Again, this may just be specific to my remote with the MCE. That all leaves me totally unsure of what I would use with a new system where I had to use USB...especially if I want to keep my TIVO remote (which I do). Perhaps some other USB receivers I've seen suggested (like the iguanaIR) would cooperate more.

Tom

----------

## sidamos

Just a FYI: New LIRC serial module works fine for me with kernel 4.14.8-r1 and Technotrend remote.

I enabled in the kernel config:

CONFIG_IR_SERIAL=m

CONFIG_IR_SERIAL_TRANSMITTER=y

/etc/conf.d/modules:

modules_4_14="${modules_4_14} serial_ir"

module_serial_ir_args_4_14=""

/etc/modprobe.d/lirc.conf:

install serial_ir setserial /dev/ttyS0 uart none; modprobe --ignore-install serial_ir

The settings in /etc were already there before, I just changed lirc_serial to serial_ir.

----------

## tld

 *sidamos wrote:*   

> Just a FYI: New LIRC serial module works fine for me with kernel 4.14.8-r1 and Technotrend remote.

 Thanks for this! I think I'm sticking with ir-keytable, but just out of curiosity...are you using the default driver? Also, could you post the output of lsmod? When I was trying to get this working nobody seemed to really know for sure what else was required with ir_serial, for example the lirc_codec etc. Thanks!

Side note: I almost didn't see this because apparently the "View your posts" link on the forum has some time limit despite the fact that this thread had recent activlty. Anyone know what's up with that?

Tom

----------

## sidamos

Hmm, I guess, I am using the default driver? Where would I see this? I have this in  /etc/conf.d/lircd:

LIRCD_SET_SYSCLASSRCS="rc0"

lsmod reports:

serial_ir              12288  0

Before, it reported lirc_serial.

Regarding notifications:

Do you not have "Notify me" enabled for this thread? Then you should get an email.

----------

## tld

Thanks! I didn't have notifications on this thread actually.

On the driver that would be in /etc/lirc/lirc_options.conf:

```
[lircd]

nodaemon        = False

driver          = default

device          = /dev/lirc0

output          = /var/run/lirc/lircd

...etc...
```

Specifically that driver line. What I was wondering about lsmod was whether there were other loaded modules (dependencies) that referenced serial_ir, most notably lirc_codec.

Thanks!

Tom

----------

## sidamos

I do not have the file /etc/lirc/lirc_options.conf.

----------

## tld

Wow...extremely strange. That's been installed by all lirc-0.9.x versions that I'm aware of:

```
equery b /etc/lirc/lirc_options.conf

 * Searching for /etc/lirc/lirc_options.conf ... 

app-misc/lirc-0.9.4a-r2 (/etc/lirc/lirc_options.conf)
```

Anyway...not important. I was mostly curious. lirc is a total blank hole, which is why I moved to ir-keytable.

Thanks!

Tom

----------

## sidamos

equery files lirc | grep options

-> nothing

app-misc/lirc-0.9.0-r6

----------

