What are the goals for the architecture of an in-kernel IR system?
in [Kernel]
|
Prev: [PATCH 2/3] sched: make tunable scaling style configurable
Next: [PATCH] pata_rdc: MWDMA0 is unsupported
From: Christoph Bartelmus on 6 Dec 2009 07:10 Hi Dmitry, on 04 Dec 09 at 15:15, Dmitry Torokhov wrote: [...] >>>>>> http://lirc.sourceforge.net/remotes/lg/6711A20015N >>>>>> >>>>>> This is an air-conditioner remote. >>>>>> The entries that you see in this config file are not really separate >>>>>> buttons. Instead the remote just sends the current settings for e.g. >>>>>> temperature encoded in the protocol when you press some up/down key. >>>>>> You really don't want to map all possible temperature settings to KEY_* >>>>>> events. For such cases it would be nice to have access at the raw scan >>>>>> codes from user space to do interpretation of the data. >>>>>> The default would still be to pass the data to the input layer, but it >>>>>> won't hurt to have the possibility to access the raw data somehow. >>>> >>>>> Interesting. IMHO, the better would be to add an evdev ioctl to return >>>>> the scancode for such cases, instead of returning the keycode. >>>> >>>> That means you would have to set up a pseudo keymap, so that you can get >>>> the key event which you could than react on with a ioctl. Or are you >>>> generating KEY_UNKNOWN for every scancode that is not mapped? >>>> What if different scan codes are mapped to the same key event? How do you >>>> retrieve the scan code for the key event? >>>> I don't think it can work this way. >>>> >> >>> EV_MSC/MSC_SCAN. >> >> How would I get the 64 bit scan codes that the iMON devices generate? >> How would I know that the scan code is 64 bit? >> input_event.value is __s32. >> > I suppose we could add MSC_SCAN_END event so that we can transmit > "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by > MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 > bit. And I set a timeout to know that no MSC_SCAN_END will arrive? This is broken design IMHO. Furthermore lircd needs to know the length of the scan code in bits, not as a multiple of 32. > FWIW there is MSC_RAW as well. It took me some time to convice people that this is not the right way to handle raw timing data. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Bartelmus on 6 Dec 2009 07:20 Hi Jon, on 04 Dec 09 at 19:28, Jon Smirl wrote: >> BTW, I just came across a XMP remote that seems to generate 3x64 bit >> scan codes. Anyone here has docs on the XMP protocol? > > Assuming a general purpose receiver (not one with fixed hardware > decoding), is it important for Linux to receive IR signals from all > possible remotes no matter how old or obscure? Or is it acceptable to [...] > Of course transmitting is a completely different problem, but we > haven't been talking about transmitting. I can see how we would need > to record any IR protocol in order to retransmit it. But that's in the > 5% of users world, not the 90% that want MythTV to "just work". Use > something like LIRC if you want to transmit. I don't think anyone here is in the position to be able to tell what is 90% or 5%. Personally I use LIRC exclusively for transmit to my settop box using an old and obscure RECS80 protocol. No, I won't replace my setup just because it's old and obscure. Cable companies tend to provide XMP based boxes to subscribers more often these days. Simply not supporting these setups is a no-go for me. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on 6 Dec 2009 12:30 Andy Walls <awalls(a)radix.net> writes: > Yes, I agree. I do not know what percentage of current Linux users are > technical vs non-technical, so I cannot gauge the current improtance. > > I can see the trend line though: as time goes by, the percentage of all > linux users that have a technical bent will only get smaller. This IMHO shouldn't matter. If users can configure their keymaps for e.g. games with a graphical utility (and they easily can), they can do the same with their remotes, at least with these using common sane protocols. The only thing needed is a good GUI utility. Ergo - it's not a kernel issue. The "default bundled", or PnP, won't work well in comparison to a GUI utility, I wouldn't worry about it too much (though adding it to udev and co is trivial and we should do it - even if not PnP but asking first about the actual remote used). -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on 6 Dec 2009 15:20 Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC extended protocol). > However, currently, the drivers were getting only 7 bits, due to the old way to implement > EVIO[S|G]KEYCODE. > > I know, however, one i2c chip that returns a 5 byte scancode when you press a key. > We're currently just discarding the remaining bits, so I'm not really sure what's there. Right. This will have to be investigated by owners of the exact hardware in question. What we can do is to try to make it easy for them. There is no hurry, though - it can and will continue to work the current way. > In general, the scancode contains 8 or 16 bits for address, and 8 bits for command. Right. I think the kernel shouldn't differentiate between address and command too much. > at include/linux/input.h, we'll add a code like: > > struct input_keytable_entry { > u16 index; > u64 scancode; > u32 keycode; > } __attribute__ ((packed)); > > (the attribute packed avoids needing a compat for 64 bits) Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a bit better, no alignment problems and we could eventually change "reserved" into something useful. But I think, if we are going to redesign it, we better use scancodes of arbitrary length (e.g. protocol-dependent length). It should be opaque except for the protocol handler. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on 6 Dec 2009 15:30
Jon Smirl <jonsmirl(a)gmail.com> writes: > The in-kernel support can start small and add protocols and maps over > time. Protocols, yes. Maps - we certainly don't want megatons of maps in the kernel. The existing ones have to be removed, some time. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |