Hi Andy, Am Sonntag, den 05.04.2009, 18:00 -0400 schrieb Andy Walls: > On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote: > > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare: > > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote: > > > > What can not be translated to the input system I would like to know. > > Andy seems to have closer looked into that. > > 1. IR blasting: sending IR codes to transmit out to a cable convertor > box, DTV to analog convertor box, or similar devices to change channels > before recording starts. An input interface doesn't work well for > output. > > 2. Sending raw IR samples to user space: user space applications can > then decode or match an unknown or non-standard IR remote protocol in > user space software. Timing information to go along with the sample > data probably needs to be preserved. I'm assuming the input interface > currently doesn't support that. > > That's all the Gerd mentioned. > > > One more nice feature to have, that I'm not sure how easily the input > system could support: > > 3. specifying remote control code to key/button translations with a > configuration file instead of recompiling a module. > > In effect there are actually two devices the ir-kbd-i2c input driver is > supporting in various combinations: an IR receiver and an IR remote. > > > Regards, > Andy > you always end up with something transmitting series of 0s and 1s. It does not matter if the medium is infrared, infradead ;), wireless or whats or ever. If it spares a chip for the remote and you have to get it from IRQs triggered, you have to do that. It could also be some voltage change, a ultrasound beeper or what ever. The first place for such is the input layer and nothing out of the kernel. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
