Re: Remote that breaks current system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> wrote:
...
>> 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.

Cool, sounds like a plan then, I'll go ahead with it.

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

Hm. Was afraid of that. I gave it a shot to see if I could make that
work, pretty shaky results. About 2/3 of the keys get decoded as
15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't
match anything in the keytable (and often duplicate one another). So
it looks like at least for the time being, a separate parallel decoder
is the way to go. I'm thinking that I like the approach of only
explicitly loading it from the streamzap driver though.

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


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux