Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Gerd Hoffmann wrote:
> On 12/01/09 12:49, Andy Walls wrote:
>> On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote:
>>> Once lirc_dev is merged you can easily fix this:  You'll have *one*
>>> driver which supports *both* evdev and lirc interfaces.  If lircd opens
>>> the lirc interface raw data will be sent there, keystrokes come in via
>>> uinput.  Otherwise keystrokes are send directly via evdev.  Problem
>>> solved.
>>
>> This will be kind of strange for lirc_zilog (aka lirc_pvr150).  It
>> supports IR transmit on the PVR-150, HVR-1600, and HD-PVR.  I don't know
>> if transmit is raw pulse timings, but I'm sure the unit provides codes
>> on receive.  Occasionally blocks of "boot data" need to be programmed
>> into the transmitter side.  I suspect lirc_zilog will likely need
>> rework....
> 
> Well, for IR *output* it doesn't make sense to disable evdev.  One more
> reason which indicates it probaably is better to introduce a ioctl to
> disable evdev reporting.  lircd will probably turn it off, especially
> when sending data to uevent.  debug tools might not, likewise apps
> sending IR.
> 
>>>   so killing the in-kernel IR limits to make ir-kbd-i2c
>>                    ^^^^^^^^^^^^^^^^^^^
>>>        being on par with lirc_i2c might be more useful in this case.
>>
>> I didn't quite understand that.  Can you provide a little more info?
> 
> Such as throwing away the address part of rc5 codes ...

This limit were already removed from the subsystem core by the patches
I committed recently (still only at the devel tree - I should be adding
those patches to my linux-next tree likely today). 

The remaining issue is that we'll need to re-scan the IR tables for 
every supported remote to be sure that we're getting the full RC5 code.
It is not complex, but requires lots of work from people that actually have
those IR's.

Cheers,
Mauro.