Message-ID: <20080912044416.GA18385@anvil.corenet.prv>
Date:	Fri, 12 Sep 2008 00:44:16 -0400
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Gerd Hoffmann <kraxel@...hat.com>
Cc:	Jarod Wilson <jwilson@...hat.com>, linux-kernel@...r.kernel.org,
	Jarod Wilson <jarod@...hat.com>, Janne Grunau <j@...nau.net>,
	Christoph Bartelmus <lirc@...telmus.de>,
	Mario Limonciello <superm1@...ntu.com>
Subject: Re: [PATCH 01/18] lirc core device driver infrastructure

Hi Gerd,

On Thu, Sep 11, 2008 at 10:47:10AM +0200, Gerd Hoffmann wrote:
> 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.
> 

I see. I guess what I would like to see it first to have "smart"
devices that do decoding in hardware to be converted to input subsystem
since lirc can use it and other programs can do that too. We should
probably start using KEY_NUMERIC_* there to help userspace
distinguishing RC keys from normal numeric/keypad keys.

For protocols that require decoding in userspace the best solution IMHO
is to route them back via uinput so that applications would not need to
keep implementing 2 interfaces, one for standard input devices and
another for lirc.

I am not sure if input devices are the best for transmittign raw IR
signal. It is pretty easy to add EV_MSC/IR_RAW event type to the input
core... It would give you a timestamp and a 32 bit value... I guess I
need to start looking at extending number of event devices in the
system.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists