Ubuntu kernels 5.4.0-51 and 5.4.0-52 break ir-keytable loading

[pdaniel]

I run mythtv on Ubuntu 20.04 and I used a custom remote control keymap in /etc/rc_keymaps to correctly map buttons on my IR remote. The above kernel seems to break custom keymap loading for my remote (certain buttons no longer work in mythtv). Reverting to kernel 5.4.0-48 corrects the problem.

Description: Ubuntu 20.04.1 LTS
Release: 20.04

linux-image-5.4.0-52-generic:
  Installed: 5.4.0-52.57
  Candidate: 5.4.0-52.57
  Version table:
 *** 5.4.0-52.57 500
        500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
        100 /var/lib/dpkg/status

belongs to the linux source package

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-52-generic 5.4.0-52.57
ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
Uname: Linux 5.4.0-48-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.10
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: pdaniel 1552 F.... pulseaudio
 /dev/snd/controlC0: pdaniel 1552 F.... pulseaudio
CasperMD5CheckResult: skip
Date: Thu Oct 22 16:16:58 2020
InstallationDate: Installed on 2017-04-17 (1284 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
MachineType: MSI MS-7792
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-48-generic root=UUID=38b7dfb0-9848-4919-890b-fdc027e936f1 ro radeon.dpm=0 quiet splash vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-48-generic N/A
 linux-backports-modules-5.4.0-48-generic N/A
 linux-firmware 1.187.3
SourcePackage: linux
UpgradeStatus: Upgraded to focal on 2020-05-11 (164 days ago)
dmi.bios.date: 02/12/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V2.4
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: FM2-A75IA-E53 (MS-7792)
dmi.board.vendor: MSI
dmi.board.version: 1.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV2.4:bd02/12/2015:svnMSI:pnMS-7792:pvr1.0:rvnMSI:rnFM2-A75IA-E53(MS-7792):rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: MS-7792
dmi.product.sku: To be filled by O.E.M.
dmi.product.version: 1.0
dmi.sys.vendor: MSI

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Wes Newell (wesnewell)]

Just upgraded to -58 kernel and it broke my remote too. Going back to -42 kernel fixed it.

[pdaniel (pdaniel9)]

Workaround that seems to work:

Running ir-keytable -t as my user gave "permission denied" on /dev/input/event16 and /dev/lirc0. After adding my user to the "input" and "video" groups that own those devices, the remote works correctly. However, I also have to manually load the custom keymap before I login as my user to make it work (sudo ir-keytable -w /etc/rc_keymaps/<custom keymap>.toml). Not sure why that no longer happens automatically during boot or why a kernel change coincides with all these issues. Currently running kernel 5.4.0-58-generic with this workaround.

[Chris (oldright)]

I implemented your workaround and it addresses the issue for me as well
with kernel 5.4.0-58-generic.

Thanks!

On 12/12/20 10:08 AM, pdaniel wrote:
> Workaround that seems to work:
>
> Running ir-keytable -t as my user gave "permission denied" on
> /dev/input/event16 and /dev/lirc0. After adding my user to the "input"
> and "video" groups that own those devices, the remote works correctly.
> However, I also have to manually load the custom keymap before I login
> as my user to make it work (sudo ir-keytable -w /etc/rc_keymaps/<custom
> keymap>.toml). Not sure why that no longer happens automatically during
> boot or why a kernel change coincides with all these issues. Currently
> running kernel 5.4.0-58-generic with this workaround.
>

[Wes Newell (wesnewell)]

Interesting, but doesn't seem to be a proper fix. Been running ir-keytable for years and was never able to use ir-krytable -t as a regular user. had to redo keymap file going from xubuntu 18.04lts to 20.04lts. Having to load after boot is not a viable option as this is a frontend my wife uses that boots staight to mythtv frontend and if the remote doesn't work on boot, to her it's broke.

[Kai-Heng Feng (kaihengfeng)]

Please boot under kernels with the issue, and attach dmesg here?

[Wes Newell (wesnewell)]

AFAICT, it affects all later kernels starting after 5.4.0-48 somewhere. that includes 5.9 and 5.10 which i just installed a couple of days ago. If you think it would help I can reboot to whichever kernel you want and post dmesg output.Wondering if this should be posted as a kernel bug too.

[Kai-Heng Feng (kaihengfeng)]

Well, that means upstream kernel is also affected. Please do a kernel bisection.

[Kai-Heng Feng (kaihengfeng)]

First, find the last -rc kernel works and the first -rc kernel doesn’t work from http://kernel.ubuntu.com/~kernel-ppa/mainline/

Then,
$ sudo apt build-dep linux
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ git bisect start
$ git bisect good $(the working version you found)
$ git bisect bad $(the non-working version found)
$ make localmodconfig
$ make -j`nproc` deb-pkg
Install the newly built kernel, then reboot with it.
If it still have the same issue,
$ git bisect bad
Otherwise,
$ git bisect good
Repeat to "make -j`nproc` deb-pkg" until you find the offending commit.

[Wes Newell (wesnewell)]

Last ubuntu kernel that worked was 5.4.0-48. First that doesn't is 5.4.0-51. And there isn't a 5.4.0 dir list here.
https://kernel.ubuntu.com/~kernel-ppa/mainline/
It works in some later kernels from mainline but quit working sometime after 5.4.53, and doesn't work in 5.9 or 5.10.

[Wes Newell (wesnewell)]

5.8.7-050807-generic #202009051031 SMP Sat Sep 5 10:34:16 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux WORKS.

kernel 5.8.8 does not.
Looks like any kernel built after Sep 5 2020 will be bad.

[Kai-Heng Feng (kaihengfeng)]

Thanks. That boils down to two commits:
9af0c46a761293ef04c57f001cc2641d4ec1add3 media: rc: uevent sysfs file races with rc_unregister_device()
bff924ee40ae3857e7373536fdda203378795e3c media: rc: do not access device via sysfs after rc_unregister_device()

Can you please try which one breaks it?

[Wes Newell (wesnewell)]

I have no idea how to do that.

[Wes Newell (wesnewell)]

I've emailed the person that commited them. With luck.....

[Sean Young (sean-young)]

Hello, the author of those commits here. It's not clear to me how those commits broke things. Either something else changed, or there is something subtle going on.

The following bits of information would be very useful.

1. Is the issue intermittent or consistent, i.e. does booting with a new kernel always cause some keys to fail and an older kernel all the keys always work fine?
2. What keymap are you loading?
3. Are you using a streamzap device?
3. How are you loading the keymap; i.e. how is ir-keytable run, and with what command line.
4. Once the system is booted, it would be useful to know what the output of the evtest command line tool is (after you select the device)

Ideally it would also be useful to know what happens if you revert those commits.

Thank you

[Wes Newell (wesnewell)]

On 12/19/20 5:09 PM, Sean Young wrote:
> Hello, the author of those commits here. It's not clear to me how those
> commits broke things. Either something else changed, or there is
> something subtle going on.
>
> The following bits of information would be very useful.
>
> 1. Is the issue intermittent or consistent, i.e. does booting with a new kernel always cause some keys to fail and an older kernel all the keys always work fine?
> 2. What keymap are you loading?
> 3. Are you using a streamzap device?
> 3. How are you loading the keymap; i.e. how is ir-keytable run, and with what command line.
> 4. Once the system is booted, it would be useful to know what the output of the evtest command line tool is (after you select the device)
>
> Ideally it would also be useful to know what happens if you revert those
> commits.
>
> Thank you

1. It's consistent. older kernels always work. never ones never work.

2. I'm using a custom keymap. I'll attach my keymap file and config
file. Don't know what the original reporter uses.

3. No. I'm using a JP1 remote with my own custom nec protocol.

4. You lost me on this one. Don't know what evtest you mean. Nor do I
select the device. It just works after boot.

I'm not a kernel guy and don't know how to revert the commits. Here's my
ir-keytable output on kernel 5.8.7.

wes@mythfe0:~$ ir-keytable
Found /sys/class/rc/rc3/ with:
     Name: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)
     Driver: mceusb
     Default keymap: rc-rc6-mce
     Input device: /dev/input/event19
     LIRC device: /dev/lirc3
     Attached BPF protocols: Permission denied
     Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo
mce_kbd rc-6 sharp xmp imon rc-mm
     Enabled kernel protocols: lirc nec rc-6

Newer kernels ir-keytable output does not enable the nec protocol. I
have removed them from my system. Currently running 5.8.7. It was the
last one that worked. All after that don't work. The last ubuntu kernel
that worked was 5.4.0-48. None after that work either.

I have no clue if those commits have anything to do with this. It was someone else's comment in the bug report.
If I'm barking up the wrong tree I'm sorry to have bothered you.

--
https://github.com/wesnewell/Functionality
http://wesnewell.ddns.net

[Sean Young (sean-young)]

Thank you for that.

With evtest I mean the evtest tool from the evtest package: https://packages.ubuntu.com/focal/evtest

when you run ir-keytable there is an line which says "Input device: /dev/input/event..". Use that as an argument to evtest:

evtest /dev/input/event19

There will be some output about the device. Please copy and paste that.

Thanks. I'm sure we'll get to the bottom of this.

[Sean Young (sean-young)]

Actually you said "on newer systems it does not enable the nec protocol". That is odd.

what is the output of ir-keytable on newer (broken) systems?
also what is the kernel config on broken systems (not sure how to see that on ubuntu)

[Wes Newell (wesnewell)]

This is with working kernel 5.8.7.
root@mythfe0:/home/wes# ir-keytable
Found /sys/class/rc/rc3/ with:
 Name: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)
 Driver: mceusb
 Default keymap: rc-rc6-mce
 Input device: /dev/input/event19
 LIRC device: /dev/lirc3
 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 rc-mm
 Enabled kernel protocols: lirc nec rc-6
 bus: 3, vendor/product: 0471:0815, version: 0x0000
 Repeat delay = 500 ms, repeat period = 125 ms

root@mythfe0:/home/wes# evtest /dev/input/event19
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x471 product 0x815 version 0x0
Input device name: "Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 1 (KEY_ESC)
    Event code 2 (KEY_1)
    Event code 3 (KEY_2)
    Event code 4 (KEY_3)
    Event code 5 (KEY_4)
    Event code 6 (KEY_5)
    Event code 7 (KEY_6)
    Event code 8 (KEY_7)
    Event code 9 (KEY_8)
    Event code 10 (KEY_9)
    Event code 11 (KEY_0)
    Event code 16 (KEY_Q)
    Event code 17 (KEY_W)
    Event code 18 (KEY_E)
    Event code 19 (KEY_R)
    Event code 20 (KEY_T)
    Event code 21 (KEY_Y)
    Event code 22 (KEY_U)
    Event code 23 (KEY_I)
    Event code 24 (KEY_O)
    Event code 25 (KEY_P)
    Event code 28 (KEY_ENTER)
    Event code 30 (KEY_A)
    Event code 31 (KEY_S)
    Event code 32 (KEY_D)
    Event code 33 (KEY_F)
    Event code 34 (KEY_G)
    Event code 35 (KEY_H)
    Event code 36 (KEY_J)
    Event code 37 (KEY_K)
    Event code 38 (KEY_L)
    Event code 39 (KEY_SEMICOLON)
    Event code 44 (KEY_Z)
    Event code 45 (KEY_X)
    Event code 46 (KEY_C)
    Event code 47 (KEY_V)
    Event code 48 (KEY_B)
    Event code 49 (KEY_N)
    Event code 50 (KEY_M)
    Event code 51 (KEY_COMMA)
    Event code 52 (KEY_DOT)
    Event code 53 (KEY_SLASH)
    Event code 67 (KEY_F9)
    Event code 68 (KEY_F10)
    Event code 87 (KEY_F11)
    Event code 88 (KEY_F12)
    Event code 102 (KEY_HOME)
    Event code 103 (KEY_UP)
    Event code 104 (KEY_PAGEUP)
    Event code 105 (KEY_LEFT)
    Event code 106 (KEY_RIGHT)
    Event code 107 (KEY_END)
    Event code 108 (KEY_DOWN)
    Event code 109 (KEY_PAGEDOWN)
    Event code 111 (KEY_DELETE)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 116 (KEY_POWER)
    Event code 119 (KEY_PAUSE)
    Event code 128 (KEY_STOP)
    Event code 142 (KEY_SLEEP)
    Event code 161 (KEY_EJECTCD)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 167 (KEY_RECORD)
    Event code 168 (KEY_REWIND)
    Event code 174 (KEY_EXIT)
    Event code 207 (KEY_PLAY)
    Event code 208 (KEY_FASTFORWARD)
    Event code 210 (KEY_PRINT)
    Event code 212 (KEY_CAMERA)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 226 (KEY_MEDIA)
    Event code 352 (KEY_OK)
    Event code 356 (KEY_POWER2)
    Event code 358 (KEY_INFO)
    Event code 365 (KEY_EPG)
    Event code 366 (KEY_PVR)
    Event code 368 (KEY_LANGUAGE)
    Event code 369 (KEY_TITLE)
    Even...

