Dietpi: Hardware | LIRC does not work with current RPi 4.19 kernel

[AlexanderShniperson]

Creating a bug report/issue

Required Information

• DietPi version |

G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=28
G_DIETPI_VERSION_RC=0

• Distro version | 10.2
• Kernel version | Linux DietPi 4.19.93-v7+ #1290 SMP Fri Jan 10 16:39:50 GMT 2020 armv7l GNU/Linux
• SBC device | RPi 3 Model A+ (armv7l)
• Power supply used | 5V 1A RAVpower

Additional Information (if applicable)

• Software title | Lirc - installed by APT
• Was the software title installed freshly or updated/migrated? - fresh install
• Can this issue be replicated on a fresh installation of DietPi? - yes

Steps to reproduce

1. Install LIRC package
2. setup configs
3. send some IR-command by irsend

Expected behaviour

lircd receive signal and broadcast to clients

Actual behaviour

nothing received, also in logs Cannot configure the rc device for /dev/lirc0

Extra details

setup was done by this instruction without luck: https://github.com/mtraver/rpi-ir-remote
Used IR-receiver TSOP31238 and IR-led TSAL6200

Possible solution: downgrade kernel to 4.14 because many users told that LIRC work fine with that kernel version

How to downgrade kernel to 4.14 ?

[Joulinar]

Hi,

many thanks for your report. Basically this could be an answer on your question. But I never did this by my own. So don't know if this will work.

https://isahatipoglu.com/2015/09/29/how-to-upgrade-or-downgrade-raspberrypis-kernel-servoblaster-problem-raspberry-pi2/

[AlexanderShniperson]

dietpi doesn't have rpi-update utility

[Joulinar]

yes, you would need to install it as described an the link

apt-get update
apt-get install rpi-update

[AlexanderShniperson]

missed that part
ok, found kernel version 4.14.98 after run
sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b
after success install and reboot i see uname -a outputs
Linux DietPi 4.19.93-v8+ #1290 SMP PREEMPT Fri Jan 10 16:51:04 GMT 2020 aarch64 GNU/Linux

it doesn't work

[Joulinar]

hmm probably something to ask on the raspberry board as DietPi is not providing any own kernel. Maybe guys at raspberry knows whats going on. As I see it updated to 64Bit (aarch64), which is quite strange. Maybe is an issue to display current version correctly.

root@DietPi3:~# rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
#############################################################
This update bumps to rpi-4.14.y linux tree
Be aware there could be compatibility issues with some drivers
Discussion here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=197689
##############################################################
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   168  100   168    0     0    437      0 --:--:-- --:--:-- --:--:--   437
100 56.3M    0 56.3M    0     0  1800k      0 --:--:--  0:00:32 --:--:-- 2388k
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 4.14.98-v7+
 *** depmod 4.14.98+
 *** Updating VideoCore libraries
 *** Using HardFP libraries
 *** Updating SDK
 *** Running ldconfig
 *** Storing current firmware revision
 *** Deleting downloaded files
 *** Syncing changes to disk
 *** If no errors appeared, your firmware was successfully updated to a08ece3d48c3c40bf1b501772af9933249c11c5b
 *** A reboot is needed to activate the new firmware
root@DietPi3:~# reboot

available kernel modules should be visible at ls -la /lib/modules/

[AlexanderShniperson]

ls shown this

root@DietPi:/# ls -la /lib/modules/
total 32
drwxr-xr-x  8 root root 4096 Apr 21 11:38 .
drwxr-xr-x 17 root root 4096 Apr 21 11:37 ..
drwxr-xr-x  3 root root 4096 Apr 21 11:39 4.14.98+
drwxr-xr-x  3 root root 4096 Apr 21 11:38 4.14.98-v7+
drwxr-xr-x  3 root root 4096 Jan 25 17:03 4.19.93+
drwxr-xr-x  3 root root 4096 Jan 25 17:12 4.19.93-v7+
drwxr-xr-x  3 root root 4096 Jan 25 17:03 4.19.93-v7l+
drwxr-xr-x  3 root root 4096 Jan 25 17:03 4.19.93-v8+

[MichaIng]

@AlexanderShniperson
Kernel 4.14 is installed but 4.19 is still there as well. To see which is active: ls -Al /boot
One problem is indeed that you enabled 64 bit kernel and the 64 bit kernel modules might not be compatible with 32 bit user space software, like lircd. There is a /DietPi/config.txt to enable/disable 64 bit kernel and this is what I would try first before downgrading the kernel.

[AlexanderShniperson]

@MichaIng today i also try to setup LIRC by instrunction from elmicha commented on 30 May 2019
when i try to send signal
irsend --device=/var/run/lirc/lircd-tx SEND_ONCE TANK-64 KEY_0
i got message

Apr 22 11:06:21 DietPi lircd[3352]: lircd-0.10.1[3352]: Error: error processing command: SEND_ONCE TANK-64 KEY_0
Apr 22 11:06:21 DietPi lircd[3352]: lircd-0.10.1[3352]: Error: transmission failed
Apr 22 11:06:21 DietPi lircd[3352]: lircd-0.10.1[3352]: Info: removed client
Apr 22 11:06:21 DietPi lircd-0.10.1[3352]: Error: invalid send buffer
Apr 22 11:06:21 DietPi lircd-0.10.1[3352]: Error: this remote configuration cannot be used to 
transmit
Apr 22 11:06:21 DietPi lircd-0.10.1[3352]: Error: error processing command: SEND_ONCE TANK-64 
KEY_0
Apr 22 11:06:21 DietPi lircd-0.10.1[3352]: Error: transmission failed

[AlexanderShniperson]

and also try to patch LIRC with that instruction from Raspbian Buster section without luck
also try to run on a fresh DietPi install on RPI Zero and updated Kernel without luck
Linux DietPi 4.19.115+ #1305 Fri Apr 17 11:47:30 BST 2020 armv6l GNU/Linux

[AlexanderShniperson]

@MichaIng do you have any success story with LIRC?

[AlexanderShniperson]

i run lircd --nodaemon -Dtrace2 and see logs, looks like LIRC can't find needed device as it say

Apr 25 13:49:39 DietPi lircd[862]: lircd-0.10.1[862]: Debug: No device found: /sys/class/rc/rc1/lirc0
Apr 25 13:49:39 DietPi lircd[862]: lircd-0.10.1[862]: Debug: Cannot open protocol file: /sys/class/rc/rc
0/protocols for read
Apr 25 13:49:39 DietPi lircd[862]: lircd-0.10.1[862]: Info: Cannot configure the rc device for /dev/lirc
0
Apr 25 13:49:39 DietPi lircd[862]: lircd-0.10.1[862]: Trace: driver supports sending
Apr 25 13:49:39 DietPi lircd-0.10.1[862]: Trace: registering inet client
Apr 25 13:49:39 DietPi lircd-0.10.1[862]: Notice: accepted new client from 127.0
.0.1
Apr 25 13:49:39 DietPi lircd-0.10.1[862]: Debug: No device found: /sys/class/rc/
rc1/lirc0
Apr 25 13:49:39 DietPi lircd-0.10.1[862]: Debug: Cannot open protocol file: /sys
/class/rc/rc0/protocols for read
Apr 25 13:49:39 DietPi lircd-0.10.1[862]: Info: Cannot configure the rc device for /dev/lirc0
Apr 25 13:49:39 DietPi lircd-0.10.1[862]: Trace: driver supports sending

[AlexanderShniperson]

so looks like i got working config and placed setup at the repo
seems to be working and data sends but receiver decode signal wrong, that we can see at journalctl -fu lircd

[MichaIng]

@AlexanderShniperson
Great that it finally works and for shairing your solution.

@MichaIng do you have any success story with LIRC?

Sadly I personally never used LIRC/IR on the Raspberry Pi. I would have expected that enabling the related dtoverlay and installing the lirc package should basically do the job, sad that it isn't hat easy.

---

On RPi we have this "JustBoom IR remote" option in dietpi-config > Display Options, for MPD remote control. I never tested it or worked on it (was done by prior devs), but what we do is:

• Install lirc package
• Add dtoverlay=gpio-ir,gpio_pin=25 to config.txt
• At best check lircd.conf yourself: https://github.com/MichaIng/DietPi/blob/dev/dietpi/func/dietpi-set_hardware#L415

