Talk:LIRC

From ArchWiki
Jump to navigation Jump to search

group ownership and write permission on lock

@duaner - Re: https://wiki.archlinux.org/index.php?title=LIRC&type=revision&diff=577159&oldid=577125

The extra line you proposed isn't needed at least on my system. Did you find otherwise on your system?

e /run/lock 0775    - lock -

—This unsigned comment is by Graysky (talk) 20:15, 9 July 2019 (UTC). Please sign your posts with ~~~~!

I just installed from the 1 July livedvd, and my /run/lock is set root:root 755 by default. The lock group isn't used anywhere on the system, oddly enough. The FTDI USB model, using the uirt2_raw driver still has to create lock files, so I did have to change the group ownership/permissions, but that may be a special case. That dongle is also not picked up by the 60-lirc.rules udev rule -- I had to specify vendor and product. —This unsigned comment is by Duaner (talk) 00:33, 10 July 2019 (UTC). Please sign your posts with ~~~~!
yes, I too get root:root for mine, yet my streamzap (USB dongle + IR) works as I describe. I think we should add a comment about the potential quirkiness but not make the page too hardware specific. Thoughts? Graysky (talk) 20:48, 10 July 2019 (UTC)
In that case you might not want to add the lock group to lirc, since apparently nothing on a new system has the lock group. —This unsigned comment is by Duaner (talk) 23:56, 10 July 2019 (UTC). Please sign your posts with ~~~~!

lirc user groups

Hi guys, my first time commenting here... I have a homebrew USB dongle that uses /dev/ttyUSB0. In this case the lirc user needs to be also a memeber of uucp, not only lock.

Nyan GO (talk) 19:14, 5 May 2020 (UTC)

LIRC with GPIO on a Raspberry Pi

There are quite some differences when setting this up on a Raspberry Pi and information about them is scattered all over the internet. It took me several hours to find all pieces of information and to get it to work. This might be worth adding to this article. Please tell me if you know an easier or otherwise better way.


So apparently, Raspberry Pis stopped using the lirc-rpi overlay last year and use gpio-ir and gpio-tr-ix instead. If you're having trouble because /dev/lirc0 won't show up, open up /boot/config.txt. If you added anything else to this file during other LIRC tutorials, discard it. Then add the lines dtoverlay=gpio-ir,gpio_pin=2 for IR input and/or dtoverlay=gpio-ir-tx,gpio_pin=3 for IR output. Adjust the GPIO numbers according to your setup. Remember to use the GPIO numbers, not the physical pin numbers! I also read about someone having issues using both gpio-ir and gpio-tr-ix at the same time, but I haven't verified that. Also set driver = default in your /etc/lirc/lirc_options.conf. Reboot your Pi, start lircd and check if /dev/lirc0 is now there.

However, depending on what you are planning to do, we are not done yet. gpio-ir produces a slightly different output which irrecord and possibly other tools can't handle. Trying to use irrecord produces config files that have 0x0 configured for all keys, rendering them useless.

Fortunately, someone created a patch for lirc to get it to work. There is a Tutorial on the Raspberry Pi forums for applying it on Raspbian, but things are a little different on Arch Linux. Here's how I did it:

First, acquire the build files for lirc-git:

git clone https://aur.archlinux.org/lirc-git.git

Enter the directory and download the patch:

cd lirc-git
wget https://raw.githubusercontent.com/neuralassembly/raspi/master/lirc-gpio-ir-0.10.patch

Now you need to edit the PKGBUILD. The PKGBUILD claims that lirc only supports x86_64, but this is not true. I have a Raspberry Pi 4B using the armv7h architecture and it builds just fine. It probably works on other Raspberry Pi models as well. Thus, add your model's architecture to the arch variable (armv7h in my case):

...

arch=('armv7h')

...

Add the patch to the prepare function:

...

prepare() {
  cd "$srcdir/$_pkgname"
  patch -Np1 -i ../../lirc-gpio-ir-0.10.patch
  patch -Np1 -i ../unfuck_build.patch
}

...

Then try to build the package using makepkg. If it works, you're set! However, you might get this error:

==> Starting prepare()...
patching file lib/config_file.c
patching file lib/ir_remote.h
patching file lib/irrecord.c
patching file lib/lirc/ir_remote.h
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file lib/lirc/ir_remote.h.rej
patching file tools/mode2.cpp
==> ERROR: A failure occurred in prepare().
    Aborting...

The error is itself not a problem as far as I know, but it causes makepkg to exit without building anything. Open up the PKGBUILD again and add || true to the patch line. This will discard the non-zero exit code returned by patch.

...

prepare() {
  cd "$srcdir/$_pkgname"
  patch -Np1 -i ../../lirc-gpio-ir-0.10.patch || true
  patch -Np1 -i ../unfuck_build.patch
}

...

Now run makepkg again.

That's it! You should now have a patched package in your directory. Install it:

sudo pacman -U lirc-git-*.pkg.tar.xz

If extra/lirc is already installed, you will be asked to replace it. This might also overwrite your existing configs in /etc/lirc/, so you might want to make a backup first.

All you have left to do is to (re)start lircd and irrecord should now work as expected! Keep in mind that you have to apply the patch again if you update LIRC and the problem hasn't been fixed in the new version yet.




Rapti (talk) 18:52, 13 May 2020 (UTC)