defective ir-keytable udev rule → custom keytable does not get loaded

Bug #1906986 reported by Tore Anderson
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
v4l-utils (Ubuntu)
Expired
High
Unassigned

Bug Description

ir-keytable v1.18.0-2build1 ships /lib/udev/rules.d/60-ir-keytable.rules containing the following rule:

ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name"

After upgrading to Focal, this does not get triggered at boot, nor if I (re)insert my receiver when the system is running. Therefore, the custom keytable does not get loaded.

This is the udev events that occur when I insert the receiver:

$ sudo udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1195.829011] add /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
KERNEL[1195.834989] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0 (usb)
KERNEL[1195.874055] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
KERNEL[1195.875019] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
KERNEL[1195.875183] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
KERNEL[1196.134164] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
KERNEL[1196.134448] bind /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0 (usb)
KERNEL[1196.134704] bind /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
UDEV [1196.158923] add /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
UDEV [1196.174559] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0 (usb)
UDEV [1196.194750] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
UDEV [1196.196268] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
UDEV [1196.197180] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
UDEV [1196.224577] add /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
UDEV [1196.231346] bind /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0 (usb)
UDEV [1196.244978] bind /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)

Note how there's no «(rc)» displayed on any of the lines, which means that the «SUBSYSTEM=="rc"» condition from the udev rule filters all of the above events.

I found a rule that works at https://<email address hidden>/msg117165.html:

ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="rc", KERNEL=="event*", ENV{.rc_sysdev}="$id", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $env{.rc_sysdev}"

Creating a custom /etc/udev/rules.d/60-ir-keytable.rules file containing this rule solves the problem; now my custom keymap is loaded at boot, as it did before (when I was running Bionic).

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ir-keytable 1.18.0-2build1 [modified: usr/bin/ir-keytable]
ProcVersionSignature: Ubuntu 5.4.0-56.62-generic 5.4.73
Uname: Linux 5.4.0-56-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.13
Architecture: amd64
CasperMD5CheckResult: skip
Date: Sun Dec 6 18:05:06 2020
SourcePackage: v4l-utils
UpgradeStatus: Upgraded to focal on 2020-12-06 (0 days ago)

Revision history for this message
Tore Anderson (toreanderson) wrote :
Revision history for this message
Gregor Jasny (gjasny) wrote :

Hi,

the issue is the same as in LP #1903966. The following commit should fix it also for the 1.18 version:

  https://salsa.debian.org/debian/libv4l/-/commit/e12bd27aa844663601d81c99ecbdff33c9b5e9f3

Until the version in focal is fixed, you could use the v4l-utils-stable PPA:

  https://code.launchpad.net/~libv4l/+archive/ubuntu/stable

The (pending) Build recipe is here:
https://code.launchpad.net/~libv4l/+recipe/v4l-utils-stable-1.20

Thanks,
Gregor

Changed in v4l-utils (Ubuntu):
status: New → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, that's what got fixed in https://bugs.launchpad.net/ubuntu/+source/v4l-utils/1.20.0-2 right ?

Changed in v4l-utils (Ubuntu):
importance: Undecided → High
status: Confirmed → Incomplete
Revision history for this message
Tore Anderson (toreanderson) wrote :

Probably. My (fully updated) 20.04.1 LTS box is still at version 1.18.0-2build1, though.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for v4l-utils (Ubuntu) because there has been no activity for 60 days.]

Changed in v4l-utils (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.