Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/25/09 19:20, Devin Heitmueller wrote: On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilsonja...@wilsonet.com wrote: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. I think at the end of the day we'll want to have all IR drivers use the same interface. The way the current in-kernel input layer drivers work obviously isn't perfect too, so we *must* consider both worlds to get a good solution for long-term ... This is one of the key use cases I would be very concerned with. For many users who have bought tuner products, the bundled remotes work out-of-the-box, regardless of whether lircd is installed. I bet this simply isn't going to change. I have no objection so much as to saying well, you have to install the lircd service now, but there needs to be a way for the driver to automatically tell lirc what the default remote control should be, to avoid a regression in functionality. *Requiring* lircd for the current in-kernel drivers doesn't make sense at all. Allowing lircd being used so it can do some more advanced stuff makes sense though. This is why I think we really should put together a list of use cases, so that we can see how any given proposal addresses those use cases. I offered to do such, but nobody seemed really interested in this. Lets have a look at the problems the current input layer bits have compared to lirc: (1) ir code (say rc5) - keycode conversion looses information. I think this can easily be addressed by adding a IR event type to the input layer, which could look like this: input_event-type = EV_IR input_event-code = IR_RC5 input_event-value = rc5 value In case the 32bit value is too small we might want send two events instead, with -code being set to IR_code_1 and IR_code_2 Advantages: * Applications (including lircd) can get access to the unmodified rc5/rc6/... codes. * All the ir-code - keycode mapping magic can be handled by the core input layer then. All the driver needs to do is to pass on the information which keymap should be loaded by default (for the bundled remote if any). The configuration can happen in userspace (sysfs attribute + udev + small utility in tools/ir/). * lirc drivers which get ir codes from the hardware can be converted to pure input layer drivers without regressions. lircd is not required any more. (2) input layer doesn't give access to the raw samples. Not sure how to deal with that best. Passing them through the input layer would certainly be possible to hack up. But what would be the point? The input layer wouldn't do any processing on them. It wouldn't buy us much. So we might want to simply stick with todays lirc interface for the raw samples. Drivers which support both ir codes (be it by hardware or by in-kernel decoding) and raw samples would register two devices then, one input device and one lirc device. It would probably a good idea to stop sending events to the input layer as soon as someone (most likely lircd) opens the lirc device to avoid keystrokes showing up twice. By default the in-kernel bits will be at work, but optionally you can have lircd grab the raw samples and do fancy advanced decoding. (3) input layer doesn't allow transmitting IR codes. If we keep the lirc interface for raw samples anyway, then we can keep it for sending too, problem solved ;) How does sending hardware work btw? Do they all accept just raw samples? Or does some hardware also accept ir-codes? cheers, 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Gerd, on 25 Nov 09 at 22:58, Gerd Hoffmann wrote: [...] (1) ir code (say rc5) - keycode conversion looses information. I think this can easily be addressed by adding a IR event type to the input layer, which could look like this: input_event-type = EV_IR input_event-code = IR_RC5 input_event-value = rc5 value In case the 32bit value is too small we might want send two events instead, with -code being set to IR_code_1 and IR_code_2 Advantages: * Applications (including lircd) can get access to the unmodified rc5/rc6/... codes. Unfortunately with most hardware decoders the code that you get is only remotely related to the actual code sent. Most RC-5 decoders strip off start bits. Toggle-bits are thrown away. NEC decoders usually don't pass through the address part. Some even generate some pseudo-random code (Irman). There is no common standard which bit is sent first, LSB or MSB. Checksums are thrown away. To sum it up: I don't think this information will be useful at all for lircd or anyone else. Actually lircd does not even know anything about actual protocols. We only distinguish between certain protocol types, like Manchester encoded, space encoded, pulse encoded etc. Everything else like the actual timing is fully configurable. [...] If we keep the lirc interface for raw samples anyway, then we can keep it for sending too, problem solved ;) How does sending hardware work btw? Do they all accept just raw samples? Or does some hardware also accept ir-codes? Usually raw samples in some form. I've never seen any device that would accept just ir-codes. UIRT2 devices have some more advanced modes but also accept raw samples. Christoph -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
(1) ir code (say rc5) - keycode conversion looses information. I think this can easily be addressed by adding a IR event type to the input layer, which could look like this: input_event-type = EV_IR input_event-code = IR_RC5 input_event-value =rc5 value In case the 32bit value is too small we might want send two events instead, with -code being set to IR_code_1 and IR_code_2 Advantages: * Applications (including lircd) can get access to the unmodified rc5/rc6/... codes. Unfortunately with most hardware decoders the code that you get is only remotely related to the actual code sent. Most RC-5 decoders strip off start bits. I would include only the actual data bits in the payload anyway. Toggle-bits are thrown away. NEC decoders usually don't pass through the address part. Too bad. But information which isn't provided by the hardware can't be passed up anyway, no matter what kernel/userspace interface is used. Gone is gone. There is no common standard which bit is sent first, LSB or MSB. Input layer would have to define a bit order. And drivers which get it the other way from the hardware have to convert. Or maybe signal the order and the input core then will convert if needed. Checksums are thrown away. Don't include them. To sum it up: I don't think this information will be useful at all for lircd or anyone else. Why not? With RC5 remotes applications can get the device address bits for example, which right now are simply get lost in the ir code - keycode conversion step. Actually lircd does not even know anything about actual protocols. We only distinguish between certain protocol types, like Manchester encoded, space encoded, pulse encoded etc. Everything else like the actual timing is fully configurable. I know that lircd does matching instead of decoding, which allows to handle unknown encodings. Thats why I think there will always be cases which only lircd will be able to handle (using raw samples). That doesn't make attempts to actually decode the IR samples a useless exercise though ;) cheers, 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote: On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I'm not sure what two ways you are talking about. With the patches posted by Jarod, nothing has to be changed in userspace. Everything works, no code needs to be written and tested, everybody is happy. The existing drivers use input layer. Do you want part of the tree to use existing lirc interface while the other part uses their own in-kernel (badly broken for example) code to do precisely the same thing? Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. It has been on mine. I have been somewhat against the input subsystem route for unification because it neglects transmitters and appears to trade the userspace complexity we already have (i.e. LIRC configuration) for another new (and hence less documented) configuration complexity for end users. My strategy for unification goes something like this: 1. Get lirc_dev and the needed supporting headers in the kernel. I will concede LIRC is not perfect or beautiful, but I'll assert it is feature complete for all the end user use cases that matter. 2. Encapsulate all the various IR controller hardware handling in V4L-DVB into v4l_subdevice objects and provide a uniform interface to IR hardware internally via v4l2_subdev_ir_ops. The exact nature of the IR hardware is then mostly abstracted away: I2C bus microcontroller, register block, GPIO line control of discretes devices, etc. can all be accessed in a somewhat unifrom manner. 3. In conjunction with 2, common IR handling routines that exist in various drivers already can be broken out: RC-5 protocol handling, etc. 4. Develop an internal interface so the v4l2_subdev object instance for the IR hardware is exposed through a bridge driver's v4l2_device object. 5. Develop the needed layer between lirc_dev and the v4l2_device object to connect things up. That unifies all the IR cats and dogs in V4L-DVB at the low levels and glues them in a consistent manner to something up top (i.e. lirc_dev) that already handles Rx, Tx, protocols, keymapping, etc. My primary desire is to encapsulate or remove the complexity we currently have in kernel with all the ad-hoc IR hardware handling and get it unifrom and layered. The upper level glue to userspace doesn't have to be lirc_dev, but why not? It's there and the end users are familiair with it. I have set-top boxes, I need IR Tx. We can have a good code for both, or we can end up with badly broken media drivers and incompatible, suboptimal existing lirc interface (though most probably much better in terms of quality, especially after Jarod's work). Well, is there any reason most of those drivers with currently-in-kernel-but-badly-broken decoding can't be converted to use the lirc interface if its merged into the kernel? I think all the V4L-DVB IR hardware can be. I have not done sufficient research on the Serial, USB and other devices to say personally. And/or, everything could converge on a new in-kernel decoding infra that wasn't badly broken. Sure, there may be two separate ways of doing essentially the same thing for a while, but meh. The lirc way works NOW for an incredibly wide variety of receivers, transmitters, IR protocols, etc. Also LIRC has had years of requirements collection and refinement of use cases. Anything new implementation will likely end up converging to the feature set LIRC already has implemented. I do concur that Just Works decoding for bundled remotes w/o having to configure anything would be nice, and one way to go about doing that certainly is via in-kernel IR decoding. But at the same time, the second you want to use something other than a bundled remote, things fall down, and having to do a bunch of setkeycode ops seems less optimal than simply dropping an appropriate lircd.conf in place. From a big picture perspective I would never see the OS kenrel as a good place to address usability issues. It seems more logical to fix usability issues with a decent GUI application and good documentation. (LIRC needs a configuration GUI!). Expecting IR usability problems to be eased by the kernel and command line utilties is - well - optimistic. I'll add that there are too many factors that can be permuted by the end user and OEM -- protocols, remote layouts, button codes, PC IR Rx/Tx hardware, and Set top boxes feeding PC video capture devices -- that generating defaults that Just Work is a generally unsolvable problem. 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
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Wed, 2009-11-25 at 13:20 -0500, Devin Heitmueller wrote: On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson ja...@wilsonet.com wrote: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. This is one of the key use cases I would be very concerned with. For many users who have bought tuner products, the bundled remotes work out-of-the-box, regardless of whether lircd is installed. I have no objection so much as to saying well, you have to install the lircd service now, but there needs to be a way for the driver to automatically tell lirc what the default remote control should be, to avoid a regression in functionality. We cannot go from a mode where it worked automatically to a mode where now inexperienced users now have to deal with the guts of getting lircd properly configured. If such an interface were available, I would see to it that at least all the devices I have added RC support for will continue to work (converting the in-kernel RC profiles to lirc RC profiles as needed and doing the associations with the driver). The other key thing I don't think we have given much thought to is the fact that in many tuners, the hardware does RC decoding and just returns NEC/RC5/RC6 codes. And in many of those cases, the hardware has to be configured to know what format to receive. We probably need some kernel API such that the hardware can tell lirc what formats are supported, and another API call to tell the hardware which mode to operate in. Please think about how we would need to augment the v4l_subdev_ir_ops: http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l246 http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l305 http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l27 I think encapsulation of the various IR devices under V4L-DVB into v4l_subdevices can facilitate your suggestions. The CX23888 IR subdevice code configures itself to a single default setup for Tx and Rx: http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23888-ir.c#l1192 http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23888-ir.c#l1211 but there isn't a reason V4L2 IR subdevices couldn't configure to a per product defaults based on information about the detected card from the main bridge driver code. Regards, Andy This is why I think we really should put together a list of use cases, so that we can see how any given proposal addresses those use cases. I offered to do such, but nobody seemed really interested in this. Devin -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Am Mittwoch, den 25.11.2009, 22:31 -0500 schrieb Andy Walls: On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote: On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I'm not sure what two ways you are talking about. With the patches posted by Jarod, nothing has to be changed in userspace. Everything works, no code needs to be written and tested, everybody is happy. The existing drivers use input layer. Do you want part of the tree to use existing lirc interface while the other part uses their own in-kernel (badly broken for example) code to do precisely the same thing? Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. It has been on mine. I have been somewhat against the input subsystem route for unification because it neglects transmitters and appears to trade the userspace complexity we already have (i.e. LIRC configuration) for another new (and hence less documented) configuration complexity for end users. My strategy for unification goes something like this: 1. Get lirc_dev and the needed supporting headers in the kernel. I will concede LIRC is not perfect or beautiful, but I'll assert it is feature complete for all the end user use cases that matter. 2. Encapsulate all the various IR controller hardware handling in V4L-DVB into v4l_subdevice objects and provide a uniform interface to IR hardware internally via v4l2_subdev_ir_ops. The exact nature of the IR hardware is then mostly abstracted away: I2C bus microcontroller, register block, GPIO line control of discretes devices, etc. can all be accessed in a somewhat unifrom manner. 3. In conjunction with 2, common IR handling routines that exist in various drivers already can be broken out: RC-5 protocol handling, etc. 4. Develop an internal interface so the v4l2_subdev object instance for the IR hardware is exposed through a bridge driver's v4l2_device object. 5. Develop the needed layer between lirc_dev and the v4l2_device object to connect things up. That unifies all the IR cats and dogs in V4L-DVB at the low levels and glues them in a consistent manner to something up top (i.e. lirc_dev) that already handles Rx, Tx, protocols, keymapping, etc. My primary desire is to encapsulate or remove the complexity we currently have in kernel with all the ad-hoc IR hardware handling and get it unifrom and layered. The upper level glue to userspace doesn't have to be lirc_dev, but why not? It's there and the end users are familiair with it. I have set-top boxes, I need IR Tx. We can have a good code for both, or we can end up with badly broken media drivers and incompatible, suboptimal existing lirc interface (though most probably much better in terms of quality, especially after Jarod's work). Well, is there any reason most of those drivers with currently-in-kernel-but-badly-broken decoding can't be converted to use the lirc interface if its merged into the kernel? I think all the V4L-DVB IR hardware can be. I have not done sufficient research on the Serial, USB and other devices to say personally. And/or, everything could converge on a new in-kernel decoding infra that wasn't badly broken. Sure, there may be two separate ways of doing essentially the same thing for a while, but meh. The lirc way works NOW for an incredibly wide variety of receivers, transmitters, IR protocols, etc. Also LIRC has had years of requirements collection and refinement of use cases. Anything new implementation will likely end up converging to the feature set LIRC already has implemented. I do concur that Just Works decoding for bundled remotes w/o having to configure anything would be nice, and one way to go about doing that certainly is via in-kernel IR decoding. But at the same time, the second you want to use something other than a bundled remote, things fall down, and having to do a bunch of setkeycode ops seems less optimal than simply dropping an appropriate lircd.conf in place. From a big picture perspective I would never see the OS kenrel as a good place to address usability issues. It seems more logical to fix usability issues with a decent GUI application and good documentation. (LIRC needs a configuration GUI!). Expecting IR usability problems to be eased by the kernel and command line utilties is - well - optimistic. I'll add that there are too many factors that can be permuted by the end user and OEM -- protocols, remote layouts, button codes, PC IR Rx/Tx hardware, and Set top boxes feeding PC video capture devices -- that generating defaults that Just Work is a
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Wed, 2009-11-25 at 22:58 +0100, Gerd Hoffmann wrote: On 11/25/09 19:20, Devin Heitmueller wrote: On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilsonja...@wilsonet.com wrote: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. I think at the end of the day we'll want to have all IR drivers use the same interface. The way the current in-kernel input layer drivers work obviously isn't perfect too, so we *must* consider both worlds to get a good solution for long-term ... This is one of the key use cases I would be very concerned with. For many users who have bought tuner products, the bundled remotes work out-of-the-box, regardless of whether lircd is installed. I bet this simply isn't going to change. I have no objection so much as to saying well, you have to install the lircd service now, but there needs to be a way for the driver to automatically tell lirc what the default remote control should be, to avoid a regression in functionality. *Requiring* lircd for the current in-kernel drivers doesn't make sense at all. Allowing lircd being used so it can do some more advanced stuff makes sense though. This is why I think we really should put together a list of use cases, so that we can see how any given proposal addresses those use cases. I offered to do such, but nobody seemed really interested in this. Lets have a look at the problems the current input layer bits have compared to lirc: (1) ir code (say rc5) - keycode conversion looses information. I think this can easily be addressed by adding a IR event type to the input layer, which could look like this: input_event-type = EV_IR input_event-code = IR_RC5 input_event-value = rc5 value In case the 32bit value is too small we might want send two events instead, with -code being set to IR_code_1 and IR_code_2 RC-6 Mode 6A can be up to 67 bits: http://www.picbasic.nl/frameload_uk.htm?http://www.picbasic.nl/rc5-rc6_transceiver_uk.htm (This page is slightly wrong, there is some data coded in the header such as the RC-6 Mode, but I can't remeber if it's biphase or not.) Advantages: * Applications (including lircd) can get access to the unmodified rc5/rc6/... codes. * All the ir-code - keycode mapping magic can be handled by the core input layer then. All the driver needs to do is to pass on the information which keymap should be loaded by default (for the bundled remote if any). The configuration can happen in userspace (sysfs attribute + udev + small utility in tools/ir/). * lirc drivers which get ir codes from the hardware can be converted to pure input layer drivers without regressions. lircd is not required any more. (2) input layer doesn't give access to the raw samples. Not sure how to deal with that best. Passing them through the input layer would certainly be possible to hack up. But what would be the point? The input layer wouldn't do any processing on them. It wouldn't buy us much. So we might want to simply stick with todays lirc interface for the raw samples. Drivers which support both ir codes (be it by hardware or by in-kernel decoding) and raw samples would register two devices then, one input device and one lirc device. It would probably a good idea to stop sending events to the input layer as soon as someone (most likely lircd) opens the lirc device to avoid keystrokes showing up twice. By default the in-kernel bits will be at work, but optionally you can have lircd grab the raw samples and do fancy advanced decoding. (2a) Input layer doesn't help with raw samples: So now what about devices that don't produce codes at all, but simply pulse width measurements? Where's the infrastrucutre to perform low pass filtering to get rid of glitches and to perform oversampling to deal with pulse jitter, so that adding a new IR device isn't a pain incurred per driver? I was quite dismayed at how much I had to reimplement here, just for RC-5 for the sake of the input layer and having a remote Just Work: http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23885-input.c lirc does all that stuff in spades. (3) input layer doesn't allow transmitting IR codes. If we keep the lirc interface for raw samples anyway, then we can keep it for sending too, problem solved ;) How does sending hardware work btw? Do they all accept just raw samples? Or does some hardware also accept ir-codes? The Conexant chips' integrated IR Tx hardware expects a series of pulse widths and a flag for mark or space with each width. I'd have to research other implementations. Regards, Andy cheers, Gerd --
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 25, 2009, at 2:27 PM, Krzysztof Halasa wrote: Jarod Wilson ja...@wilsonet.com writes: Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: 1) bring drivers in in their current state - users keep using lirc as they always have 2) add in-kernel decoding infra that feeds input layer Well. I think the above is fine enough. 3) add option to use in-kernel decoding to existing lirc drivers - users can keep using lirc as they always have - users can optionally try out in-kernel decoding via a modparam 4) switch the default mode from lirc decode to kernel decode for each lirc driver - modparam can be used to continue using lirc interface instead 5) assuming users aren't coming at us with pitchforks, because things don't actually work reliably with in-kernel decoding, deprecate the lirc interface in driver 6) remove lirc interface from driver, its now a pure input device But 3-6 are IMHO not useful. We don't need lirc _or_ input. We need both at the same time: input for the general, simple case and for consistency with receivers decoding in firmware/hardware; input for special cases such as mapping the keys, protocols not supported by the kernel and so on (also for in-tree media drivers where applicable). [*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all others will be shot on sight. ;) I think: in-kernel decoding only as the general, primary means. Not the only one. Okay, I read ya now. I got my wires crossed, thought you were advocating for dropping the lirc interface entirely. I think we're on the same page then. :) -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 09:51:31PM +0100, Krzysztof Halasa wrote: Dmitry Torokhov dmitry.torok...@gmail.com writes: Curreently the scan codes in the input layer serve just to help users to map whatever the device emits into a proper input event code so that the rest of userspace would not have to care and would work with all types of devices (USB, PS/2, etc). I would not want to get to the point where the raw codes are used as a primary data source. The key interface is not flexible enough at present. In what way the key interface is unsufficient for delivering button events? -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehabmche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. Right, but still the keys usually do have the well-defined meaning, teh issue is in mapping raw code to the appropriate keycode. This can be done either by lirc config file (when lirc is used) or by some other means. ... We need to handle more than one RC at a time, of course. So, the basic question that should be decided is: should we create a new userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). I think if the data is used to do the primary protocol decoding then it should be a separate interface that is processed by someone and then fed into input subsystem (either in-kernel or through uinput). Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for keys and buttons on all devices. Current lircd actually inter-operates with the input subsystem quite well for any and all supported remotes if their keys are mapped in their respective lircd.conf file using standard input subsystem key names, and the lirc daemon started with the --uinput param. lircd decodes the raw IR, finds the mapping in its config, and happily passes it along to uinput. Right. I guess the question is what is the interface we want the regular userspace (i.e. not lircd) to use. Right now programs has to use 2 intercfaces - one lirc for dealing with remotes that are not using the standard event interface and evdev for remotes using it as well as the rest of the input devices. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: Czesc Krzysztof, on 23 Nov 09 at 15:14, Krzysztof Halasa wrote: [...] I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. I agree with Christoph. Is it that the input subsystem is better developed and seen as a leverage point for development and thus an easier place to get results earlier? If so, then one should definitely deal with transmitters early in the design, as that is where the most unknowns lie. With the end of analog TV, people will have STBs feeding analog only video cards. Being able to change the channel on the STB with an IR transmitter controlled by applications like MythTV is essential. And on some different notes: I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are forced to support lirc because the remores are not available through other means? I believe it is the latter and applications writers would be happy to reduce number of ways they get button data. I don't think there is LIRC aversion per se. We are just trying to decide whether multiple interfaces for the same data is needed. And I don't think that we will completely reject userspace components. Just as input subsystem allows for userspace drivers I do not think why we can't have the same for the LIRC. But I do think that the primary interface for regular userspace consumers (read mplayer and MythTV and the likes) should be input event interface (EV_KEY/KEY_*). -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehabmche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. Right, but still the keys usually do have the well-defined meaning, Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean. teh issue is in mapping raw code to the appropriate keycode. This can be done either by lirc config file (when lirc is used) or by some other means. The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too. ... We need to handle more than one RC at a time, of course. So, the basic question that should be decided is: should we create a new userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). I think if the data is used to do the primary protocol decoding then it should be a separate interface that is processed by someone and then fed into input subsystem (either in-kernel or through uinput). Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for keys and buttons on all devices. Current lircd actually inter-operates with the input subsystem quite well for any and all supported remotes if their keys are mapped in their respective lircd.conf file using standard input subsystem key names, and the lirc daemon started with the --uinput param. lircd decodes the raw IR, finds the mapping in its config, and happily passes it along to uinput. Right. I guess the question is what is the interface we want the regular userspace (i.e. not lircd) to use. Right now programs has to use 2 intercfaces - one lirc for dealing with remotes that are not using the standard event interface and evdev for remotes using it as well as the rest of the input devices. From the mythtv perspective, using the input layer could yield a better out-of-the-box experience -- users don't have to set up an lircrc mapping that converts key names as specified in lircd.conf into commands (key strokes, actually) that mythtv understands. For example, a button labeled Play in lircd.conf has to be mapped to 'p' in ~/.lircrc for mythtv to do the right thing with it. If everything came through the input layer, be that natively or via lircd's uinput reinjection, there would be no need to do that extra mapping step, mythtv would simply handle a KEY_PLAY event. So at worst, one manual mapping to do -- IR signal to standard button name in lircd.conf -- instead of two. But the lircrc approach does also allow more flexibility, in that you can only have a certain app respond to a certain key, if so desired, and remap a key to a different function (KEY_RED, KEY_GREEN, KEY_BLUE, KEY_YELLOW -- what should their default functionality be? I know some users map a pair of those to mythtv's skip to next commflag point and skip to prior commflag point). Unfortunately, mythtv currently doesn't handle KEY_PLAY, KEY_VOLUMEUP, etc., etc. at all right now, it operates purely on keys commonly found on a standard keyboard. Remedying that is on my TODO list for the next release, if I can carve out the time. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: Czesc Krzysztof, on 23 Nov 09 at 15:14, Krzysztof Halasa wrote: [...] I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. I agree with Christoph. Is it that the input subsystem is better developed and seen as a leverage point for development and thus an easier place to get results earlier? If so, then one should definitely deal with transmitters early in the design, as that is where the most unknowns lie. With the end of analog TV, people will have STBs feeding analog only video cards. Being able to change the channel on the STB with an IR transmitter controlled by applications like MythTV is essential. And on some different notes: I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are forced to support lirc because the remores are not available through other means? I believe it is the latter and applications writers would be happy to reduce number of ways they get button data. Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. serial receivers and transmitters, both supported by lirc_serial, were the most frequently used devices outside of plain old keyboards. The lirc support in mythtv actually relies on mapping remote button names as defined in lircd.conf to keyboard key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but I intend on fixing that... I don't think there is LIRC aversion per se. We are just trying to decide whether multiple interfaces for the same data is needed. And I don't think that we will completely reject userspace components. Just as input subsystem allows for userspace drivers I do not think why we can't have the same for the LIRC. But I do think that the primary interface for regular userspace consumers (read mplayer and MythTV and the likes) should be input event interface (EV_KEY/KEY_*). Works for me. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: ... I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. There's one gripe I agree with, and that is that its still not plug-n-play. Something where udev auto-loads a sane default remote config for say, mceusb transceivers, and the stock mce remote Just Works would be nice, but auto-config is mostly out the window the second you involve transmitters and universal remotes anyway. But outside of that, I think objections are largely philosophical -- in a nutshell, the kernel has an input layer, remotes are input devices, and lirc doesn't conform to input layer standards. I do understand that argument, I just don't currently agree that all IR must go through the input layer before the drivers are acceptable for upstream -- especially since lircd can reinject decoded key presses into the input layer via uinput. I believe Jarod's intent is to have the LIRC components, that need to be in kernel modules, moved into kernel mainline to avoid the headaches of out of kernel driver maintenance. I'm not sure it is time well spent for developers, or end users, to develop yet another IR receive implementation in addition to the ones we suffer with now. Yeah, a fairly relevant factor in all this is that, despite not being in the linux kernel source tree proper-like, the lirc drivers and lirc have been in use for many years by lots of users. The likes of Fedora, Debian, Ubuntu, SUSE, Mandriva, etc. have all been shipping lirc drivers for years now. While lirc certainly isn't perfect (its not always the easiest thing for users to set up), it has actually proven itself pretty robust and useful in the field, once set up. The bulk of breakage in lirc I've personally had to deal with has mostly come in the form of kernel interface changes, which would definitely be mitigated by not having to maintain the drivers out-of-tree any longer. Now, I'm all for improving things and integrating better with the input subsystem, but what I don't really want to do is break compatibility with the existing setups on thousands (and thousands?) of MythTV boxes around the globe. The lirc userspace can be pretty nimble. If we can come up with a shiny new way that raw IR can be passed out through an input device, I'm pretty sure lirc userspace can be adapted to handle that. If a new input-layer-based transmit interface is developed, we can take advantage of that too. But there's already a very mature lirc interface for doing all of this. So why not start with adding things more or less as they exist right now and evolve the drivers into an idealized form? Getting *something* into the kernel in the first place is a huge step in that direction. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Considering the common case where the lirc driver will be associated with a media input device, the IR type can be detected automatically on kernel. However, advanced users may opt to use other IR types than what's provided with the device they bought. I think most users would want to do that, though I don't have hard numbers of course. Why use a number of RCs simultaneously while one will do? It should also be noticed that not all the already-existing IR drivers on kernel can provide a lirc interface, since several devices have their own IR decoding chips inside the hardware. Right. I think they shouldn't use lirc interface, so it doesn't matter. 2) create a lirc kernel API, and have a layer there to decode IR protocols and output them via the already existing input layer. In this case, all we need to do, in terms of API, is to add a way to set the IR protocol that will be decoded, and to enumberate the capabilities. The lirc API, will be an in-kernel API to communicate with the devices that don't have IR protocols decoding capabilities inside the hardware. I think this makes a lot of sense. But: we don't need a database of RC codes in the kernel (that's a lot of data, the user has to select the RC in use anyway so he/she can simply provide mapping e.g. RC5keycode). We do need RCx etc. protocols implementation in the kernel for the input layer. lirc interface: should we be sending time+on/off data to userspace, or the RC5 etc. should be implemented in the kernel? There is (?) only a handful of RC protocols, implementing them in the kernel and passing only information such as proto+group+code+press/release etc. should be more efficient. Perhaps the raw RCx data could be sent over the input layer as well? Something like the raw keyboard codes maybe? We need to handle more than one RC at a time, of course. So, the basic question that should be decided is: should we create a new userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). or it would be better to standardize it to always use the existing input layer? I'd optionally provide a keyboard-alike input layer interface, with mappings (proto + raw code key) provided by userspace program. This should also work with multiple remotes. Then the existing drivers (such as saa713x with GPIO+IRQ-driven IR receiver (IR signal on/off generating IRQ)) should be converted. I think we shouldn't at this time worry about IR transmitters. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 9:14 AM, Krzysztof Halasa k...@pm.waw.pl wrote: I think this makes a lot of sense. But: we don't need a database of RC codes in the kernel (that's a lot of data, the user has to select the RC in use anyway so he/she can simply provide mapping e.g. RC5keycode). Just bear in mind that with the current in-kernel code, users do *not * have to manually select the RC code to use if they are using the default remote that shipped with the product. This helps alot for those unfamiliar with LIRC, since their product works out of the box with the remote the product came with. I agree though, that the user should be able to easily change the RC to be used if he/she decides to use a remote other than the default. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
It is perhaps time to resurrect Jon Smirl's work about In-kernel IR remote control support ? See http://marc.info/?l=linux-kernelm=122591465821297w=2 and all discussions around it. Regards, Emmanuel. --- Laposte.net fête ses 10 ans ! Gratuite, garantie à vie et déjà utilisée par des millions d'internautes... vous aussi, pour votre adresse e-mail, choisissez laposte.net. Laposte.net, bien + qu'une messagerie -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Modern input drivers in the mainline kernel have a scancode-to-keycode translation table (or equivalent) which can be overwritten by userspace. The mechanism to do that is the EVIOCSKEYCODE ioctl. (This is no recommendation for lirc. I have no idea whether a pulse/space - scancode - keycode translation would be practical there.) -- Stefan Richter -=-==--= =-== =-=== http://arcgraph.de/sr/ -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com: Just bear in mind that with the current in-kernel code, users do *not * have to manually select the RC code to use if they are using the default remote that shipped with the product. This could still happen, if LIRC checks the identifiers of the reciving device, and has a database that tells it mappings between those devices and the remote controls that shipped with them. However, it occours to me that the IR circumstances map pretty well to what happens with ps/2 and serial devices now: 1: There are a variety of drivers for serio computer-side hardware, each of which speaks the serio interface to the next-higher level. These corrospond to the drivers for IR recievers. 2: There's a raw serio interface, for those wishing to do strange things. 3: There's also a variety of things that take data, using the kernel serio API, and decode it into input events -- the ps2 keyboard driver, the basic mouse driver, the advanced mice drivers. This is where the interface falls down a little bit -- the ps2 keyboard driver is the closest analogue to what I'm suggesting. The ps2 keyboard driver creates scancode events, which map nicely to what the keyboard is sending -- these are, for ex, rc5 codes. It will also produce key-up/key-down events, if it has a keymap loaded. (This is the difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned to it at boottime, so it works out-of-box. This isn't really possible with an IR remote -- though perhaps rc5 is standarized enough, I don't think other protocols neccessarly are.) Userspace would have to load a keymap; those don't really belong in kernel code. Of course, userspace could look at the device identifiers to pick a reasonable default keymap if it's not configured to load another, solving the out-of-box experince. Why is this such a contentious point? I can understand wanting to keep uncommon decoding algos out of the kernel, and keymaps, but at the same time, they are currently there, in multiple drivers, and while colesing them into a single place each makes sense, I'm not convinced that moving them out completely makes all that much sense. Having an explicit layer between the raw pulse/space layer and the decoders means that usespace can hook in there, and create scancode events, if it wishes to, but for the majority of remotes that use just a couple of encoding schemes, the code can stay in the kernel. Of course, devices that do the decoding in hardware would not implement the raw interface, but simply create the scancode/keycode events. -=- James Mastros -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com: Just bear in mind that with the current in-kernel code, users do *not * have to manually select the RC code to use if they are using the default remote that shipped with the product. This could still happen, if LIRC checks the identifiers of the reciving device, and has a database that tells it mappings between those devices and the remote controls that shipped with them. However, it occours to me that the IR circumstances map pretty well to what happens with ps/2 and serial devices now: 1: There are a variety of drivers for serio computer-side hardware, each of which speaks the serio interface to the next-higher level. These corrospond to the drivers for IR recievers. 2: There's a raw serio interface, for those wishing to do strange things. 3: There's also a variety of things that take data, using the kernel serio API, and decode it into input events -- the ps2 keyboard driver, the basic mouse driver, the advanced mice drivers. This is where the interface falls down a little bit -- the ps2 keyboard driver is the closest analogue to what I'm suggesting. The ps2 keyboard driver creates scancode events, which map nicely to what the keyboard is sending -- these are, for ex, rc5 codes. It will also produce key-up/key-down events, if it has a keymap loaded. (This is the difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned to it at boottime, so it works out-of-box. This isn't really possible with an IR remote -- though perhaps rc5 is standarized enough, I don't think other protocols neccessarly are.) Userspace would have to load a keymap; those don't really belong in kernel code. Of course, userspace could look at the device identifiers to pick a reasonable default keymap if it's not configured to load another, solving the out-of-box experince. -=- James Mastros -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 12:05 PM, James Mastros ja...@mastros.biz wrote: 2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com: Just bear in mind that with the current in-kernel code, users do *not * have to manually select the RC code to use if they are using the default remote that shipped with the product. This could still happen, if LIRC checks the identifiers of the reciving device, and has a database that tells it mappings between those devices and the remote controls that shipped with them. However, it occours to me that the IR circumstances map pretty well to what happens with ps/2 and serial devices now: 1: There are a variety of drivers for serio computer-side hardware, each of which speaks the serio interface to the next-higher level. These corrospond to the drivers for IR recievers. 2: There's a raw serio interface, for those wishing to do strange things. 3: There's also a variety of things that take data, using the kernel serio API, and decode it into input events -- the ps2 keyboard driver, the basic mouse driver, the advanced mice drivers. Â This is where the interface falls down a little bit -- the ps2 keyboard driver is the closest analogue to what I'm suggesting. Â The ps2 keyboard driver creates scancode events, which map nicely to what the keyboard is sending -- these are, for ex, rc5 codes. Â It will also produce key-up/key-down events, if it has a keymap loaded. Â (This is the difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned to it at boottime, so it works out-of-box. Â This isn't really possible with an IR remote -- though perhaps rc5 is standarized enough, I don't think other protocols neccessarly are.) Userspace would have to load a keymap; those don't really belong in kernel code. Â Of course, userspace could look at the device identifiers to pick a reasonable default keymap if it's not configured to load another, solving the out-of-box experince. I think perhaps before we go much further into this, we may wish to come up with a set of use cases and expected behavior. I worry that part of the problem here is people are thinking of how their particular cards behave, and few people have a holistic picture of all the possible scenarios. Whatever implementation we come up, we should be confident that it meets the requirements of *all* the various hardware implementations. I will try to draft up some requirements/use cases if people think this would be worthwhile. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Key mapping can be easily changed via input interface, as noticed by others. Considering the common case where the lirc driver will be associated with a media input device, the IR type can be detected automatically on kernel. However, advanced users may opt to use other IR types than what's provided with the device they bought. I think most users would want to do that, though I don't have hard numbers of course. Why use a number of RCs simultaneously while one will do? If you're building a dedicated hardware to act as a MCE, it makes sense to use just one IR to control your TV and your hardware, but the common usage is to add a TV board or stick to your desktop to see TV. For this, the standard IR fits well. It should also be noticed that not all the already-existing IR drivers on kernel can provide a lirc interface, since several devices have their own IR decoding chips inside the hardware. Right. I think they shouldn't use lirc interface, so it doesn't matter. If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. It is very bad to have two interfaces for the same thing, because people may do things like that. Also, there are some cases where the same V4L driver can receive IR scancodes directly for one board, while for others, it needs to get pulse/space decoding. So, it makes sense to have an uniform way for doing it. 2) create a lirc kernel API, and have a layer there to decode IR protocols and output them via the already existing input layer. In this case, all we need to do, in terms of API, is to add a way to set the IR protocol that will be decoded, and to enumberate the capabilities. The lirc API, will be an in-kernel API to communicate with the devices that don't have IR protocols decoding capabilities inside the hardware. I think this makes a lot of sense. But: we don't need a database of RC codes in the kernel (that's a lot of data, the user has to select the RC in use anyway so he/she can simply provide mapping e.g. RC5keycode). This is an interesting discussion. We currently have lots of such tables in kernel, but it can be a good idea to have it loaded by udev during boot time. We do need RCx etc. protocols implementation in the kernel for the input layer. Yes. We already have this. See bttv, saa7134 and cx88 for several of such protocol decoding. lirc interface: should we be sending time+on/off data to userspace, or the RC5 etc. should be implemented in the kernel? There is (?) only a handful of RC protocols, implementing them in the kernel and passing only information such as proto+group+code+press/release etc. should be more efficient. Perhaps the raw RCx data could be sent over the input layer as well? Something like the raw keyboard codes maybe? We need to handle more than one RC at a time, of course. Are you meaning that we should do more than one RC per input event interface? If so, why do you think we need to handle more than one IR protocol at the same time? I think this will just make the driver more complex without need. Also, I'm not sure if this would work well for all protocols. So, the basic question that should be decided is: should we create a new userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). Since the key mapping table can be changed anytime, I don't see this as an issue. If we are doing protocol handling in kernel, we just need to add some extensions to the existing input event API to properly handle the IR protocol type. I think we shouldn't at this time worry about IR transmitters. Agreed. We can postpone this discussion after solving the IR receivers 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Perhaps the raw RCx data could be sent over the input layer as well? Something like the raw keyboard codes maybe? Curreently the scan codes in the input layer serve just to help users to map whatever the device emits into a proper input event code so that the rest of userspace would not have to care and would work with all types of devices (USB, PS/2, etc). I would not want to get to the point where the raw codes are used as a primary data source. We need to handle more than one RC at a time, of course. So, the basic question that should be decided is: should we create a new userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). I think if the data is used to do the primary protocol decoding then it should be a separate interface that is processed by someone and then fed into input subsystem (either in-kernel or through uinput). Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for keys and buttons on all devices. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Stefan Richter wrote: Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Modern input drivers in the mainline kernel have a scancode-to-keycode translation table (or equivalent) which can be overwritten by userspace. The mechanism to do that is the EVIOCSKEYCODE ioctl. This mechanism is already used by all V4L drivers and several DVB drivers. (This is no recommendation for lirc. I have no idea whether a pulse/space - scancode - keycode translation would be practical there.) pulse/space - scancode translation is already done by several existing drivers. For example, there are several bttv and saa7134 devices that polls (or receive IRQ interrupts) to detect pulses (and the absense of them) in order to create a pulse/space code. The conversion from pulse/space to scancode is done inside the driver, with the help of some generic routines and based on the protocol specifications. The conversion from the scancode to a keycode is done based on in-kernel keycode tables that can be changed from userspace with EVIOCSKEYCODE ioctl. I can't see any technical reason why not doing the same for the lirc drivers, except for one issue: Those devices where the decoding is done by software can support any IR protocols. So, it is possible to buy a device with a NEC IR, and use a RC5 IR to control it. However, currently, there's no way to inform the kernel to use a different algorithm to translate the kernel. This can be solved by adding a few ioctls to enumerate the supported protocols and to select the one(s) that will be handled by the kernel driver. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
James Mastros wrote: 2009/11/23 Devin Heitmueller dheitmuel...@kernellabs.com: Just bear in mind that with the current in-kernel code, users do *not * have to manually select the RC code to use if they are using the default remote that shipped with the product. This could still happen, if LIRC checks the identifiers of the reciving device, and has a database that tells it mappings between those devices and the remote controls that shipped with them. True, but this means that everyone with an IR will need to use lirc. /me thinks that, whatever decided with those lirc drivers, this should be applied also to the existing V4L/DVB drivers. IMO, it would be better to load the tables at the boot time (or at the corresponding hotplug event, for USB devices). However, it occours to me that the IR circumstances map pretty well to what happens with ps/2 and serial devices now: 1: There are a variety of drivers for serio computer-side hardware, each of which speaks the serio interface to the next-higher level. These corrospond to the drivers for IR recievers. 2: There's a raw serio interface, for those wishing to do strange things. 3: There's also a variety of things that take data, using the kernel serio API, and decode it into input events -- the ps2 keyboard driver, the basic mouse driver, the advanced mice drivers. Seems an interesting model. This is where the interface falls down a little bit -- the ps2 keyboard driver is the closest analogue to what I'm suggesting. The ps2 keyboard driver creates scancode events, which map nicely to what the keyboard is sending -- these are, for ex, rc5 codes. It will also produce key-up/key-down events, if it has a keymap loaded. (This is the difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned to it at boottime, so it works out-of-box. This isn't really possible with an IR remote -- though perhaps rc5 is standarized enough, I don't think other protocols neccessarly are.) Even with RC5, there are some vendors that implement it differently on his IR (for example, using VCR and/or TV group for the keys). Userspace would have to load a keymap; those don't really belong in kernel code. Of course, userspace could look at the device identifiers to pick a reasonable default keymap if it's not configured to load another, solving the out-of-box experince. I like this idea. We currently have hundreds of IR keymaps already in kernel. It seems good to remove from kernel and let udev load those. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
I'm a bit short on time to write up a more complete reply to anything in this thread at the moment, but a few quick notes interspersed below. On Nov 23, 2009, at 12:29 PM, Mauro Carvalho Chehab wrote: Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: ... Considering the common case where the lirc driver will be associated with a media input device, the IR type can be detected automatically on kernel. However, advanced users may opt to use other IR types than what's provided with the device they bought. I think most users would want to do that, though I don't have hard numbers of course. Why use a number of RCs simultaneously while one will do? If you're building a dedicated hardware to act as a MCE, it makes sense to use just one IR to control your TV and your hardware, but the common usage is to add a TV board or stick to your desktop to see TV. For this, the standard IR fits well. The main use case that I have personal experience using IR and capture devices is with MythTV. Its not at all uncommon for a MythTV user to have a setup where the capture devices are attached to a completely different system from the system where the IR part needs to be. MythTV is client-server -- the backend server does the video capture via the capture devices, and the frontend client plays back the video, and its the frontend client that you navigate via an IR remote control. There are quite a few available IR options that are NOT tied to a video capture device at all -- the mceusb and imon drivers submitted in my patch series are actually two such beasts. And particularly with the mceusb receivers, because they support damn near every IR protocol under the sun at any carrier frequency, using a remote other than the bundled one is quite common. Most people's set top boxes and/or televisions and/or AV receivers come with a remote capable of controlling multiple devices, and many bundled remotes are, quite frankly, utter garbage. I use a Logitech Harmony 880 universal remote myself. It should also be noticed that not all the already-existing IR drivers on kernel can provide a lirc interface, since several devices have their own IR decoding chips inside the hardware. Right. I think they shouldn't use lirc interface, so it doesn't matter. If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. Historically, this is true. But the version I submitted actually defaults to operating as a pure input layer device for all the imon devices that do onboard decoding. There are older imon devices that don't do onboard decoding, and I retained legacy, if you will, lirc interface support in this pass of the driver for the onboard decode devices for those that want to keep things running as they always have (via a modparam). More replyification later tonight... -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
James Mastros ja...@mastros.biz writes: (This is the difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned to it at boottime, so it works out-of-box. This isn't really possible with an IR remote -- though perhaps rc5 is standarized enough, I don't think other protocols neccessarly are.) Even with RC5 this isn't really possible. RC5 specifies several classes of remotes, and with a typical HTPC scenario the sensor will pick up more than one remote codeset - e.g. one for the display, one for TV card, and maybe others (all those codes may be coming from a single remote). We have no way to know in advance which one code set is for the PC. The only thing which we can preconfigure is the remote bundled with the sensor (card etc). And even this can be incorrect. Several sensors don't came with a remote controller. I think the default sensor-remote assignment may only make sense in userspace, while configuring the mapping. Of course all the above changes when the sensors can't present the raw data (IR on/off) but does all the decoding internally (and for example can't decode all RC5 but only keys used on its remote). In such unfortunate cases it has to go to the input layer directly. Userspace would have to load a keymap; those don't really belong in kernel code. Of course, userspace could look at the device identifiers to pick a reasonable default keymap if it's not configured to load another, solving the out-of-box experince. Precisely. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: True, but this means that everyone with an IR will need to use lirc. I think that if the input layer (instead of raw code) is used, a utility which only sets the mapping(s) would suffice. I.e. no daemon. /me thinks that, whatever decided with those lirc drivers, this should be applied also to the existing V4L/DVB drivers. Certainly. IMO, it would be better to load the tables at the boot time (or at the corresponding hotplug event, for USB devices). Sure (unless the raw code interface is in use). Though maybe the raw code interface should be done in a simple library instead of requiring the daemon. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: (This is no recommendation for lirc. I have no idea whether a pulse/space - scancode - keycode translation would be practical there.) It would, but not exactly in the present shape. For example, there are several bttv and saa7134 devices that polls (or receive IRQ interrupts) to detect pulses (and the absense of them) in order to create a pulse/space code. The conversion from pulse/space to scancode is done inside the driver, with the help of some generic routines and based on the protocol specifications. Right. There are currently several problems (I'm quite familiar with saa713x RC5 code): the one that it barely works and is not implemented for most such GPIO/IRQ-driven cards (as of 2.6.29 or so). This could be fixed, I even have a working though quickdirty patch. Another: the RC5 allows for groups and codes within groups. The mapping can only use one group, and there can only be one mapping. These design limitations mean it's unusable in many cases. Those devices where the decoding is done by software can support any IR protocols. Yes, and there can be multiple remote controllers, and multiple code groups within a remote. This can be solved by adding a few ioctls to enumerate the supported protocols and to select the one(s) that will be handled by the kernel driver. The driver may have to handle many protocols simultaneously. This is not a problem from a technical POV. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. IOW the driver generates artificial pulse code for lircd? I think - pure bloat. lircd can get events from input layer without problems. Perhaps I misunderstood? It is very bad to have two interfaces for the same thing, because people may do things like that. I think having a raw scan code interface + the key code cooked mode is beneficial. For remotes lacking the raw interface only the latter could be used. Also, there are some cases where the same V4L driver can receive IR scancodes directly for one board, while for others, it needs to get pulse/space decoding. Sure. This is an interesting discussion. We currently have lots of such tables in kernel, but it can be a good idea to have it loaded by udev during boot time. Sure. Are you meaning that we should do more than one RC per input event interface? I think so. Why not? For example, one of my remotes generates codes from at least two RC5 groups (in only one mode). Currently a remote is limited to only one RC5 group. I think the mapping should be: key = proto + group + raw code, while key2 could be different_proto + different group (if any) + another code. If so, why do you think we need to handle more than one IR protocol at the same time? Why not? There are X-in-1 remotes on the market for years. They can speak many protocols at once. One may want to have a protocol to handle DVD apps while another for DVB etc. And someone may want to use several different remotes, why not? Personally I use two different remotes (both set to speak RC5 but what if I couldn't set the protocol?). Sure, it requires a bit of hackery (not with pulse code and lircd). I think this will just make the driver more complex without need. Not much more, and there is a need. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson ja...@wilsonet.com writes: There are quite a few available IR options that are NOT tied to a video capture device at all -- the mceusb and imon drivers submitted in my patch series are actually two such beasts. Precisely. This also includes the parallel and serial port receivers, I'm under impression that they are, or at least were, the most common, due to their extreme simplicity. And particularly with the mceusb receivers, because they support damn near every IR protocol under the sun at any carrier frequency, using a remote other than the bundled one is quite common. Most people's set top boxes and/or televisions and/or AV receivers come with a remote capable of controlling multiple devices, and many bundled remotes are, quite frankly, utter garbage. This is precisely also my experience. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov dmitry.torok...@gmail.com writes: Curreently the scan codes in the input layer serve just to help users to map whatever the device emits into a proper input event code so that the rest of userspace would not have to care and would work with all types of devices (USB, PS/2, etc). I would not want to get to the point where the raw codes are used as a primary data source. The key interface is not flexible enough at present. Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for keys and buttons on all devices. Primary, I think so. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Czesc Krzysztof, on 23 Nov 09 at 15:14, Krzysztof Halasa wrote: [...] I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. Christoph -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Jarod, on 23 Nov 09 at 14:17, Jarod Wilson wrote: Krzysztof Halasa wrote: [...] If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. Historically, this is true. No, it's not. I think you misunderstood the code. The comment may be a bit misleading, too. Early iMON devices did not decode in hardware and the part of the driver that Krzystof is referring to is translating a bit-stream of the sampled input data into pulse/space durations. Christoph -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
l...@bartelmus.de (Christoph Bartelmus) writes: I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. I don't say don't use a transmitter. I say the transmitter is not an input device, they are completely independent functions. I can't see any reason to try and fit both in the same interface - can you? -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 4:46 PM, Krzysztof Halasa k...@pm.waw.pl wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. I don't say don't use a transmitter. I say the transmitter is not an input device, they are completely independent functions. I can't see any reason to try and fit both in the same interface - can you? There is an argument to be made that since it may be desirable for both IR receivers and transmitters to share the same table of remote control definitions, it might make sense to at least *consider* how the IR transmitter interface is going to work, even if it is decided to not implement such a design in the first revision. Personally, I would hate to see a situation where we find out that we took a bad approach because nobody considered what would be required for IR transmitters to reuse the same remote control definition data. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
I though about it a bit - my idea:
1. Receivers that can only decode their own remote controllers.
The present code (saa713x etc) can stay mostly unchanged. I'd only
verify that 7 bits (or whatever the number is) is enough for all
cases. The ioctl() should stay unchanged. That means keyboard-like
input layer interface.
2. Receivers that can be programmed to receive different codes, and/or
which simply generate IRQ on space/mark changes. They would use a new
ioctl() instead:
int set_rc_mapping_ioctl(void *data ...)
data should be:
u32 protocol1;
u32 length1;
u32 protocol2;
u32 length2;
...
u32 protocol_last;
u32 length_last;
(u32) 0.
The protocol data would follow (after all proto/length fields to avoid
alignment issues, but that's a detail of course).
For example, RC5. It uses 1 start bit (formerly 2 bits), 1 toggle bit,
5 address bits (group code) and 7 command bits (formerly 6 bits).
Each key would be represented by u16, or maybe by a couple of u8.
A discard repeated (perhaps inverted) bit should be included. Of
course, the symbolic key code should be included for each scan code.
Maybe: u8 address_and_discard_repeated_bit;
u8 command_value;
u8 symbolic_key_code;
repeated as required.
Protocol2 would follow protocol1 etc. (alignment issues). The driver
could see this info (for example, to program hardware to receive a
specific protocol) and then it should pass it to the generic
lirc_set_mapping() routine.
I'd also add separate trivial space/mark protocol, for debugging etc.
Maybe: u8 key_code_for_space;
u8 key_code_for_mark;
Maybe specifying length = 0 (meaning constant key codes) would be
enough? I think the key code should also specify some time stamp (or
pulse length).
Interface to the sensor driver:
The driver should register an IRQ called on both (preferably) edges of
the input signal. Basically it should only register IRQ and do:
irqreturn_t xxx_irq()
{
ack_irq_as_usual_etc();
if (input_signal-changed_state) /* really for us */
lirc_signal_state_change(input_signal-current_state);
}
The sensor driver would not know about the protocols etc. unless it
needs to e.g. program the hardware.
The middle layer (some sort of a library, and module) would interface to
the userspace (ioctl passed by the driver, input interface) and to the
hw driver. It would have to enable and call the required protocol
decoders (based on the keymap loaded).
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Devin Heitmueller dheitmuel...@kernellabs.com writes: There is an argument to be made that since it may be desirable for both IR receivers and transmitters to share the same table of remote control definitions, it might make sense to at least *consider* how the IR transmitter interface is going to work, even if it is decided to not implement such a design in the first revision. Personally, I would hate to see a situation where we find out that we took a bad approach because nobody considered what would be required for IR transmitters to reuse the same remote control definition data. I briefly though about such possibility, but dismissed it with assumption that we won't transmit the same codes (including key codes) that we receive. Perhaps I'm wrong. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, Nov 23, 2009 at 5:31 PM, Krzysztof Halasa k...@pm.waw.pl wrote: Devin Heitmueller dheitmuel...@kernellabs.com writes: There is an argument to be made that since it may be desirable for both IR receivers and transmitters to share the same table of remote control definitions, it might make sense to at least *consider* how the IR transmitter interface is going to work, even if it is decided to not implement such a design in the first revision. Personally, I would hate to see a situation where we find out that we took a bad approach because nobody considered what would be required for IR transmitters to reuse the same remote control definition data. I briefly though about such possibility, but dismissed it with assumption that we won't transmit the same codes (including key codes) that we receive. I'm not specifically suggesting that you would want to transmit the same codes that you receive, but you probably want the database of remote control definitions to be shared. For example, you might want the IR receiver to be listening for codes using the Universal Remote Control XYZ profile and the IR transmitter pretending to be Cable Company Remote Control ABC when blasting IR codes to the cable box. Ideally, there would be a single shared database of the definitions of the remote controls, regardless of whether you are IR receiving or transmitting. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Devin Heitmueller dheitmuel...@kernellabs.com writes: For example, you might want the IR receiver to be listening for codes using the Universal Remote Control XYZ profile and the IR transmitter pretending to be Cable Company Remote Control ABC when blasting IR codes to the cable box. Ideally, there would be a single shared database of the definitions of the remote controls, regardless of whether you are IR receiving or transmitting. Well, with different receivers, the maps must certainly be different. There can be single database in the userspace but the kernel must be uploaded the relevant info only. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: Czesc Krzysztof, on 23 Nov 09 at 15:14, Krzysztof Halasa wrote: [...] I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. I agree with Christoph. Is it that the input subsystem is better developed and seen as a leverage point for development and thus an easier place to get results earlier? If so, then one should definitely deal with transmitters early in the design, as that is where the most unknowns lie. With the end of analog TV, people will have STBs feeding analog only video cards. Being able to change the channel on the STB with an IR transmitter controlled by applications like MythTV is essential. And on some different notes: I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. I believe Jarod's intent is to have the LIRC components, that need to be in kernel modules, moved into kernel mainline to avoid the headaches of out of kernel driver maintenance. I'm not sure it is time well spent for developers, or end users, to develop yet another IR receive implementation in addition to the ones we suffer with now. I would also note that RC-6 Mode 6A, used by most MCE remotes, was developed by Philips, but Microsoft has some sort of licensing interest in it and it is almost surely encumbered somwhow: http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt Microsoft recommends the Microsoft-Philips IR protocol (based on RC6) * You can become a licensee at no charge to you [...] * How to license RC6 * Contact RemoteMC @ microsoft.com for license agreement I would much rather that RC-6 be handled as much as possible in user space than in the kernel. LIRC userspace components already handle it, IIRC. Regards, Andy LIRC Fan-Boy Walls -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. I don't say don't use a transmitter. I say the transmitter is not an input device, they are completely independent functions. I can't see any reason to try and fit both in the same interface - can you? The underlying hardware need not be completely independent. For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012] chips have IR hardware that shares a common timing source, interrupt line, interrupt status register, etc, between IR Rx and Tx. They can also do things like loopback of Tx to Rx. That said, an underlying hardware implementation can be split up to user space with separate interfaces Tx and Rx. The underlying driver module would have to manage the dependencies. I would guess that would be easier for driver modules, if the userspace interfaces were designed with such combined IR Tx/Rx hardware in mind. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/23/2009 04:10 PM, Christoph Bartelmus wrote: Hi Jarod, on 23 Nov 09 at 14:17, Jarod Wilson wrote: Krzysztof Halasa wrote: [...] If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. Historically, this is true. No, it's not. I think you misunderstood the code. The comment may be a bit misleading, too. Early iMON devices did not decode in hardware and the part of the driver that Krzystof is referring to is translating a bit-stream of the sampled input data into pulse/space durations. Sorry, no, I know the newer devices don't actually send pulse/data info out to userspace, just hex codes that correspond to key presses. What I meant was onboard decoding devices can operate as pure input devices or in classic lirc mode, leaving out the details on exactly what they were sending out to userspace. :) -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehabmche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. ... We need to handle more than one RC at a time, of course. So, the basic question that should be decided is: should we create a new userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). I think if the data is used to do the primary protocol decoding then it should be a separate interface that is processed by someone and then fed into input subsystem (either in-kernel or through uinput). Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for keys and buttons on all devices. Current lircd actually inter-operates with the input subsystem quite well for any and all supported remotes if their keys are mapped in their respective lircd.conf file using standard input subsystem key names, and the lirc daemon started with the --uinput param. lircd decodes the raw IR, finds the mapping in its config, and happily passes it along to uinput. -- 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