[Wes Newell (wesnewell)]

This is with kernel 5.8.8 which doesn't work.

Found /sys/class/rc/rc0/ with:
 Name: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)
 Driver: mceusb
 Default keymap: rc-rc6-mce
 Input device: /dev/input/event7
 LIRC device: /dev/lirc0
 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 rc-mm
 Enabled kernel protocols: lirc rc-6
 bus: 3, vendor/product: 0471:0815, version: 0x0000
 Repeat delay = 500 ms, repeat period = 125 ms
root@mythfe0:/home/wes# evtest /dev/input/event7
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x471 product 0x815 version 0x0
Input device name: "Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 28 (KEY_ENTER)
    Event code 103 (KEY_UP)
    Event code 105 (KEY_LEFT)
    Event code 106 (KEY_RIGHT)
    Event code 108 (KEY_DOWN)
    Event code 111 (KEY_DELETE)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 119 (KEY_PAUSE)
    Event code 128 (KEY_STOP)
    Event code 142 (KEY_SLEEP)
    Event code 161 (KEY_EJECTCD)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 167 (KEY_RECORD)
    Event code 168 (KEY_REWIND)
    Event code 174 (KEY_EXIT)
    Event code 207 (KEY_PLAY)
    Event code 208 (KEY_FASTFORWARD)
    Event code 210 (KEY_PRINT)
    Event code 212 (KEY_CAMERA)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 226 (KEY_MEDIA)
    Event code 352 (KEY_OK)
    Event code 356 (KEY_POWER2)
    Event code 358 (KEY_INFO)
    Event code 365 (KEY_EPG)
    Event code 366 (KEY_PVR)
    Event code 368 (KEY_LANGUAGE)
    Event code 369 (KEY_TITLE)
    Event code 370 (KEY_SUBTITLE)
    Event code 372 (KEY_ZOOM)
    Event code 373 (KEY_MODE)
    Event code 377 (KEY_TV)
    Event code 385 (KEY_RADIO)
    Event code 386 (KEY_TUNER)
    Event code 387 (KEY_PLAYER)
    Event code 389 (KEY_DVD)
    Event code 392 (KEY_AUDIO)
    Event code 393 (KEY_VIDEO)
    Event code 398 (KEY_RED)
    Event code 399 (KEY_GREEN)
    Event code 400 (KEY_YELLOW)
    Event code 401 (KEY_BLUE)
    Event code 402 (KEY_CHANNELUP)
    Event code 403 (KEY_CHANNELDOWN)
    Event code 407 (KEY_NEXT)
    Event code 412 (KEY_PREVIOUS)
    Event code 425 (KEY_PRESENTATION)
    Event code 430 (KEY_MESSENGER)
    Event code 512 (KEY_NUMERIC_0)
    Event code 513 (KEY_NUMERIC_1)
    Event code 514 (KEY_NUMERIC_2)
    Event code 515 (KEY_NUMERIC_3)
    Event code 516 (KEY_NUMERIC_4)
    Event code 517 (KEY_NUMERIC_5)
    Event code 518 (KEY_NUMERIC_6)
    Event code 519 (KEY_NUMERIC_7)
    Event code 520 (KEY_NUMERIC_8)
    Event code 521 (KEY_NUMERIC_9)
    Event code 522 (KEY_NUMERIC_STAR)
    Event code 523 (KEY_NUMERIC_POUND)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
 Found /sys/class/rc/rc0/ with:
 Name: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)
 Driver: mceusb
 Default keymap: rc-rc6-mce
 Input device: /dev/input/event7
 LIRC device: /dev/lirc0
 Attached BPF protocols: Operation not s...

[Wes Newell (wesnewell)]

Ccofigs for both kernels attached.

[Wes Newell (wesnewell)]

Oops. here's the other.

[Sean Young (sean-young)]

Thanks for that. It looks like on 5.8.8 it has not loaded the rc keymap at all. It looks like a default mce keymap with the default rc-6 protocol enabled.

So for some reason /etc/rc_map.cfg did not get processed at all. That's super odd. Let's try and see what udevd does when you plug in the device. On 5.8.8 As root, run:

udevadm control -l debug
journalctl -u systemd-udevd.service -f

Now plug in the device. There _should_ be some lines about ir-keytable.

[Wes Newell (wesnewell)]

here goes.

root@mythfe0:/home/wes# journalctl -u systemd-udevd.service -f
-- Logs begin at Thu 2020-09-24 22:03:46 CDT. --
Dec 21 06:58:08 mythfe0 systemd-udevd[1702]: value '[dmi/id]sys_vendor' is 'To Be Filled By O.E.M.'
Dec 21 06:58:08 mythfe0 systemd-udevd[1702]: 1-8: Device (SEQNUM=4105, ACTION=remove) processed
Dec 21 06:58:08 mythfe0 systemd-udevd[1702]: 1-8: sd-device-monitor: Passed 355 byte to netlink monitor
Dec 21 06:58:12 mythfe0 systemd-udevd[310]: Cleanup idle workers
Dec 21 06:58:12 mythfe0 systemd-udevd[1702]: Unload module index
Dec 21 06:58:12 mythfe0 systemd-udevd[1701]: Unload module index
Dec 21 06:58:12 mythfe0 systemd-udevd[1701]: Unloaded link configuration context.
Dec 21 06:58:12 mythfe0 systemd-udevd[1702]: Unloaded link configuration context.
Dec 21 06:58:12 mythfe0 systemd-udevd[310]: Worker [1701] exited
Dec 21 06:58:12 mythfe0 systemd-udevd[310]: Worker [1702] exited
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: 1-8: Device (SEQNUM=4106, ACTION=add) is queued
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: Validate module index
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: Check if link configuration needs reloading.
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: Successfully forked off 'n/a' as PID 1710.
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: 1-8: Worker [1710] is forked for processing SEQNUM=4106.
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: 1-8: Processing device (SEQNUM=4106, ACTION=add)
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: value '[dmi/id]sys_vendor' is 'To Be Filled By O.E.M.'
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: value '[dmi/id]sys_vendor' is 'To Be Filled By O.E.M.'
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: 1-8: /usr/lib/udev/rules.d/50-udev-default.rules:13 Importing properties from results of builtin command 'usb_id'
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: 1-8:1.0: Device (SEQNUM=4107, ACTION=add) is queued
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: lirc0: Device (SEQNUM=4108, ACTION=add) is queued
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: input20: Device (SEQNUM=4109, ACTION=add) is queued
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: event8: Device (SEQNUM=4110, ACTION=add) is queued
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: wakeup39: Device (SEQNUM=4111, ACTION=add) is queued
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: 1-8:1.0: Device (SEQNUM=4112, ACTION=bind) is queued
Dec 21 06:58:29 mythfe0 systemd-udevd[310]: 1-8: Device (SEQNUM=4113, ACTION=bind) is queued
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: 1-8: /usr/lib/udev/rules.d/50-udev-default.rules:13 Importing properties from results of builtin command 'hwdb --subsystem=usb'
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: 1-8: /usr/lib/udev/rules.d/50-udev-default.rules:48 MODE 0664
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: 1-8: /usr/lib/udev/rules.d/60-drm.rules:3 Importing properties from results of builtin command 'path_id'
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: 1-8: /usr/lib/udev/rules.d/69-libmtp.rules:2685 Running PROGRAM 'mtp-probe /sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-8 1 5'
Dec 21 06:58:29 mythfe0 systemd-udevd[1710]: 1-8: Starting 'mtp-probe /sys/devices/pci0000:00/0000:00:01.2/0000:01:00...

[Wes Newell (wesnewell)]

As you can see there's no reference to ir-keytable running in that kernel. Ran the same on good kernel 5.8.7 and here's a snippet from the output of it.

Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: /usr/lib/udev/rules.d/60-ir-keytable.rules:5 RUN '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name'
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: Running command "/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc3"
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: Starting '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc3'
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: Successfully forked off '(spawn)' as PID 1477.
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: wakeup39: Processing device (SEQNUM=4086, ACTION=add)
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: value '[dmi/id]sys_vendor' is 'To Be Filled By O.E.M.'
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: value '[dmi/id]sys_vendor' is 'To Be Filled By O.E.M.'
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: wakeup39: Device (SEQNUM=4086, ACTION=add) processed
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: wakeup39: sd-device-monitor: Passed 194 byte to netlink monitor
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc3'(err) '/etc/rc_keymaps/rc6_mce.toml: error: cannot open: No such file or directory'
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc3'(err) 'Old keytable cleared'
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc3'(err) 'Wrote 163 keycode(s) to driver'
Dec 21 14:04:20 mythfe0 systemd-udevd[308]: ir_nec_decoder: Device (SEQNUM=4089, ACTION=add) is queued
Dec 21 14:04:20 mythfe0 systemd-udevd[308]: ir_nec_decoder: sd-device-monitor: Passed 138 byte to netlink monitor
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: ir_nec_decoder: Processing device (SEQNUM=4089, ACTION=add)
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: value '[dmi/id]sys_vendor' is 'To Be FDec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: /usr/lib/udev/rules.d/60-ir-keytable.rules:5 RUN '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name'
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: Running command "/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc3"
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: Starting '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc3'
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: Successfully forked off '(spawn)' as PID 1477.
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: wakeup39: Processing device (SEQNUM=4086, ACTION=add)
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: value '[dmi/id]sys_vendor' is 'To Be Filled By O.E.M.'
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: value '[dmi/id]sys_vendor' is 'To Be Filled By O.E.M.'
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: wakeup39: Device (SEQNUM=4086, ACTION=add) processed
Dec 21 14:04:20 mythfe0 systemd-udevd[1464]: wakeup39: sd-device-monitor: Passed 194 byte to netlink monitor
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc3'(err) '/etc/rc_keymaps/rc6_mce.toml: error: cannot open: No such file or directory'
Dec 21 14:04:20 mythfe0 systemd-udevd[1458]: rc3: '/usr/bin/i...

[Sean Young (sean-young)]

Thanks for that.

It seems very possible that this issue is solved by this patch: https://patchwork.linuxtv<email address hidden>/

Would you be able to test this patch please? There are instructions for compiling the kernel here.

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

That would be super-helpful

[Wes Newell (wesnewell)]

Well, that didn't work.

wes@mythfe0:~$ sudo apt-get build-dep linux linux-image-$(uname -r)
[sudo] password for wes:
Reading package lists... Done
E: You must put some 'deb-src' URIs in your sources.list
wes@mythfe0:~$ uname -r
5.10.2-051002-generic
wes@mythfe0:~$

Last time I compiled a kernel was ~20 years ago. Can I assume I need to be running a current ubuntu dist. kernel to do this following those instructions?
Might it not be easier to just dl current sources and manually edit rc-main.c and then recompile. i might be able to get that done. i know how to dl the sources.

or maybe have someone more familiar with the process to do it.

[Wes Newell (wesnewell)]

After enabling sources and reverting to ubuntu kernel 5.4.0-58 installed first part. Will continue tomorrow or later tonight.

[Kai-Heng Feng (kaihengfeng)]

Test kernel with the patch:
https://people.canonical.com/~khfeng/lp1901089/

[Wes Newell (wesnewell)]

Yes! That fixed it for me. Glad someone here could compile it. I was lost.
What happens now to all the other kernels.

[Sean Young (sean-young)]

Thank you @wesnewell and @kaihengfeng for testing this!

Now that we know the patch works, I'll send the patch upstream and it'll be included in the stable kernels as well.

[Wes Newell (wesnewell)]

Just curious how long that takes. 5.10.3 was just released today and doesn't look like it made it into it going by the changes.

[Sean Young (sean-young)]

I've submitted a PR
https://<email address hidden>/T/#t
This has to be merged by Mauro (linux-media). Then Linus has to merge it. Finally, it needs to be merged into the stable tree. So it may be some time.

