[lkml]   [2008]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 01/18] lirc core device driver infrastructure
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.

Just my .02 cents,

I personally don't like the lircd daemon (*), I would like to have all input keycodes in
input layer.
What do you, lirc developers think about making lircd a daemon that injects input events via uinput?

(*) the reason I don't like lircd is that not all applications support it.

Best regards,
Maxim Levitsky

> HTH,
> Gerd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at

 \ /
  Last update: 2008-09-11 23:31    [W:0.081 / U:1.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site