Re: Status of lirc. should I create new reciever driver against it?

[Maxim L. <max...@gm...>]

On Fri, 2009-05-29 at 23:50 +0200, Christoph Bartelmus wrote:
> Hi!
> 
> Maxim Levitsky "max...@gm..." wrote:
> [...]
> > I want to write a kernel driver for this device, but I don't know if I
> > need to write it against lirc, or recently posted on LKML in-kernel IR
> > framework.
> [...]
> > What are your suggestions?
> 
> Just implement a LIRC driver.
> 
> The last suggestion that seemed to be accepted was that the IR data is  
> received by the LIRC drivers and is passed to a in-kernel decoder if the  
> user configures it so. Otherwise it's passed to lircd in user-space.
> 
> The in-kernel decoder code was far from complete and I still have concerns  
> that it can work in all situations.

Me too.

In my opinion, kernel drivers should pass raw IR data to userspace, but
lircd should process it and use uinput to send it back to kernel.


Here are 2 reasons why:


1 - obscure remotes:
Here is a real word example, I have a remote for a air conditioner unit.
The remote has 'state'. It displays current settings on its LCD, and
uploads all settings when any of them change.

It sends quite big packet, encoded with typical pulse distance encoding.
Thus the typical approach of sending keys won't work, and besides there
is really no point to add support for this in kernel.
Instead I could write my own (trivial) program to do decoding, and then
use decoded data as I wish (actually I already have one...)
Thus I really think kernel should at least allow to see raw data, and
not via some 'debug' interface.
This still doesn't rule out in kernel approach.




2 - userspace driver:
There will always be pure userspace drivers, like the one that records
from soundcard.
These won't have access to in kernel decoder, thus will have to use
their own decoder, and, most importantly, they won't be able to use
configfs interface, thus we end up with two decoders, two config
interfaces, etc...


But the idea of having a state machine is really great, and thus I think
that:

1 - we should cleanup kernel drivers, and merge them upstream, 
These drivers should expose a unified interface to allow reading the ir
timings, (unified scale, in microseconds I think).
Reading/writing should be done via char device as it is already done.


2 - make lirc use uinput, and _depricate_ its own interface.
(and in same time clean it up)

It is possible even to rewrite userspace, kernel space or both parts or
lirc, they aren't that big.

Also it would be  nice to make lirc automaticly guess the protocol,
using these state machines, thus allowing you to create more 'high
level' config files for lirc.

Thats all, that what I think



Best regards,
	Maxim Levitsky