[Wes Newell (wesnewell)]

After a system upgrade last night, the patched version 5.4.0-59 that works was replaced by an older version of 5.4.0-59 dated Dec 10. So anyone that installed the patched version will likely find their remote not working again if they do a system upgrade.

[Wes Newell (wesnewell)]

Patch was added into kernel builds on 01-31-21. Working later kernels.
Linux mythfe0 5.10.13-051013-generic #202102032337 SMP Thu Feb 4 00:17:21 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[Wes Newell (wesnewell)]

last kernel upgrade to 5.4.0-66 is still broken.

[Wes Newell (wesnewell)]

Kernel 5.4.0-67 is still broken.
Can anyone explain this to me.
A patch that fixed it was done in Dec. 2020. And it was implemented in ppa kernels compiled after 01/28/2021.
So why is it that this has not made it into any of the distribution kernels yet. Kernels 5.10 has shown up in the repos, yet it is still based on the broken kernel versions.
What the heck is going on with this.

[Chris (oldright)]

I appreciate that you keep trying to verify that the fix is in place. I guess I'll continue to use the workaround until I see that you have confirmed the fix.

[Wes Newell (wesnewell)]

Well, I run newer kernels from the ppa as my main kernel. Currently running 5.11.3, so it's not a problem for me. As long as whomever does the distribution kernels keep using old base kernels, the problem will never be fixed. If you want to run a distribution kernel, then you should go back to 5.4.0-48. It works.

[Wes Newell (wesnewell)]

I'm happy to report that the following dist kernel has fixed the problem.
wes@mythfe0:~$ uname -a
Linux mythfe0 5.10.0-1017-oem #18-Ubuntu SMP Fri Mar 5 18:33:48 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
It's in the repos.
And it also supports my nvme drive status which was why I was running later ppa kernels to begin with.
Now if they could only get the 5.4 kernels fixed it would be complete.

[Wes Newell (wesnewell)]

While 5.10.0-1017 did fix the ir-keytable problem it introduced other problems which I couldn't live with. After deleting my 5.11.3 kernel I have since reinstalled it and am running it.Maybe I'll try to reinstall the 5.10.0-1017 kernel later and see if I just got a bad install.

[Wes Newell (wesnewell)]

Still screwed up after reinstall. At this point I'd just recommend installing the 5.11.3 kernel from the ppa and be done with it.

[Wes Newell (wesnewell)]

Kernel 5.4.0-71 has finally fixed the problem. Having just installed it, I have not run extensive test on it, but it appears to be stable.

[Marti Martz (martiimartz)]

Haven't fully tracked this issue in all kernels updated via apt but:

Kernel 5.4.0-51
Kernel 5.4.0-52
Kernel 5.4.0-65
Kernel 5.8.0-44
Kernel 5.8.0-49
Kernel 5.8.0-53

... all still have this issue.

At Kernel 5.8.0-49 IR went wonky with repeating key button presses for quite some time although it does finally appear to stop after seventy-six (76) times of:

```
44076.138469: event type EV_KEY(0x01) key_up: KEY_VOLUMEUP(0x0073)
44076.138469: event type EV_SYN(0x00).
```

Same "work-around" that is discussed at https://github.com/clontarfx/kodi-rc6-mce-nolirc/issues/3 needs to be applied even in the wonky state.

[Tom Horsley (tom-horsley)]

Looks like the bug I just added at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932360 is a duplicate of this which I didn't find in any searches before I added it.

[Marti Martz (martiimartz)]

@tom-horsley

It's alright. Glad to see I'm not the only one with this "wonky" state. Hard term to search on. I just retested on:

```
Linux 5.8.0-55-generic #62~20.04.1-Ubuntu SMP Wed Jun 2 08:55:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
```

... this morning and it still repeats.

Please make sure to add to the "bug heat" icon at the top of this page so it gets addressed sooner. And add yourself to the "affects me" list too at the top of this bug.

It's a little confusing on all the replies here on exactly which kernel has fixed the IR and when it will land in an apt release so drudging merrily forward. :)

I've temporarily worked around by using a RF media remote for the time being but I really miss the IR remote features I've assigned.