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

Andy Walls
2009-12-01T11:50:48Z

On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote:
> Hi,
>
> > A current related problem is that i2c based devices can only be bound to
> > only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time.
> > Currently it is somewhat up to the bridge driver which binding is
> > preferred. Discussion about this for the pvrusb2 module had the biggest
> > email churn IIRC.
>
> 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....

> cheers,
> Gerd
>
> PS: Not sure this actually makes sense for the i2c case, as far I know
> these do decoding in hardware and don't provide access to the raw
> samples,

True.

> 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?

Thanks,
Andy