On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote: > On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@xxxxxxxxxx> wrote: >> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote: >>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> wrote: ... >>> > It has nothing to do with start bits. >>> > The Streamzap remote just sends 14 (sic!) bits instead of 13. >>> > The decoder expects 13 bits. >>> > Yes, the Streamzap remote does _not_ use standard RC-5. >>> > Did I mention this already? Yes. ;-) >>> >>> If the remote is sending a weird protocol then there are several choices: >>> 1) implement raw mode >>> 2) make a Stream-Zap protocol engine (it would be a 14b version of >>> RC-5). Standard RC5 engine will still reject the messages. >>> 3) throw away your Stream-Zap remotes >>> >>> I'd vote for #3, but #2 will probably make people happier. >> >> Hm. Yeah, I know a few people who are quite attached to their Streamzap >> remotes. I'm not a particularly big fan of it, I only got the thing off >> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is >> probably not the best route. But I don't know that I'm a huge fan of #2 >> either. Another decoder engine just for one quirky remote seems excessive, >> and there's an option #4: >> >> 4) just keep passing data out to lirc by default. > > That's a decent idea. Implement the mainstream, standard protocols in > the kernel and kick the weird stuff out to LIRC. We can avoid the > whole world of raw mode, config files, etc. Let LIRC deal with all > that. If the weird stuff gets enough users bring it in-kernel. Maybe > StreamZap will suddenly sell a million units, you never know. > > It is easy to implement a StreamZap engine. Just copy the RC5 one. > Rename everything and adjust it to require one more bit. You'll have > to modify the RC5 to wait for a bit interval (timeout) before sending > the data up. If you want to get fancy use a weak symbol in the > StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then > you can decide to wait the extra bit interval or not. The other thought I had was to not load the engine by default, and only auto-load it from the streamzap driver itself. >> Let lircd handle the default remote in this case. If you want to use >> another remote that actually uses a standard protocol, and want to use >> in-kernel decoding for that, its just an ir-keytable call away. >> >> For giggles, I may tinker with implementing another decoder engine though, >> if only to force myself to actually pay more attention to protocol >> specifics. For the moment, I'm inclined to go ahead with the streamzap >> port as it is right now, and include either an empty or not-empty, but >> not-functional key table. So I spent a while beating on things the past few nights for giggles (and for a sanity break from "vacation" with too many kids...). I ended up doing a rather large amount of somewhat invasive work to the streamzap driver itself, but the end result is functional in-kernel decoding, and lirc userspace decode continues to behave correctly. RFC patch here: http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch Core changes to streamzap.c itself: - had to enable reporting of a long space at the conclusion of each signal (which is what the lirc driver would do w/timeout_enabled set), otherwise I kept having issues with key bounce and/or old data being buffered (i.e., press up, cursor moves up. push down, cursor moves up then down, press left, it moves down, then left, etc.). Still not quite sure what the real problem is there, the lirc userspace decoder has no problems with it either way. - removed streamzap's internal delay buffer, as the ir-core kfifo seems to provide the necessary signal buffering just fine by itself. Can't see any significant difference in decode performance either in-kernel or via lirc with it removed, anyway. (Christoph, can you perhaps expand a bit on why the delay buffer was originally needed/how to reproduce the problem it was intended to solve? Maybe I'm just not triggering it yet.) Other fun stuff to note: - currently, loading up an rc5-sz decoder unconditionally, have considered only auto-loading it from the streamzap driver itself. Its a copy of the rc5 decoder with relatively minor tweaks to deal with the extra bit and resulting slightly different bit layout. Might actually be possible to merge back into the rc5 decoder itself, haven't really looked into that yet (should be entirely doable if there's an easy way to figure out early on if we need to grab 15 bits). - not sure the decoder is 100% correct, but it does get to the same scancodes as the lirc userspace now (with both a streamzap and mceusb receiver). -- Jarod Wilson jarod@xxxxxxxxxxxx -- 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