Even that it is a special use case, probably it helps. The other way round probably our remote control implementation is outdated or does not work OOTB for the same reason.

[AlexanderShniperson]

i've inspected output of ir-keytable

Found /sys/class/rc/rc0/ (/dev/input/event4) with:
    Name: gpio_ir_recv
    Driver: gpio_ir_recv, table: rc-rc6-mce
    LIRC device: /dev/lirc1
    Attached BPF protocols: Operation not supported
    Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon 
    Enabled kernel protocols: lirc rc-6 
    bus: 25, vendor/product: 0001:0001, version: 0x0100
    Repeat delay = 500 ms, repeat period = 125 ms

and see that by default is enabled lirc rc-6 protocols, i think should be used related protocol to send and receive data, because now is see output of journalctl -fu lircd

Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: expecting pulse: 9000
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: +p208
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: unget: 1
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace: failed on header
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace: decoding failed for all remotes
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: pending pulse: 0
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: pending space: 0
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace: trying "TEST" remote
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: pending pulse: 0
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: pending space: 0
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: <p208
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace1: space expected
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace: failed on sync
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace: decoding failed for all remotes
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: c18530
Apr 25 20:54:24 DietPi lircd-0.10.1[384]: Trace2: pending pulse: 0
Apr 25 20:54:26 DietPi lircd-0.10.1[384]: Trace2: pending space: 0
Apr 25 20:54:26 DietPi lircd-0.10.1[384]: Trace: trying "TEST" remote
Apr 25 20:54:26 DietPi lircd-0.10.1[384]: Trace2: pending pulse: 0
Apr 25 20:54:26 DietPi lircd-0.10.1[384]: Trace2: pending space: 0
Apr 25 20:54:26 DietPi lircd-0.10.1[384]: Trace2: <p18530
Apr 25 20:54:26 DietPi lircd-0.10.1[384]: Trace1: space expected
Apr 25 20:54:26 DietPi lircd-0.10.1[384]: Trace: failed on sync
Apr 25 20:54:26 DietPi lircd-0.10.1[384]: Trace: decoding failed for all remotes

[MichaIng]

@AlexanderShniperson

Attached BPF protocols: Operation not supported

That is btw expected on RPi. BPF is a new kernel packet filter (firewall) that has not been enabled on recent RPi kernels yet. They just enabled nftables not too long ago.

Enabled kernel protocols: lirc rc-6

Looks right to me, although I have no deeper knowledge about those protocols and especially how to configure the adapters to use a certain protocol.

LIRC device: /dev/lirc1

Interesting that it's lirc1 and not lirc0.

And another think I just found:

• You use driver = default: https://github.com/AlexanderShniperson/rpi-lirc/blob/master/lirc_options.conf#L11
• The default config uses driver = devinput.
• There is a related /etc/lirc/lircd.conf.d/ config for the devinput driver explicitely, which is loaded by the default lircd.conf. If "default" does not match "devinput", you might need to alter/disable the config. The config to me looks like for x86 systems btw. The readme contains the following info:

/etc/lirc/lircd.conf.d README
=============================

Files in this directory are as distributed included by the main
/etc/lirc/lircd.conf. Only files matching '*.conf' are included.

As distributed, here is a single file devinput.lircd.conf. This should
be used with the devinput driver which is enabled by default. When using
another driver, disable the devinput file e. g., by renaming it to
devinput.lircd.dist.

lircd normally (tries to) sort the remotes so the ones which decodes fastest
are used first. If you want to sort your configs manually, see the
Configuration Guide on using multiple remotes.

[AlexanderShniperson]

i start thinking that send and receive signal on the same Raspberry is impossible in case of usage Raspberry Zero that have 1 core, i will check with two devices, one send signal and second receive.
just checked devinput driver and see a lof of false positive signals sending from nowhere

[AlexanderShniperson]

Hooray, its works, connected to socket opened at RPi that receive IR data and got message, updated configs at my repo

[GlennFR]

Hi, I'm glad you got something working! Can you please resume your step-by-step installation so that I, and others, can follow? I can't even get lircd to run, it always fails.
Thanks, in advance!

[AlexanderShniperson]

@GlennFR hi, i summarized all my work in repo
just install lirc apt-get install lirc and then read steps at my readme file, also as would be needed install patched lirc, it's also there

[GlennFR]

Hi Alexander, thanks for your reply.  I'm having trouble because
  I'm using ArchLinux on my RPi - and the install of lirc doesn't
  seem to be complete.  I'm more used to debian type linux, so I'm
  struggling under Arch.  I'll re-read your post tomorrow with a
  fresher brain!


On 27/04/2020 15:49, Alexander
  Shniperson wrote:



  @GlennFR
    hi, i summarized all my work in repo
    just install lirc apt-get install lirc and then
    read steps at my readme file, also as would be needed install
    patched lirc, it's also there
  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub, or unsubscribe.
  [

{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/MichaIng/DietPi/issues/3481#issuecomment-619998425",
"url": "https://github.com/MichaIng/DietPi/issues/3481#issuecomment-619998425",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

[AlexanderShniperson]

if you need help i've recommend you to open issue at my Repo, because it's not related to this thread.
will try to help as i can.

[MichaIng]

@AlexanderShniperson
Many thanks for your research and repo. I read through the readme and probably it make sense to skip apt-get install lirc and instead install the patched packages in the first place? Once the patch has been merged upstream or into the Raspbian repo, it can then be reverted to apt-get install lirc.

I am pretty sure that our implementation suffers from the same issue, hence I'll implement your workaround with full credits to you. I'll reopen this issue and add it to v6.30 milestone. The "workaround" flag makes us keeping an eye on the underlying upstream/repo version. Actually, it might be already solved on Bullseye: https://metadata.ftp-master.debian.org/changelogs//main/l/lirc/lirc_0.10.1-6.1_changelog

• debian/patches/lirc-gpio-ir-0.10.patch:
  
  
  
  • fix for kernel 4.19 (Closes: #931078, 930485).
  
  

Related bug reports:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930485
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931078

The 0.10.1-6 packages from here could be tested: http://raspbian.raspberrypi.org/raspbian/pool/main/l/lirc/
If they work, those would be probably the better (since official) ones to use.

[AlexanderShniperson]

To skip step apt-get install lirc a lot of other packages should be installed too, i will do a clean install and copy needed dependencies and place them as an another step.

Will try to also test 0.10.1-6 version

[AlexanderShniperson]

ok did clean install and found needed related packages, after that i try to install 0.10.1-6-1 without luck

root@DietPi:~# sudo apt install ./liblirc0_0.10.1-6.1_armhf.deb ./liblirc-client0_0.10.1-6.1_armhf.deb ./lirc_0.10.1-6.1_armhf.deb
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'liblirc0' instead of './liblirc0_0.10.1-6.1_armhf.deb'
Note, selecting 'liblirc-client0' instead of './liblirc-client0_0.10.1-6.1_armhf.deb'
Note, selecting 'lirc' instead of './lirc_0.10.1-6.1_armhf.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 liblirc0 : Depends: libgcc-s1 (>= 3.5) but it is not installable
 lirc : Depends: libgcc-s1 (>= 3.5) but it is not installable
E: Unable to correct problems, you have held broken packages.

as you can see apt can't find related package libgcc-s1

[MichaIng]

@AlexanderShniperson
Ah yeah, that is only available on the Bullseye repo:

• https://packages.debian.org/bullseye/libgcc-s1
• And again depends on gcc-10-base: https://packages.debian.org/bullseye/gcc-10-base
• So those two need to be installed as well: http://raspbian.raspberrypi.org/raspbian/pool/main/g/gcc-10/

But indeed, pulling a bunch of dependencies from testing suite is not better then using the ones compiled against Buster explicitely, since other Bullseye-only dependencies might follow later on. So we need to check whether these fixes find their way into stable/Buster as well, probably requesting it.

[AlexanderShniperson]

maybe is there a way to get source of 0.10.1-6-1 version to build them at Raspberry with Buster ?

[MichaIng]

@AlexanderShniperson
They are available at the links above as well:

• Lib/binaries: http://raspbian.raspberrypi.org/raspbian/pool/main/l/lirc/lirc_0.10.1.orig.tar.gz
• Debian patches, package rules, services etc: http://raspbian.raspberrypi.org/raspbian/pool/main/l/lirc/lirc_0.10.1-6.1.debian.tar.xz
• To be build with the debhelper tools: https://manpages.debian.org/buster/debhelper

However I think the packages you have with patch included are fine already, the upstream source is still the same anyway.

[AlexanderShniperson]

oh, a lot of work needs to be done to compile 0.10.1-6-1 version, in case of existing patched and working 0.10.1-5.2 version this work demotivates me.
before i requested source i think there is already patched version that just need to be compiled

[MichaIng]

@AlexanderShniperson
I think the debhelper tools build with the patches automatically. However yeah probably not worth it to do the effort as long as we have working packages already. Probably I'll do that by times when the patches are not backported to Buster soon.

[MichaIng]

@AlexanderShniperson
To switch over here, did you try to resolve by going forward to current Linux 5.4 branch?

apt install rpi-update
rpi-update

And here is as well a solution going back to the "deprecated" kernel module: https://gist.github.com/prasanthj/c15a5298eb682bde34961c322c95378b
The discussion around this issue on RPi forum: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=235256

[AlexanderShniperson]

To switch over here, did you try to resolve by going forward to current Linux 5.4 branch?

No i don't but will try.

The code in my repository is the union of several articles and solutions, also in my repo i was linked last link as a base solution

[AlexanderShniperson]

@MichaIng experiment end without luck, success update to kernel 5.4 doesn't give positive effect with original lirc library and also with patched.
so i did a trick and installed dietpi-stretch and downgrade kernel to 4.14 by
1) rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b
2) installed lirc by default for stretch is coming lirc 0.9.4.c and setup them just write to /Dietpi/config.txt line dtoverlay=lirc-rpi,gpio_in_pin=17,gpio_out_pin=18
3) also used default driver and lirc0 as receiver/transmitter device at /etc/lirc/lirc_options.conf

driver          = default
device          = /dev/lirc0

so now all works as expected!

[MichaIng]

Doesn't work the "new" dtoverlay gpio-ir with kernel 4.14? Ah, better not mess with a running system 😄.

There seem to be other IR issues with RPi4, failing irrecord: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=235256&start=50#p1686574
Also some other solutions (installing, then removing lirc package again) don't look like something that will work in every case and sustainable. With my limited IR experience it all looks like one needs to to try&error to find a solution that works for the particular case with the particular RPi model, but sadly not just a single bug with a single patch that we could apply to recover generic IR for all RPi users 😢. I can only hope the devs come up with a broader rework to make dtverlays and userland packages work again as expected. Probably its already in making or done but not yet released to stable APT repositories (dtoverlays/kernel as well as userland tools).

[AlexanderShniperson]

gpio-ir is part of kernel starting from 4.19.x so at 4.14.x we should use lirc-rpi
yes, something was broken starting from kernel 4.19.x and someone should try to fix that, until that fixed we will have a problem

[MichaIng]

gpio-ir is part of kernel starting from 4.19.x so at 4.14.x we should use lirc-rpi

Ah okay makes sense somehow, although I'm confused now whether gpio-ir then was buggy right from the start, so this new dtoverlay is the issue and not so much kernel 4.19... From my end I'll wait for for the new 5.4 kernel release before investigating deeper, to not waste time for a solution which might then be obsolete.

[AlexanderShniperson]

@MichaIng
looks like after kernel downgrade i've lost access to my camera, because when i run raspistill i got error message failed to open vchiq instance and no device with that name exists at dev

do you have any idea why?

[AlexanderShniperson]

by googling i found similar problem where folks talk about wrong kernel mailboxing bcm2835_vchiq 2000b840.mailbox: Missing firmware node and the problem related to wrong DTB files when downgrade kernel, so i just take this commit and
1) replaced all files at /boot folder and removed /boot/bcm2708-rpi-zero-w.dtb
2) replaced /lib/modules
3) replaced /opt/vc folder

now camera and lirc works fine together at kernel 4.14.x

[MichaIng]

Meanwhile lirc v0.10.1-6.2 has been merged into Buster, so probably the issue is fixed with current kernel and APT packages: https://packages.debian.org/buster/lirc

[MichaIng]

I mark this as closed. Feel free to reopen if issue persists.