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

[David Härdeman]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/