Re: ir-core multi-protocol decode and mceusb

[Andy Walls <awalls@md.metrocast.net>]

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.  

Regards,
Andy