Another approach to IR
in [Kernel]
|
From: Mauro Carvalho Chehab on 3 Dec 2009 05:10 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 3 Dec 2009 06:20 Jon Smirl wrote: > On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab > <mchehab(a)redhat.com> wrote: >> Jon Smirl wrote: >>> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson <jarod(a)wilsonet.com> wrote: >>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: >>>> >>>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: >>>>>> On 12/2/09 12:30 PM, Jon Smirl 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? >>>>>>> The code I posted using configfs did that. Instead of making apps IR >>>>>>> aware it mapped the vendor/device/command triplets into standard Linux >>>>>>> keycodes. Each remote was its own evdev device. >>>>>> Note, of course, that you can only do that iff each remote uses distinct >>>>>> triplets. A good portion of mythtv users use a universal of some sort, >>>>>> programmed to emulate another remote, such as the mce remote bundled >>>>>> with mceusb transceivers, or the imon remote bundled with most imon >>>>>> receivers. I do just that myself. >>>>>> >>>>>> Personally, I've always considered the driver/interface to be the >>>>>> receiver, not the remote. The lirc drivers operate at the receiver >>>>>> level, anyway, and the distinction between different remotes is made by >>>>>> the lirc daemon. >>>>> The fact that lirc does it this way does not necessarily mean it is the >>>>> most corerct way. >>>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. >>>> >>>>> Do you expect all bluetooth input devices be presented >>>>> as a single blob just because they happen to talk to the sane receiver >>>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged >>>>> together just because they end up being serviced by the same host >>>>> controller? If not why remotes should be any different? >>>> A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. >>> Actually remotes do have an ID. They all transmit vendor/device pairs >>> which is exactly how USB works. >>> >> Well, the description of NEC and RC5 protocol at http://www.sbprojects.com/knowledge/ir/rc5.htm >> doesn't mention any vendor/device pair, nor I'm able to get them with the IR hardware decoders >> I have. > > Some of the protocols were not intended to be multi-vendor - the > vendor is implicit in the protocol encoding. You don't have to split > the IR codes into vendor/device/command triplets. I just do that > because it is convenient to think of them that way. It is equally > valid to treat them as a 64b integers and use four bits of the int to > encode the protocol. It should really be a quad > protocol/vendor/device/command and some of the fields may be missing. > Bottom line, you are looking for unique codes how the fields are split > up doesn't really matter. Currently, there aren't any in-kernel driver that support 64 bit IR's. They support only up to 16 bits. So, we have only address (device)/command. As I said before, AFAIK, only RC6 mode 6 remotes support 64 bits. As pointed by Andy, it is risky to support such protocol in kernel, since you won't be able to ship the kernel to countries where RC6 patents got accepted, or you would need. > A fixed protocol receiver is more of a challenge. You have to figure > out how to make a universal remote transmit device codes for a device > you don't already own that is also encoded in the protocol your > hardware supports. > There's nothing we can do about that problem in > Linux, its a side effect of fixed protocol decode hardware. With hardware decoders, you're limited to the supported protocols, but yet, you can use a different scancode than the one that comes with the shipped device. If you take a look, for example, at the NEC protocol decoder we have on drivers/media/video/saa7134/saa7134-input.c [1], you'll see that the tasklet (nec_task) holds CPU control up to 76.5 ms, in order to be able to receive the entire sequence at the GPIO port. Fortunately, on the device where this decoder is called (Avermedia M135A), we can trigger the start of the IR code via IRQ. [1]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/video/saa7134/saa7134-input.c;h=6e219c2db8419013ab3ced30470ad1c19431974a;hb=HEAD In this specific decoder I've implemented it some time ago. I think I tried first to get the pulse/space width using just IRQ without the tasklet, but the lengths weren't precise enough for decoding. Also, if you have a bad contact at the IR sensor connector, as it is directly connected to an IRQ pin, you may end by hanging the machine, if the code is not carefully written. I remember I had some bad time due to the bad contacts at the IR sensor with the sample I had available for implementing that IR. Btw, looking at that code, while it is not impossible to split the IR pulse/space measures from the NEC decoder itself, and make it generic to support other protocols, it is not a trivial task, and may result on a less stable driver. Without splitting the protocol decoder, even being able to store raw pulse/space data on some fifo, the driver will still limit the protocol for that board to NEC (there is a similar code for RC5 there also, using some generic functions [2]). [2]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/common/ir-functions.c;h=16792a68a44951e1bc1c2cbb1c9da27a2b6b2722;hb=HEAD The advantage of the NEC decoding approach on saa7134 is that you know for sure how much time it is required to get the entire code. So, the code can easily abort the reception of a bad code. The disadvantage is that only one protocol can be decoded at the same time. The same problem also happens with almost all in-kernel drivers: the decoders for raw mode were constructed to work with just one pulse/space code at the same time. A conversion into a generic code can happen, but it will require several tests to be sure that they won't cause undesirable side-effects. The advantage of hardware decoders is that you don't need to be polling the IR serial port at a high rate, as you'll get directly the code. So, you'll free the CPU to do something else. > You're just going to have to start guessing devices in the remote until you > find one that uses your fixed protocol and doesn't also activate the > devices you own. We can put suggestions in the doc when working > devices are discovered. With a universal receiver the problem is > simpler, just pick a device you don't own - the encoding protocol > doesn't matter. These are generic problems with IR that are the same > no matter how things get implemented in Linux. Yes, provided that we can successfully change the drivers to split decoders from pulse/space counting. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 3 Dec 2009 06:20 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. The better is to add the lirc glue at ir-common module. There, we have the support functions used by all V4L devices, and they'll be expanded to cover also dvb-usb, as soon as I can find some time to do a patch for it. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andy Walls on 3 Dec 2009 07:10 On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote: > 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: > > 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. These were just ideas. I haven't done *anything* yet. ;) > 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. I think I see what you are saying (I wish could see look at a whiteboard somewhere...). Wherever we come through internally to split to 2 different userspace interfaces is fine, if you've got a big picture plan you think is feasible. That seems like a bit of perturbation to lirc_zilog and lirc_i2c. My thought was that lirc_v4l using the standardized v4l2_subdev_ir_ops interface, and maybe some new calls associted with v4l2_device, could subsume/unify all the functionality of lirc_i2c, lirc_zilog, ... lirc_whatever. Maybe that's just a poorly thought out dream though... > 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. The v4l_subdevice just abstracted the IR hardware into a nice (mental) box for me -- easier to keep hardware separate from software decoders and userspace interface logic. Also, since v4l2_subdevices may have per subdevice /dev nodes and the /dev/../mcN nodes providing a discovery mechanism due to the Meda Controller framework, wrapping things in v4l2_subdevice may be handy for development and debug. Or ... as an additional operational interface to userspace. :D *ducks and runs for cover* Regards, Andy > Cheers, > Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ferenc Wagner on 3 Dec 2009 11:10
Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > Dmitry Torokhov wrote: > >>>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: >>>>> >>>>>> Now I understand that if 2 remotes send completely identical >>>>>> signals we won't be able to separete them, but in cases when we >>>>>> can I think we should. >> >> They are the same key events (Lets's say KEY_PLAY) but one is >> supposed to affect CD player while another DVD player >> application. Evdev will not be able to distinguish them but if we had >> 2 separate devices then applications could read from the one thet >> user assigned to them. > > This is clear, but the point is that the two distinguish scancodes can > (and, in practice, will) be generated by the same IR. For example, my > Satellite IR produces two different sets of codes. if you press <SAT>, > all keys you press after that will have the "sat" address. If you > press <TV>, they'll get a different address. The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent by any remote (ok, I'm stretching it a bit). Instead, a multifunction remote (or two distinct remotes) would send different scan codes[1], which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example. Btw. the former is already defined, besides the generic KEY_PLAY. Even if all this worked, user space would need integration with hal/devicekit to open the new input devices appearing on the fly (if it's initiated by the arrival of a scan code belonging to some new protocol), and also be able to decide whether the new event source is for it or not. Given that commodity home appliances manage not to be confused by multiple or multifunction remotes, decent software should be able to do so as well. [1] scan codes in the broadest possible sense, containing vendor, address and whatever, and only treating the case which is possible to handle in principle. -- Regards, Feri. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |