Re: [RFC v2] Another approach to IR

Andy Walls wrote:
On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

Dmitry Torokhov wrote:
...
(for each remote/substream that they can recognize).
I'm assuming that, by remote, you're referring to a remote receiver (and not to
the remote itself), right?
If we could separate by remote transmitter that would be the best I
think, but I understand that it is rarely possible?
IMHO, the better is to use a separate interface for the IR transmitters,
on the devices that support this feature. There are only a few devices
I'm aware of that are able to transmit IR codes.
If I'm thinking clearly, there are only three lirc kernel drivers that
support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
driver was posted, so I won't rehash what it is here. The zilog driver
binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
etc). The serial driver is fairly self-explanatory as well.

There are also a few userspace-driven devices that do transmit, but
I'm assuming they're (currently) irrelevant to this discussion.


I've got the CX23888 integrated IR Rx done and Tx nearly done. I was
waiting to see how kfifo and lirc_dev panned out before making the
interface to userspace.

The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
I hope to have CX23885 IR done by Christmas.

Both of those IR devices are/will be encapsulated in a v4l2_subdevice
object internally. I was going to write lirc_v4l glue between the
v4l2_device/v4l2_subdev_ir_ops and lirc_dev.

As for the the I2C chips, I was going to go back and encapsulate those
in the v4l2_subdevice object as well, so then my notional lirc_v4l could
pick those up too. The I2C subsystem only allows one binding to an I2C
client address/name on a bus. So without some new glue like a notional
lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
lirc_zilog.

Maybe you're having a bad time because you may be trying to integrate lirc
at the wrong place.

All devices at V4L tree including ir-kbd-i2c use ir-common.ko
(at /drivers/media/common tree) module to communicate to IR's.
I'm preparing some patches to extend this also to dvb-usb devices
(that uses a close enough infrastructure).

Also, most of the decoding code are there, in a form of helper routines.

As the idea is to provide lirc interface to all devices that can work with
raw pulse/space, the proper place is to write a subroutine there that, once
called, will make those pulse/space raw codes available to lirc and will
call the needed decoders to export them also to evdev.

The code at ir-common module was originally built to be used by V4L, but I'm
porting the code there to be generic enough to be a library that can be used
by other drivers. So, lirc_zilog and other lirc devices that will need to open
evdev interfaces after running a decoder can use them.

Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should
be implemented as a separate module.

Cheers,
Mauro.
--
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/

Relevant Pages

  • Re: [patch 0/2] Winbond IR Driver - v2
    ... I just want to write the driver that fully exposes the hardware. ... decode just one remote, in my opinion aren't that great. ... There have been repeated attempts to get LIRC merged with the kernel, ... It isn't a NEC protocol, it actually has its own protocol ...
    (Linux-Kernel)
  • Re: [RFC v2] Another approach to IR
    ... I'm assuming that, by remote, you're referring to a remote receiver (and not to ... If we could separate by remote transmitter that would be the best I ... I'm aware of that are able to transmit IR codes. ... driver was posted, so I won't rehash what it is here. ...
    (Linux-Kernel)
  • Re: [RFC v2] Another approach to IR
    ... I'm assuming that, by remote, you're referring to a remote receiver (and not to ... If we could separate by remote transmitter that would be the best I ... I'm aware of that are able to transmit IR codes. ... driver was posted, so I won't rehash what it is here. ...
    (Linux-Kernel)
  • [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev
    ... All of this kernel code is tiny, about 20K including a driver. ... This only converts from protocol pulse timing to common command format. ... Decoded core protocols pass through a translation map based on configfs ... This transforms a button push of 1 on my remote into a key stroke for KEY_1 ...
    (Linux-Kernel)
  • RE: Remote Web Workplace and Local Printing
    ... remote desktop of RWW from a remote PC, however, you can not find the local ... The local printer's driver is not for Windows Server 2003, ... Microsoft CSS Online Newsgroup Support ... newsgroups so that they can be resolved in an efficient and timely manner. ...
    (microsoft.public.windows.server.sbs)