All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Young <sean@mess.org>
To: Matthias Reichl <hias@horus.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media@vger.kernel.org
Subject: Re: Bug: decoders referenced in kernel rc-keymaps not loaded on boot
Date: Tue, 21 Feb 2017 19:34:39 +0000	[thread overview]
Message-ID: <20170221193438.GA4394@gofer.mess.org> (raw)
In-Reply-To: <20170221184929.GA2590@camel2.lan>

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?

Thanks,
Sean

  reply	other threads:[~2017-02-21 19:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-21 18:49 Bug: decoders referenced in kernel rc-keymaps not loaded on boot Matthias Reichl
2017-02-21 19:34 ` Sean Young [this message]
2017-02-21 22:52   ` Matthias Reichl
2017-02-22 23:00     ` Sean Young
2017-02-22 23:11       ` [PATCH] [media] rc: raw decoder for keymap protocol is not loaded on register Sean Young
2017-02-23 19:00         ` Matthias Reichl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170221193438.GA4394@gofer.mess.org \
    --to=sean@mess.org \
    --cc=hias@horus.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.