On Tue, Feb 21, 2017 at 11:52:24PM +0100, Matthias Reichl wrote: > On Tue, Feb 21, 2017 at 07:34:39PM +0000, Sean Young wrote: > > On Tue, Feb 21, 2017 at 07:49:29PM +0100, Matthias Reichl wrote: > > > 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. > > > > Hmm this seems to be working fine for me. If you write to the protocols > > file, eg. "echo +nec > /sys/class/rc/rc0/protocols", is ir-nec-decoder > > loaded and do you get any messages in dmesg (you should). > > > > What's your config? > > When I do an "echo +nec > /sys/class/rc/rc0/protocols" it triggers > the load of both rc5 and nec decoder modules: > > root@rpi3:~# 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] > root@rpi3:~# echo +nec > /sys/class/rc/rc0/protocols > root@rpi3:~# 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] > root@rpi3:~# dmesg | grep "IR " > [ 3.565061] Registered IR keymap rc-hauppauge > [ 3.613031] lirc_dev: IR Remote Control driver registered, major 242 > [ 3.641423] IR LIRC bridge handler initialized > [ 41.877263] IR RC5(x/sz) protocol handler initialized > [ 41.931575] IR NEC protocol handler initialized > > I'm currently testing with downstream RPi kernel 4.9 on Raspbian Jessie > (a Debian derivate). > > Kernel config is here: > https://github.com/raspberrypi/linux/blob/rpi-4.9.y/arch/arm/configs/bcm2709_defconfig > > To reproduce the issue it's important to disable the udev rule that > runs ir-keytable -a as that can trigger a load of the kernel keytable > via the userspace keymap/protocol. Ah. Yes, this is broken. In commit "9f0bf36 [media] media: rc: preparation for on-demand decoder module loading", code was added so that only the required decoder module was loaded. This added it to the sysfs protocols attribute handling, but not to the rc_register_device(), so no decoder will be loaded when a device is first registered. As you say the udev rule papers over the problem by executing ir-keytable, so I never noticed the problem either. I'll send a patch as a reply to this email. Sean
