Re: [PATCH 01/18] lirc core device driver infrastructure

[Gerd Hoffmann <kraxel@redhat.com>]

Dmitry Torokhov wrote:
> Couple of questions - what is missing in the current input core to
> properly support IR devices?

One issue is *sending* IR codes.
Another one is access to the raw IR signal (more on this below).

Probably 90% of the users are happy without that.

> Could we try to work it in ininput core and
> maybe provide LIRC device access through an input handler
> implementation so that applications do not have to implement 2 types of
> interfaces?

Not needed.  Applications don't talk to the lirc device directly, they
talk to the lircd daemon.  The lircd daemon can handle linux input layer
devices just fine.  So moving drivers from lirc to the input layer can
be done transparently to the applications.

Quite some time ago, back the days when I maintained video4linux, I've
switched the tv card IR drivers from lirc to the input layer.  Main
reason for that was that having a in-kernel driver using an out-of-tree
subsystem was a PITA.  I think these days most (all?) TV card drivers
use the input layer for the IR remotes frequently shipped with those cards.


Some more background, using the Hauppauge cards as example, which
usually use rc5 coding with the remotes.

The older, bt878 based ones do decoding in hardware (i2c chip).  You'll
get the decoded rc5 keycode.

The newer, cx88 based ones just sample the raw IR signal and give you
that.  The decoding has to be done in software.  The driver can program
the sample rate and has to do the biphase decoding in software to get
the rc5 keycodes.  The driver gets that done just fine, and the remote
shipped with the TV card works without problems.

The part which doesn't work is supporting *any* remote.  The (newer)
hardware gives you the raw IR signal, so it is possible to decode any IR
signal in software.  The missing bit is some way to send the raw IR
samples to userspace (i.e. the lircd daemon) for decoding.  lirc drivers
do just that.

HTH,
  Gerd