Re: [RFC v2] Another approach to IR
Dmitry Torokhov dmitry.torok...@gmail.com writes: On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: We should not forget that simple IR's don't have any key to select the address, so the produced codes there will never have KEY_TV/KEY_DVD, etc. Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select media inputs in a device/application. My receiver accepts codes like that. Sorry, my point wasn't the event names, I picked them for their superficial correspondence to the TV, DVD, SAT etc. buttons found on multifunction remotes. Obviously I picked wrong. I was also wrong to assume that remotes with such buttons are always multifunction remotes in the sense that they are meant to control separate devices. As Mauro pointed out, (some) bundled remotes with such buttons aren't; thus I wouldn't consider them multifunction at all. They simply have some extra buttons labelled TV, DVD etc, which probably shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry different semantics) but should be mapped to something else. Or not, if these buttons change some internal decoder state instead, modifying the mapping or destination input device of the other keys. It's just a different scenario, where the kernel could reasonably give rather different representations to simple applications aiming at plugplay: letting through the function change events untouched, or masking and using them internally. True multifunction devices don't send such events, the TV, DVD etc buttons on them change their internal state and the scan codes sent by the other keys, if I understand this correctly. I'd prefer if these two behaviours could be abstacted from, and the input layer interface would provide destination selection events + generic events, or (to be defined) device specific events only in either case. Is that possible or even reasonable? -- Thanks, Feri. Ps: I'm writing this in the hope to clean up the landscape and possibly help in choosing the best design. I'm not at all familiar with IR, and the above distinction was pretty surprising for me. Also, I'm just lurking here, so don't take me too seriously. :) -- 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
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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. 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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@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
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: ... Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Okay, in the above scenario, you've still got a single input device... Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per remote though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...). It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one. Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it. Simple use case: You have a multifunction remote. Press the CABLE key - it sends out commands that control the cable box, press the TV key - now the commands control the TV, press CD - now the CD player, etc. Now imagine a headless Linux box running a music server and a home automation app. Press the CD key - commands get routed to the music server, press the AUX key - commands get routed to the home automation app. This is accomplished by recognizing the device code part of the IR signal and figuring out that there are two different device codes in use. The commands of then routed to two evdev devices corresponding to the two different device codes. Using things like Alt-Tab to switch apps is impossible. There's no screen to look at. This usecase makes sense to me. With the risk of repeating myself, you don't have two physical remotes. The needed feature is a way to split one source of input events (that happens to be an infrared remote, but it could also be any other type of input device, like a bluetooth remote) into several different evdev interfaces, based on scancode groups. Also, as you're thinking on 64 bits scancodes, this also means that the current evdev KABI and API will require changes to support bigger scancodes. Anyway, IMO, this subject should be handled as a different requirement than integrating the lirc drivers. Cheers, Mauro. -- To unsubscribe from this list:
Re: [RFC v2] Another approach to IR
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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Mauro Carvalho Chehab mche...@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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Dmitry Torokhov wrote: 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). Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc. On those remotes, if you press TV and then press for example Channel UP and press Radio, then press Channel UP, the channel UP code will be the same. For example, on Hauppauge Grey IR, we have: TV [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0 CHANNEL UP [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 Radio [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0 CHANNEL UP [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the shipped IR's. 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. I see two alternatives for it: 1) to map a multifunction scancode Address=TV/command=channel up as two separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to handle it (lirc or other programs that knows IR keycodes); 2) to implement Jon's filter idea of splitting one evdev interface into several evdevs interface, one for each address. We should not forget that simple IR's don't have any key to select the address, so the produced codes there will never have KEY_TV/KEY_DVD, etc. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Dmitry Torokhov wrote: 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). Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc. On those remotes, if you press TV and then press for example Channel UP and press Radio, then press Channel UP, the channel UP code will be the same. For example, on Hauppauge Grey IR, we have: TV [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0 CHANNEL UP [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 Radio [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0 CHANNEL UP [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the shipped IR's. The remote is treating everything as a single integrated device which is not inconsistent with what has been said. In this case there really is only one multi-function device not two independent ones. If you want to control two independent devices you need to buy a different remote. Remotes are cheap so that's not a big deal. If you really want to use this remote to control two independent devices you need user space scripting to split the single device into two devices and then inject new events into the input layer. This is a complex case and not in the goal of getting 90% of users to just work. 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. I see two alternatives for it: 1) to map a multifunction scancode Address=TV/command=channel up as two separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to handle it (lirc or other programs that knows IR keycodes); 2) to implement Jon's filter idea of splitting one evdev interface into several evdevs interface, one for each address. We should not forget that simple IR's don't have any key to select the address, so the produced codes there will never have KEY_TV/KEY_DVD, etc. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- 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
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: ... Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Okay, in the above scenario, you've still got a single input device... Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per remote though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...). It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one. Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it. Simple use case: You have a multifunction remote. Press the CABLE key - it sends out commands that control the cable box, press the TV key - now the commands control the TV, press CD - now the CD player, etc. Now imagine a headless Linux box running a music server and a home automation app. Press the CD key - commands get routed to the music server, press the AUX key - commands get routed to the home automation app. This is accomplished by recognizing the device code part of the IR signal and figuring out that there are two different device codes in use. The commands of then routed to two evdev devices corresponding to the two different device codes. Using things like Alt-Tab to switch apps is impossible. There's no screen to look at. This usecase makes sense to me. With the risk of repeating myself, you don't have two physical remotes. The needed feature is a way to split one source of input events (that happens to be an infrared remote, but it could also be any other type of input device, like a bluetooth remote) into several different evdev interfaces, based on scancode groups. In real world you generally have two physical remote. In this particular case you simply have a sort of semi-universal remote, a two or tree in one remote. More particularly, you have a remote which is aimed at talking to two or tree different real devices or in our case different applications. If the application
Re: [RFC v2] Another approach to IR
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: We should not forget that simple IR's don't have any key to select the address, so the produced codes there will never have KEY_TV/KEY_DVD, etc. Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select media inputs in a device/application. My receiver accepts codees like that. -- Dmitry -- 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
Re: [RFC v2] Another approach to IR
Em Thu, 3 Dec 2009 11:50:04 -0500 Jon Smirl jonsm...@gmail.com escreveu: On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Dmitry Torokhov wrote: 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). Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc. On those remotes, if you press TV and then press for example Channel UP and press Radio, then press Channel UP, the channel UP code will be the same. For example, on Hauppauge Grey IR, we have: TV [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0 CHANNEL UP [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 Radio [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0 CHANNEL UP [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the shipped IR's. The remote is treating everything as a single integrated device which is not inconsistent with what has been said. In this case there really is only one multi-function device not two independent ones. If you want to control two independent devices you need to buy a different remote. Remotes are cheap so that's not a big deal. If you really want to use this remote to control two independent devices you need user space scripting to split the single device into two devices and then inject new events into the input layer. This is a complex case and not in the goal of getting 90% of users to just work. This remote is a typical example of the IR's that are provided together with media boards. On all such IR's I know, it does generate one key event for TV, SAT, DVB, DVD... keys and this event doesn't change the status of subsequent keys. 100% of the users of such boards will have the shipped IR. Some amount will be happy of just using the provided IR to control different applications at their computer or embedded hardware, and some amount will prefer to buy a multi-purpose IR that will allow him to control not only his computer, but also, his TV, his Air conditioning, etc. Both usages should be supported. All I'm saying is that, in the case where people have only the shipped IR, if he wants to see TV, the produced keycode will be KEY_TV, and then to change a channel, it will receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, he will press KEY_DVB and then KEY_PLAY to play his movie. So, an application like MythTV should be able to work with those keys. Eeeerrrkkk, what a .. device . For such quirky device, we could imagine a special mapping support: We could maps scancode 0x1e1c and 0x1e0c special keycode wich inform the input layer to surcharge the vendor or device with a specific value/mask for following keypresses of such remote. The mask could be choose to generate out of bound value in regards of the used protocol for the vendor or the device part to not overlap with another existing remote. Generate a complete map and so a device for each special key and you're done. No special case on the application side. In kernel states are a bit ugly, but this particular case is not too complicated and your dumb shitty remote is promoted to first class one. Regards, Emmanuel. -- 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
Re: [RFC v2] Another approach to IR
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: We should not forget that simple IR's don't have any key to select the address, so the produced codes there will never have KEY_TV/KEY_DVD, etc. Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select media inputs in a device/application. My receiver accepts codees like that. Yes, it seem that there is confusion here. Forget my proposition. It is a corner case that could be handled later if needed. Cheers, Emmanuel. -- 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
Re: [RFC v2] Another approach to IR
Jarod Wilson ja...@wilsonet.com writes: Perhaps we should clarify something here. Are we intending to auto-create a new input device for every IR command set we see arrive at the IR receiver? We don't want this, and we aren't really able to do this, because we never know if two different scan codes are part of the same or different command set. Sharing the protocol and e.g. group code doesn't mean it's the same remote. Different protocol doesn't mean it's a different remote and what's more important, doesn't mean the user wants it to be a different logical remote. -- Krzysztof Halasa -- 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
Re: [RFC v2] Another approach to IR
Mauro Carvalho Chehab mche...@redhat.com writes: 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. And it's not needed at all. Protocol decoders can be easily run in parallel, I've done it on saa713x and this is trivial at least there. Can do that when the lirc interface is available. 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. This isn't a hard thing to fix. 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. IOW any such receiver has to be tested, sure. 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. Which device requires polling the port? Most are IRQ-driven, aren't they? -- Krzysztof Halasa -- 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
Re: [RFC v2] Another approach to IR
Quoting Jon Smirl jonsm...@gmail.com: Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) From a hobbiest's perspective there's likely rarely any reason to be able to do the same thing with two different remotes that send different signals, but i could see it come up - For example if you wanted to have both a feature-rich, busy/complicated remote but also wanted to provide a simpler remote with a relatively small number of large buttons on it for basic functions, as for children or people with poor eyesight or poor motor control. From a business perspective, I've worked for a company that sold turn-key video training systems, and depending on the whims of our so-called business partners and the desires of customers, there were as many as three distinct remotes that might get shipped with the training system, and they all sent different signals. That was a less than ideal situation, and if we had been really on top of things we'd have just declined to use any of those remotes and bought custom remotes from any of the numerous vendors that sell them which would allow us to have one set of IR signals used by remotes with different features - but for whatever reason that wasn't how management decided to do things. -- 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
Re: [RFC v2] Another approach to IR
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: 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. And it's not needed at all. Protocol decoders can be easily run in parallel, I've done it on saa713x and this is trivial at least there. Can do that when the lirc interface is available. 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. This isn't a hard thing to fix. Good to know. We're open to patches to improve it. The point is that we've got in the past several complains about saa713x machines hanging due to IRQ's generated by IR sensor port. We ended by adding an option to disable IR and a code at the driver that disables IR IRQ if it happens too often. 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. IOW any such receiver has to be tested, sure. 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. Which device requires polling the port? Most are IRQ-driven, aren't they? Most of the devices that have a hardware IR decodes needs polling. Most of they simply outputs the scan code on some set of GPIO pins. In general, the devices with the IR sensor connected to a GPIO pin are IRQ-driven. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. Or, in certain cases, it can not. [... skipped rationale for adding a way to control protocol (with which I agree) ...] To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. I'm not against mapping those features as sysfs atributes, but they don't belong to lirc, as far as I understand. From all we've discussed, we'll create a lirc interface to allow the direct usage of raw IO. However, IR protocol is a property that is not related to raw IO mode but, instead, to evdev mode. Why would protocol relate to evdev node? Evdev does not really care what how the fact that a certain button was pressed was communicated to it. It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID, or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or some custom IR protocol. It makes no difference _whatsoever_ to evdev nor any users of evdev care about protocol used by underlying hardware device to transmit the data. We might add a /sys/class/IR and add IR specific stuff there, but it seems overkill to me and will hide the fact that those parameters are part of the evdev interface. So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). I agree that the code to implement the IR specific sysfs parameter should be kept oustide input core, as they're specific to IR implementations. Would this work for you? I am seeing a little bit differently structured subsystem for IR at the moment. I think we should do something like this: - receivers create /sys/class/lirc devices. These devices provide API with a ring buffer (fifo) for the raw data stream coming from (and to) them. - we allow registering several data interfaces/decoders that can be bound (manually or maybe automatically) to lirc devices. lirc devices may provide hints as to which interface(s) better suited for handling the data coming form particular receiver. Several interfaces may be bound to one device at a time. - one of the interfaces is interface implementing current lirc_dev - other interfaces may be in-kernel RC-5 decoder or other decoders. decoders will create instances of input devices (for each remote/substream that they can recognize). This way there is clear layering, protocol selection is kept at lirc level. Would this work? -- Dmitry -- 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
Re: [RFC v2] Another approach to IR
On 12/01/09 22:05, Mauro Carvalho Chehab wrote: So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). No, you add it to the physical device node. The usb mouse on the system I'm working on is here: zweiblum kraxel $ ll /sys/class/input/ | grep usb2 lrwxrwxrwx. 1 root root 0 Dec 2 12:07 event7 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 input7 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 mouse2 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/ So /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 is the device node of the physical device, and the input devices belonging to it are in the input subdirectory. If the mouse would be a usb IR receiver the IR attributes should go to /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir' subdirectory there. HTH, Gerd -- 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
Re: [RFC v2] Another approach to IR
Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. Or, in certain cases, it can not. [... skipped rationale for adding a way to control protocol (with which I agree) ...] To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. I'm not against mapping those features as sysfs atributes, but they don't belong to lirc, as far as I understand. From all we've discussed, we'll create a lirc interface to allow the direct usage of raw IO. However, IR protocol is a property that is not related to raw IO mode but, instead, to evdev mode. Why would protocol relate to evdev node? Evdev does not really care what how the fact that a certain button was pressed was communicated to it. It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID, or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or some custom IR protocol. It makes no difference _whatsoever_ to evdev nor any users of evdev care about protocol used by underlying hardware device to transmit the data. We might add a /sys/class/IR and add IR specific stuff there, but it seems overkill to me and will hide the fact that those parameters are part of the evdev interface. So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). I agree that the code to implement the IR specific sysfs parameter should be kept oustide input core, as they're specific to IR implementations. Would this work for you? I am seeing a little bit differently structured subsystem for IR at the moment. I think we should do something like this: - receivers create /sys/class/lirc devices. These devices provide API with a ring buffer (fifo) for the raw data stream coming from (and to) them. The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). - we allow registering several data interfaces/decoders that can be bound (manually or maybe automatically) to lirc devices. lirc devices may provide hints as to which interface(s) better suited for handling the data coming form particular receiver. Several interfaces may be bound to one device at a time. - one of the interfaces is interface implementing current lirc_dev - other interfaces may be in-kernel RC-5 decoder or other decoders. decoders will create instances of input devices I don't see why having more than one interface, especially for devices with hardware decoders. On IR remote receivers, internally, there's just one interface per hardware. Considering the hardware decoding case, why to artificially create other interfaces that can't be used simultaneously? No current hardware decoders can do that (or, at least, no current implementation allows). We're foreseen some cases where we'll have that (like
Re: [RFC v2] Another approach to IR
Gerd Hoffmann wrote: On 12/01/09 22:05, Mauro Carvalho Chehab wrote: So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). No, you add it to the physical device node. The usb mouse on the system I'm working on is here: zweiblum kraxel $ ll /sys/class/input/ | grep usb2 lrwxrwxrwx. 1 root root 0 Dec 2 12:07 event7 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 input7 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 mouse2 - ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/ So /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 is the device node of the physical device, and the input devices belonging to it are in the input subdirectory. If the mouse would be a usb IR receiver the IR attributes should go to /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir' subdirectory there. This makes sense to me. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote: On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. Or, in certain cases, it can not. [... skipped rationale for adding a way to control protocol (with which I agree) ...] To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. I'm not against mapping those features as sysfs atributes, but they don't belong to lirc, as far as I understand. From all we've discussed, we'll create a lirc interface to allow the direct usage of raw IO. However, IR protocol is a property that is not related to raw IO mode but, instead, to evdev mode. Why would protocol relate to evdev node? Evdev does not really care what how the fact that a certain button was pressed was communicated to it. It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID, or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or some custom IR protocol. It makes no difference _whatsoever_ to evdev nor any users of evdev care about protocol used by underlying hardware device to transmit the data. We might add a /sys/class/IR and add IR specific stuff there, but it seems overkill to me and will hide the fact that those parameters are part of the evdev interface. So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). I agree that the code to implement the IR specific sysfs parameter should be kept oustide input core, as they're specific to IR implementations. Would this work for you? I am seeing a little bit differently structured subsystem for IR at the moment. I think we should do something like this: - receivers create /sys/class/lirc devices. These devices provide API with a ring buffer (fifo) for the raw data stream coming from (and to) them. The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. - we allow registering several data interfaces/decoders that can be bound (manually or maybe automatically) to lirc devices. lirc devices may provide hints as to which interface(s) better suited for handling the data coming form particular receiver. Several interfaces may be bound to one device at a time. - one of the interfaces is interface implementing
Re: [RFC v2] Another approach to IR
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. For IR to just work the irrecord training process needs be eliminated for 90% of users. Pretty sure that's already the case. I have upwards of 20 remotes and 15 receivers. I've had to run irrecord maybe two times in five years to get any of them working. The existing lirc remote database is fairly extensive. -- Jarod Wilson ja...@redhat.com -- 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
Re: [RFC v2] Another approach to IR
Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. Ok. We need to cater to the future cases as well. I don't want to redesign it in 2 years. But for devices that have only hardware decoders I suppose we can short-curcuit interfaces and have a library-like module creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. _Yes_!!! You open as many event devices as there are devices you are interested in receiving data from. Multiplexing devices are bad, bad, bad. Witness /dev/input/mouse and all the attempts at working around the fact that if you have a special driver for one of your devices you receive events from the same device through 2 interfaces and all kind of grab, super-grab, smart-grab schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. (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. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. Ok. We need to cater to the future cases as well. I don't want to redesign it in 2 years. But for devices that have only hardware decoders I suppose we can short-curcuit interfaces and have a library-like module creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. _Yes_!!! You open as many event devices as there are devices you are interested in receiving data from. Multiplexing devices are bad, bad, bad. Witness /dev/input/mouse and all the attempts at working around the fact that if you have a special driver for one of your devices you receive events from the same device through 2 interfaces and all kind of grab, super-grab, smart-grab schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. IR devices transmit vendor/device/command triplets. They are easy to tell apart and create an evdev device corresponding to each vendor/device pair or something else along those lines. If I tell a programmable remote to send out the same commands as my Sony remote that's the same thing as owning two identical Sony remotes. I'd expect them to be indistinguishable. If you want to be able to tell your remotes apart, don't program them to emulate each other. I've published code that can split these devices apart, it's not impossible to do. 802.11 receivers have the same problem, there is one receiver and many transmitters. The networking code doesn't have problems with sorting this out and separating the streams. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. Reusing the keycode is fine if they on different evdev devices. A key feature is creating one evdev device for each remote. (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. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- 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
Re: [RFC v2] Another approach to IR
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. -- Jarod Wilson ja...@wilsonet.com -- 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
Re: [RFC v2] Another approach to IR
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. 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? 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. -- Dmitry -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl jonsm...@gmail.com wrote: On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. Ok. We need to cater to the future cases as well. I don't want to redesign it in 2 years. But for devices that have only hardware decoders I suppose we can short-curcuit interfaces and have a library-like module creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. _Yes_!!! You open as many event devices as there are devices you are interested in receiving data from. Multiplexing devices are bad, bad, bad. Witness /dev/input/mouse and all the attempts at working around the fact that if you have a special driver for one of your devices you receive events from the same device through 2 interfaces and all kind of grab, super-grab, smart-grab schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. IR devices transmit vendor/device/command triplets. They are easy to tell apart and create an evdev device corresponding to each vendor/device pair or something else along those lines. I forgot about fixed function receivers - ones that only receive codes from a specific vendor/device pair and decode them in hardware. Those devices would just create a fixed entry in the configfs which would then allow a keycode mapping to be loaded. Or a parallel scheme for setkeys IOCTL. These device can only receive from a single remote. If I tell a programmable remote to send out the same commands as my Sony remote that's the same thing as owning two identical Sony remotes. I'd expect them to be indistinguishable. If you want to be able to tell your remotes apart, don't program them to emulate each other. I've published code that can split these devices apart, it's not impossible to do. 802.11 receivers have the same problem, there is one receiver and many transmitters. The networking code doesn't have problems with sorting this out and separating the streams. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. Reusing the keycode is fine if they on different evdev devices. A key feature is creating one evdev device for each remote. (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. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- Jon Smirl jonsm...@gmail.com -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 05:33:34PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to lirc_dev interface. Ok. We need to cater to the future cases as well. I don't want to redesign it in 2 years. But for devices that have only hardware decoders I suppose we can short-curcuit interfaces and have a library-like module creating input devices directly. We really need only one interface for those devices. However, protocol selection is needed, as it is associated with the scantable on those devices. a sysfs entry would solve this issue. Also, we need a better schema to cleanup the keycode table. Currently, the only way I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or to KEY_RESERVED. I guess we could entertain EVIOCSKMAPFLUSH or something... In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. _Yes_!!! You open as many event devices as there are devices you are interested in receiving data from. Multiplexing devices are bad, bad, bad. Witness /dev/input/mouse and all the attempts at working around the fact that if you have a special driver for one of your devices you receive events from the same device through 2 interfaces and all kind of grab, super-grab, smart-grab schemes are born. The only device that the driver can actually see is the IR receiver. There's no way to know if there is only one physical IR sending signals to it or several different models, especially if we consider that programmable IR's can be able even to generate more than one protocol at the same time, and can emulate other IR types. You might create some artificial schema to try to deal with different IR's being received at the same IR receiver, but, IMHO, this will just add a complex abstraction layer. Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you can handle it differently. No it will. User will have _an option_ of assigning a particular remote to a particular application. Whether he or she will chose to entertain this option is up to that user. (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. -ENOOPINION at the moment. -- Dmitry -- 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
Re: [RFC v2] Another approach to IR
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. 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. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) -- Jarod Wilson ja...@wilsonet.com -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson 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. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. 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. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? -- Dmitry -- 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
Re: [RFC v2] Another approach to IR
Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson 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. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. 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. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? From what I understood, he is using the same physical remote, but creating different IR groups of keys on it, each group meant to be used by a different application. For such usage, some software will need to filter the scancode group and send them only for a certain application. This can be done easily by using lirc, purely in userspace. Another alternative (that will also work for multimedia keys on a keyboard) is to add a filtering subsystem at evdev that will send certain events for just certain PID's. Of course, it is feasible to do it in kernel, but, IMHO, it would be better to let userspace to take care of this. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson 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. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. Semantics. :) My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. 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. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? Yes. But that's an atypical usage, in my experience, and as Mauro said, something that can be done trivially in userspace (lirc can do this today, even for the same remote and mode of operation, on a per-key basis if you want). If it doesn't add too much complexity and people will actually use it, I don't have a problem with implementing one input device per distinct remote, but I doubt many people would use that functionality. -- Jarod Wilson ja...@wilsonet.com -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 03:42:13PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson 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. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. Semantics. :) My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back at ya ;) The fact that you need to do some more work to separate 2 physical devices does not mean it should not be done. -- Dmitry -- 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
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: IR devices transmit vendor/device/command triplets. They are easy to tell apart and create an evdev device corresponding to each vendor/device pair or something else along those lines. What they transmit depend on the used protocol. With NEC and RC5 (currently, the most common protocols), they transmit only address (TV, VCR, SAT) and command. If you have two IR's that not fully follow RC5 standard, they may use distinct addresses. So, if you're lucky enough, you'll be able to guess the IR vendor, based on the 8 bit address code. I think that you can get the vendor only with RC6 IR's on some modes. In the case of RC6, as pointed by Andy, there are some patents envolved, meaning that we probably will need to decode it on userspace, except if someone can get the proper patent rights for its used on Linux. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson 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. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? From what I understood, he is using the same physical remote, but creating different IR groups of keys on it, each group meant to be used by a different application. For such usage, some software will need to filter the scancode group and send them only for a certain application. This can be done easily by using lirc, purely in userspace. Another alternative (that will also work for multimedia keys on a keyboard) is to add a filtering subsystem at evdev that will send certain events for just certain PID's. 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. However even subscription is something that is desirable to have ouside of IRC handling topic (so that supporting applications need not be woken up by events they are not interested in - example mixer application is interested in KEY_VOLUMEUP, KEY_VOLUMEDOWN and KEY_MUTE but not any other key that may be emitted by a keyboard). -- Dmitry -- 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
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: Some major use cases: using IR as a keyboard replacement, controlling X and apps with it in via mouse and keyboard emulation. using IR to control a headless embedded device possibly running multiple apps - like audio and home automation (my app) IR during boot when it is the only input device the box has. multifunction remote controlling several apps using several different remotes to control a single app I think you reasonably described the major usecases. If everyone hates configfs the same mapping can be done via the set keys IOCTL and making changes to the user space apps like loadkeys. It is not the hate of configfs per se, but rather concern that configfs takes too much resources and is not normally enabled. It adds about 35K on 64b x86. 30K on 32b powerpc. If it gets turned on by default other subsystems might start using it too. I work on an embedded system. These arguments about non-swapable vs swapable are pointless. Embedded systems don't have swap devices. Of course config can be eliminated by modifying the setkeys IOCTL and user space tools. It will require some more mods to input to allow multiple maps monitoring the input stream and splitting them onto multiple evdev devices. This is an equally valid way of building the maps. The code I posted is just demo code. It is clearly not in shape to be merged. Its purpose was to spark a design discussion around creating a good long-term architecture for IR. Unfortunately, afaik, most distros don't enable configfs yet. I have to manually compile my kernel when I need some useful stuff there. I agree with Dmitry: IR is probably not enough to have this enabled by default on distros. I prefer a more traditional approach like ioctls (and/or sysfs) instead of configfs. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Dec 2, 2009, at 3:48 PM, Dmitry Torokhov wrote: ... 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. Not exactly... I can have 2 identical USB keyboadrs form the same manufacturer and they will still be treated separately. BT has session ID to help distinguish between devices. Semantics. :) My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back at ya ;) The fact that you need to do some more work to separate 2 physical devices does not mean it should not be done. No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work. -- Jarod Wilson ja...@wilsonet.com -- 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
Re: [RFC v2] Another approach to IR
On Wed, 2 Dec 2009, Jarod Wilson wrote: My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back at ya ;) The fact that you need to do some more work to separate 2 physical devices does not mean it should not be done. No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work. You just need to send a tuple that contrains the keycode plus some kind of id for the remote it came from. That's what I did for lirc, it decodes the sparc/mark into a remote id and key code tuple. It's certainly a common thing to want. Anyone who has existing remotes and components that use them would want it. You don't want your computer turning off when you push the power button on the DVD player's remote, do you? Each host connected to a network interface doesn't get its own device. -- 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
Re: [RFC v2] Another approach to IR
Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson 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. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? From what I understood, he is using the same physical remote, but creating different IR groups of keys on it, each group meant to be used by a different application. For such usage, some software will need to filter the scancode group and send them only for a certain application. This can be done easily by using lirc, purely in userspace. Another alternative (that will also work for multimedia keys on a keyboard) is to add a filtering subsystem at evdev that will send certain events for just certain PID's. 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. So, the needed feature is not to really distinguish two different IR's, but to allow to create groups of scancodes that will be directed to a distinct interface. I won't object about such interface, but the default should be to have just one interface and having all conversion applied to that interface. Maybe we can have a separate module for IR evdev filtering to fulfill this need. Basically, such module will get the events from one input interface and create an arbitrary number of evdev devices, and will apply different scancode-keycode tables for each different interfaces. I don't see why to limit the input interface to be IR. It can eventually be any input interface (bluetooth, keyboard, PS/3 control, Wii control, ...). Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote: On Wed, 2 Dec 2009, Jarod Wilson wrote: My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back at ya ;) The fact that you need to do some more work to separate 2 physical devices does not mean it should not be done. No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work. You just need to send a tuple that contrains the keycode plus some kind of id for the remote it came from. That's what I did for lirc, it decodes the sparc/mark into a remote id and key code tuple. It's certainly a common thing to want. Anyone who has existing remotes and components that use them would want it. What for, exactly? You don't want your computer turning off when you push the power button on the DVD player's remote, do you? No, I don't. Perhaps we should clarify something here. Are we intending to auto-create a new input device for every IR command set we see arrive at the IR receiver? I've been assuming we're not going to willy-nilly just auto-create a new device for every IR signal we happen to catch passing by. The receiver should only be passing along input events for the codeset/remote I've told it to listen for (which by default, is the codes for the receiver's bundled remote). Otherwise, yeah, I'm going to wind up with my htpc powering off when I hit the button on my harmony remote that is supposed to turn off my tv and amp. -- Jarod Wilson ja...@wilsonet.com -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@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. Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) -- Jarod Wilson ja...@wilsonet.com -- Jon Smirl jonsm...@gmail.com -- 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
Re: [RFC v2] Another approach to IR
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. 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
Re: [RFC v2] Another approach to IR
On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? There are a few features that can be used to distinguish remotes: 1. Carrier freq 2. Protocol (NEC, Sony, JVC, RC-5...) 3. Protocol variant (NEC original, NEC with extended addresses, RC-5, RC-5 with exteneded commands, RC-6 Mode 0, RC-6 Mode 6B, ...) 4. System # or Address sent by the remote (16 bits max, I think) 5. Set of possible Commands or Information words sent from the remote. 6. Pulse width deviation from standard (mean, variance) 1, 5, and 6 are really a sort of fingerprint and likely not worth the effort, even if you have hardware that can measure things with some accuracy. 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
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@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. Do you have any info on how they're encoded? Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
Am Mittwoch, den 02.12.2009, 20:19 -0500 schrieb Andy Walls: On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications can be controlled without interfering with each other? There are a few features that can be used to distinguish remotes: 1. Carrier freq 2. Protocol (NEC, Sony, JVC, RC-5...) 3. Protocol variant (NEC original, NEC with extended addresses, RC-5, RC-5 with exteneded commands, RC-6 Mode 0, RC-6 Mode 6B, ...) 4. System # or Address sent by the remote (16 bits max, I think) 5. Set of possible Commands or Information words sent from the remote. 6. Pulse width deviation from standard (mean, variance) 1, 5, and 6 are really a sort of fingerprint and likely not worth the effort, even if you have hardware that can measure things with some accuracy. I don't follow closely enough, but eventually we have (different) remotes a receiver chip can distinguish in hardware, firmware might be involved too. If I don't get it wrong, Dmitry is asking in the first place, how such sender receiver combinations switch to different emulated digital information for a bunch of different types of hardware in living rooms. Starting with RC5, IIRC, there is of course such switch over to another device around. We are only one more. To repeat, on such bundled cheapest remotes with some TV/DVB cards around, there are only some minimal implementations of RC5, likely they use that protocol even illegally, at least they make chips in use unidentifiable and this seems to be by will. So, if some try to implement now the highest level, they are far away from to know what hardware goes how far with them. At least fun to see they have some starting point ;) Cheers, Hermann -- 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
Re: [RFC v2] Another approach to IR
On Wed, 2 Dec 2009, Jon Smirl wrote: 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. *All* remotes? That's a bold statement. I'm sure there are some that only transmit 8 bits of so of scancode. I think remotes are more like hosts on a network than usb or bluetooth devices. Remotes do not join or leave a receiver, while things like usb devices do explictly join and leave the hub. Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. -- 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
Re: [RFC v2] Another approach to IR
On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: ... Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Okay, in the above scenario, you've still got a single input device... Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per remote though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...). It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one. Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it. -- Jarod Wilson ja...@wilsonet.com -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@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. 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. 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. -- Jon Smirl jonsm...@gmail.com -- 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
Re: [RFC v2] Another approach to IR
On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: ... Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Okay, in the above scenario, you've still got a single input device... Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per remote though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...). It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one. Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it. Simple use case: You have a multifunction remote. Press the CABLE key - it sends out commands that control the cable box, press the TV key - now the commands control the TV, press CD - now the CD player, etc. Now imagine a headless Linux box running a music server and a home automation app. Press the CD key - commands get routed to the music server, press the AUX key - commands get routed to the home automation app. This is accomplished by recognizing the device code part of the IR signal and figuring out that there are two different device codes in use. The commands of then routed to two evdev devices corresponding to the two different device codes. Using things like Alt-Tab to switch apps is impossible. There's no screen to look at. -- Jarod Wilson ja...@wilsonet.com -- Jon Smirl jonsm...@gmail.com -- 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
[RFC v2] Another approach to IR
While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. Of course there are details involved in making this work. MythTV will have to have a config option to allow it to emulate several different DVR devices so that you can pick one that you don't own. It should also have choices for emulating the common devices defined for the remotes included with various Linux video board like the Hauppauge remote. For apps that haven't been modified you will have to run a daemon which will capture vendor/device/command evdev events and convert them into keystroke commands than work the menus. You'll need a config file for this and have to write scripts. Instead I'd just go modify the app the respond to the IR events, it is easy to do. Long run, we define a MythTV IR profile, mplayer profile, etc and get these into the IR database for universal remotes. Now MythTV can stop emulating another vendor's device. For the default MythTV case no external support will need to be installed if the protocol decode engines are in the kernel. The raw data will come in, run through the engines, and pop out as evdev messages with a vendor/device/command triplet. Devices that decode in hardware will just send vendor/device/command triplets. -- Jon Smirl jonsm...@gmail.com -- 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
Re: [RFC v2] Another approach to IR
On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. Of course there are details involved in making this work. MythTV will have to have a config option to allow it to emulate several different DVR devices so that you can pick one that you don't own. It should also have choices for emulating the common devices defined for the remotes included with various Linux video board like the Hauppauge remote. For apps that haven't been modified you will have to run a daemon which will capture vendor/device/command evdev events and convert them into keystroke commands than work the menus. You'll need a config file for this and have to write scripts. Instead I'd just go modify the app the respond to the IR events, it is easy to do. Long run, we define a MythTV IR profile, mplayer profile, etc and get these into the IR database for universal remotes. Now MythTV can stop emulating another vendor's device. For the default MythTV case no external support will need to be installed if the protocol decode engines are in the kernel. The raw data will come in, run through the engines, and pop out as evdev messages with a vendor/device/command triplet. Devices that decode in hardware will just send vendor/device/command triplets. -- 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
Re: [RFC v2] Another approach to IR
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. So let's try and figure out a just works scheme for doing this. What I'm trying to do is to get everyone to step back and think about this problem instead of rushing head long into merging LIRC as is. irrecord is not something a non-technical user can easily handle. A basic scheme that can be used to eliminate configuration is to take well known IR device profiles and emulate them in Linux. So pick another well known device to emulate (call it A) and map it to mouse/keyboard events. Mapping vendor/device/command codes for a couple devices to mouse/keyboard events is a tiny amount of data and can be done in-kernel. This case could also be made to just work. Set your universal remote to device A. Commands from for device A will arrive and be mapped into generic keyboard/mouse commands. There are probably other solutions to making IR work without needing irrecord and configuration. What would be some other possibilities? Also consider the long term strategy of defining standard device profiles and getting them into the IR database. Make an IR profile for mouse/keyboard. After this gets into the database a universal remote can be set to this profile which will be a better match than emulating another device. Of course there are details involved in making this work. MythTV will have to have a config option to allow it to emulate several different DVR devices so that you can pick one that you don't own. It should also have choices for emulating the common devices defined for the remotes included with various Linux video board like the Hauppauge remote. For apps that haven't been modified you will have to run a daemon which will capture vendor/device/command evdev events and convert them into keystroke commands than work the menus. You'll need a config file for this and have to write scripts. Instead I'd just go modify the app the respond to the IR events, it is easy to do. Long run, we define a MythTV IR profile, mplayer profile, etc and get these into the IR database for universal remotes. Now MythTV can stop emulating another vendor's device. For the default MythTV case no external support will need to be installed if the protocol decode engines are in the kernel. The raw data will come in, run through the engines, and pop out as evdev messages with a vendor/device/command triplet. Devices that decode in hardware will just send vendor/device/command triplets. -- Jon Smirl jonsm...@gmail.com -- 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
Re: [RFC v2] Another approach to IR
Hi Jon, Jon Smirl wrote: On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. So let's try and figure out a just works scheme for doing this. What I'm trying to do is to get everyone to step back and think about this problem instead of rushing head long into merging LIRC as is. irrecord is not something a non-technical user can easily handle. A basic scheme that can be used to eliminate configuration is to take well known IR device profiles and emulate them in Linux. So pick another well known device to emulate (call it A) and map it to mouse/keyboard events. Mapping vendor/device/command codes for a couple devices to mouse/keyboard events is a tiny amount of data and can be done in-kernel. This case could also be made to just work. Set your universal remote to device A. Commands from for device A will arrive and be mapped into generic keyboard/mouse commands. There are probably other solutions to making IR work without needing irrecord and configuration. What would be some other possibilities? Also consider the long term strategy of defining standard device profiles and getting them into the IR database. Make an IR profile for mouse/keyboard. After this gets into the database a universal remote can be set to this profile which will be a better match than emulating another device. This is basically the way the current in-kernel IR drivers work. The driver converts scancodes (device address/command sequence) into an evdev standard code. Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): # SCAN Key_code # 0xeb13 KEY_RIGHT 0x1e17 KEY_RIGHT 0x1d17 KEY_RIGHT 0x860f KEY_RIGHT 0xeb11 KEY_LEFT 0x1e16 KEY_LEFT 0x1d16 KEY_LEFT 0x860e KEY_LEFT 0x0703 KEY_VOLUMEUP 0xeb1c KEY_VOLUMEUP 0x1e10 KEY_VOLUMEUP 0x037d KEY_VOLUMEUP 0x1d10 KEY_VOLUMEUP 0x8610 KEY_VOLUMEUP 0x7a12 KEY_VOLUMEUP 0x0709 KEY_VOLUMEDOWN 0xeb1e KEY_VOLUMEDOWN 0x1e11 KEY_VOLUMEDOWN 0x017d KEY_VOLUMEDOWN 0x1d11 KEY_VOLUMEDOWN 0x860c KEY_VOLUMEDOWN 0x7a13 KEY_VOLUMEDOWN 0x0706 KEY_CHANNELUP 0xeb1b KEY_CHANNELUP 0x1e20 KEY_CHANNELUP 0x0242 KEY_CHANNELUP 0x1d20 KEY_CHANNELUP 0x860d KEY_CHANNELUP 0x7a10 KEY_CHANNELUP 0x070c KEY_CHANNELDOWN 0xeb1f KEY_CHANNELDOWN 0x1e21 KEY_CHANNELDOWN 0x007d KEY_CHANNELDOWN 0x1d21 KEY_CHANNELDOWN 0x8619 KEY_CHANNELDOWN 0x7a11 KEY_CHANNELDOWN It should be noticed, however, that some devices may be provided with a shipped IR with a different keytable where the keycodes may overlap with this table. So, what we can do is to have a default keycode table mapping several different IR's there to be used by drivers that are shipped with an IR that can be fully mapped by the default table. However, for devices with scancodes that overlaps with the default table, we'll need a separate table. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): Mauro, Just to be clear, the dib0700 does not actually support receiving RC5 or NEC codes at the same time. You have to tell the chip which mode to operate in, via a REQUEST_SET_RC to the firmware (see dib0700_core.c:405). The em28xx works the same way (you have to tell it what type of IR format to receive). The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
Re: [RFC v2] Another approach to IR
Hi, On Tue, 1 Dec 2009, Devin Heitmueller wrote: On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): Mauro, Just to be clear, the dib0700 does not actually support receiving RC5 or NEC codes at the same time. You have to tell the chip which mode to operate in, via a REQUEST_SET_RC to the firmware (see dib0700_core.c:405). The em28xx works the same way (you have to tell it what type of IR format to receive). The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. I did not follow all the discussion, still I have a comment: I will soon work on a device where it is the driver who is doing the decoding of the IR-frames. It is (maybe, I'm still missing some pieces to be sure) possible to receive different protocols at the same time with this hardware. -- Patrick http://www.kernellabs.com/ -- 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
Re: [RFC v2] Another approach to IR
Maxim Levitsky wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. +1. I also use the remote as a keyboard replacement. I used an IR like that for a long time while teaching, using a standard USB video board, as a way to remotely control my notebook. Well, now I have an USB IR for this usage, using HID, that emulates both keyboard and mouse. In fact, the application didn't change. I'm just using the standard USB class for HID, instead of using vendor class to generate the same kind of evdev events ;) Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
Patrick Boettcher wrote: The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. I did not follow all the discussion, still I have a comment: I will soon work on a device where it is the driver who is doing the decoding of the IR-frames. It is (maybe, I'm still missing some pieces to be sure) possible to receive different protocols at the same time with this hardware. That's good news! Needing to pass a modprobe parameter to select the protocol is not nice, and, while an ioctl will be needed to select IR protocols (as there are some hardwares where this is not possible at all), the better is to auto-detect the protocol. Cheers, Mauro. -- 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
Re: [RFC v2] Another approach to IR
On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Due to the lack of an API for it, each driver has their own way to handle the protocols, but basically, on almost all drivers, even supporting different protocols, the driver limits the usage of just the protocol provided by the shipped remote. To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. evdev capabilities bits can support enumerating the supported protocols. I'm not sure if you can write those bits back into evdev to turn a feature off/on. If not its something that could be added to evdev. I agree that there is no consistency in the existing driver implementations. -- Jon Smirl jonsm...@gmail.com -- 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
Re: [RFC v2] Another approach to IR
On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. Or, in certain cases, it can not. [... skipped rationale for adding a way to control protocol (with which I agree) ...] To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. -- Dmitry -- 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
