Em 31-05-2010 18:45, Andy Walls escreveu:
> On Mon, 2010-05-31 at 17:58 -0300, Mauro Carvalho Chehab wrote:
>> I may be wrong (since we didn't write any TX support), but I think that a
>> rc_set_tx_parameters() wouldn't be necessary, as I don't see why the driver
>> will
>> change the parameters after registering, and without any userspace request.
>
> Yes, my intent was to handle a user space request to change the
> transmitter setup parameters to handle the protocol.
>
> I also don't want to worry about having to code in kernel parameter
> tables for any bizzare protocol userspace may know about.
Makes sense.
>
>
>> If we consider that some userspace sysfs nodes will allow changing some
>> parameters,
>> then the better is to have a callback function call, passed via the
>> registering function,
>> that will allow calling a function inside the driver to change the TX
>> parameters.
>>
>> For example, something like:
>>
>> struct rc_tx_props {
>> ...
>> int (*change_protocol)(...);
>> ...
>> };
>>
>>
>> rc_register_tx(..., struct rc_tx_props *props)
>
> A callback is likely needed. I'm not sure I would have chosen the name
> change_protocol(), because transmitter parameters can be common between
> protocols (at least RC-5 and RC-6 can be supported with one set of
> parameters), or not match any existing in-kernel protocol. As long as
> it is flexible enough to change individual transmitter parameters
> (modulated/baseband, carrier freq, duty cycle, etc.) it will be fine.
I just used this name as an example, as the same name exists on RX.
Depending on how we code the userspace API, we may use just one set_parameters
function, or a set of per-attribute changes.
In other words, if we implement severa sysfs nodes to change several parameters,
maybe it makes sense to have several callbacks. Another alternative would be
to have a "commit" sysfs node to apply a set of parameters at once.
> Currently LIRC userspace changes Tx parameters using an ioctl(). It
> asks the hardware to change transmitter parameters, because the current
> model is that the transmitters don't need to know about protocols. (LIRC
> userspace knows the parameters of the protocol it wants to use, so the
> driver's don't have too).
>
>
> I notice IR Rx also has a change_protocol() callback that is not
> currently in use.
It is used only by em28xx, where the hardware decoder can work either with
RC-5 or NEC (newer chips also support RC-6, but this is currently not
implemented).
> If sending raw pulses to userspace, it would be also
> nice to expose that callback so userspace could set the receiver
> parameters.
Raw pulse transmission is probably the easiest case. Probably, there's nothing
or a very few things that might need adjustments.
>
>
> Regards,
> Andy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
