Re: ir-core multi-protocol decode and mceusb

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

Em 31-05-2010 16:38, Andy Walls escreveu:
> On Mon, 2010-05-31 at 16:06 -0300, Mauro Carvalho Chehab wrote:
>> Hi Andy,
>>
>> Em 31-05-2010 09:15, Andy Walls escreveu:
>>>> I've now got an ir-lirc-codec bridge passing data over to a completely
>>>> unmodified lirc_dev, with the data then making its way out to the
>>>> lircd userspace where its even getting properly decoded. I don't have
>>>> the transmit side of things in ir-lirc-codec wired up just yet, but
>>>> I'd like to submit what I've got (after some cleanup) tomorrow, and
>>>> will then incrementally work on transmit. I'm pretty sure wiring up
>>>> transmit is going to require some of the bits we'd be using for native
>>>> transmit as well, so there may be some discussion required. Will give
>>>> a look at setting enabled/disabled decoders tomorrow too, hopefully.
>>>
>>>
>>> Since you're looking at Tx, please take a look at the v4l2_subdev
>>> interface for ir devices.  See 
>>>
>>> linux/include/media/v4l2-subdev.h: struct v4l2_subdev_ir_ops 
>>>
>>> I was wondering how this interface could be modified to interface nicely
>>> to lirc (or I guess ir-lirc-codec) for transmit functionality.
>>
>>> Right now, only the cx23885 driver uses it:
>>>
>>> linux/drivers/media/video/cx23885/cx23888-ir.[ch]
>>>
>>> I have the skeleton of transmit for the device implemented (it does need
>>> some fixing up).
>>>
>>> (The CX23888 hardware is nice in that it only deals with raw pulses so
>>> one can decode any protocol and transmit any protocols.  The hardware
>>> provides hardware counter/timers for measuring incoming pulses and
>>> sending outgoing pulses.)
>>
>> This interface is bound to V4L needs. As the Remote Controller subsystem
>> is meant to support not only V4L or DVB IR's, but also other kinds of remote
>> controllers that aren't associated to media devices, it makes no sense on
>> binding TX to this interface. 
>>
>> The biggest advantage of V4L subdev interface is that a command, like VIDIOC_S_STD
>> could be sent to several devices that may need to know what's the current standard,
>> in order to configure audio, video, etc. It also provides a nice way to access
>> devices on a device-internal bus. In the case of RC, I don't see any similar
>> need. So, IMO, the better is to use an in interface similar to RX for TX, e. g.,
>> something like:
>> 	rc_register_tx()
>> 	rc_unregister_tx()
>> 	rc_send_code()
> 
> Right, I agree.  The v4l2_subdev ir_ops is a detail hidden by the bridge
> driver and the bridge driver needs to deal with that.  A registration
> process seems to be the proper way to do things.
> 
> BTW, maybe
> 
> 	rc_set_tx_parameters()
> 
> is needed as well to set up the parameters for the transmitter.
> 
> I haven't looked very hard at rc_register_rx() and related functions so
> I will soon.  

They are declared at include/media/ir-core.h. The actual name is ir_input_register().

The RX parameters are configured at the IR structs, before calling the function.

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.

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)


Cheers,
Mauro.