Re: Remote that breaks current system

[lirc@bartelmus.de (Christoph Bartelmus)]

Hi Jarod,

on 11 Aug 10 at 10:38, Jarod Wilson wrote:
> On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> 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@bartelmus.de>
>>>> 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.)

Should be fine. Current lircd with timeout support shouldn't have a  
problem with that anymore. I was already thinking of suggesting to remove  
the delay buffer.

>
> 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 14
> bits).

There is no way until you see the 14th bit.

> - 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).

Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html