There seems to be a bug in on-demand loading of IR protocol decoders. After bootup the protocol referenced in the in-kernel rc keymap shows up as enabled (in sysfs and ir-keytable) but the protocol decoder is not loaded and thus no rc input events will be generated.
For example, RPi3 with kernel 4.10 and gpio-ir-recv configured to use the rc-hauppauge keymap in devicetree: # lsmod | grep '^\(ir\|rc_\)' ir_lirc_codec 5590 0 rc_hauppauge 2422 0 rc_core 24320 5 rc_hauppauge,ir_lirc_codec,lirc_dev,gpio_ir_recv # cat /sys/class/rc/rc0/protocols other unknown [rc-5] nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp cec [lirc] # dmesg | grep "IR " [ 4.506728] Registered IR keymap rc-hauppauge [ 4.554651] lirc_dev: IR Remote Control driver registered, major 242 [ 4.576490] IR LIRC bridge handler initialized The same happens with other IR receivers, eg the streamzap receiver, which uses the rc-5-sz protocol / ir_rc5_decoder, on x86. Reverting the on-demand-loading patches [media] media: rc: remove unneeded code commit c1500ba0b61e9abf95e0e7ecd3c4ad877f019abe [media] media: rc: move check whether a protocol is enabled to the core commit d80ca8bd71f0b01b2b12459189927cb3299cfab9 [media] media: rc: load decoder modules on-demand commit acc1c3c688ed8cc862ddc007eab0dcef839f4ec8 restores the previous behaviour, all decoders are enabled and IR events can be generated immediately after boot without having to manually trigger loading of a protocol decoder. so long, Hias
