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

David Härdeman
2010-03-26T13:32:55Z

On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
>> 2) add current_protocol support on other drivers;
>
> Done. Patch were already merged upstream.
>
> The current_protocol attribute shows the protocol(s) that the device is accepting
> and allows changing it to another protocol.
>
> In the case of the em28xx hardware, only one protocol can be active, since the decoder
> is inside the hardware.
>
> On the raw IR decode implementation I've done at the saa7134, all raw pulse events are
> sent to all registered decoders, so I'm thinking on using this sysfs node to allow
> disabling the standard behavior of passing the IR codes to all decoders, routing it
> to just one decoder.
>
> Another alternative would be to show current_protocol only for devices with hardware
> decoder, and create one sysfs node for each decoder, allowing enabling/disabling each
> decoder individually.

You're eventually going to want to add ioctl's to set a lot of TX or RX
parameters in one go (stuff like active receiver(s) and transmitter(s),
carrier frequency, duty cycle, timeouts, filter levels and resolution -
all of which would need to be set in one operation since some hardware
will need to be reset after each parameter is changed).

Then you'll end up with a few things being controlled via sysfs and some
being controlled via ioctls. Maybe it's a good idea to have a bitmask of
supported and enabled protocols in those ioctls instead?

--
David Härdeman