Messages in this thread | | | Date | Fri, 12 Sep 2008 00:28:04 +0300 | From | Maxim Levitsky <> | Subject | Re: [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. Hi,
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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
| |