Re: [PATCH 3/4] ir-core: move decoding state to ir_raw_event_ctrl

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

 



On Wed, Jun 9, 2010 at 2:15 PM, Jarod Wilson <jarod@xxxxxxxxxx> wrote:
> On Wed, Jun 09, 2010 at 07:56:21PM +0200, David Härdeman wrote:
>> On Wed, Jun 09, 2010 at 09:29:08AM -0400, Jarod Wilson wrote:
...
>> > So this definitely negatively impacts my ir-core-to-lirc_dev
>> > (ir-lirc-codec.c) bridge driver, as it was doing the lirc_dev device
>> > registration work in its register function. However, if (after your
>> > patchset) we add a new pair of callbacks replacing raw_register and
>> > raw_unregister, which are optional, that work could be done there instead,
>> > so I don't think this is an insurmountable obstacle for the lirc bits.
>>
>> While I'm not sure exactly what callbacks you're suggesting,
>
> Essentially:
>
> .setup_other_crap
> .tear_down_other_crap
>
> ...which in the ir-lirc-codec case, register ir-lirc-codec for a specific
> hardware receiver as an lirc_dev client, and conversely, tear it down.
>
>> it still
>> sounds like the callbacks would have the exact same problems that the
>> current code has (i.e. the decoder will be blissfully unaware of
>> hardware which exists before the decoder is loaded). Right?
>
> In my head, this was going to work out, but you're correct, I still have
> the exact same problem -- its not in ir_raw_handler_list yet when
> ir_raw_event_register runs, and thus the callback never fires, so lirc_dev
> never actually gets wired up to ir-lirc-codec. It now knows about the lirc
> decoder, but its completely useless. Narf.

And now I have it working atop your patches. Its a bit of a nasty-ish
hack, at least for the lirc case, but its working, even in the case
where the decoder drivers aren't actually loaded until after the
device driver. I've added one extra param to each protocol-specific
struct in ir-core-priv.h (bool initialized) and hooked into the
protocol-specific decode functions to both determine whether a
protocol should be enabled or disabled by default, and to run any
additionally required initialization (such as in the ir-lirc-codec
case).

So initially, mceusb comes up with all decoders enabled. Then when ir
comes in, every protocol-specific decoder fires. Each of them check
for whether or not they've been fully initialized, and if not, we
check the loaded keymap, and if it doesn't match, we disable that
decoder (bringing back the "disable protocol handlers we don't need"
functionality that disappeared w/this patchset). In the lirc case, we
actually do all the work needed to wire up the connection over to
lirc_dev.

This works perfectly fine for all the in-kernel decoders, but has one
minor shortcoming for ir-lirc-codec, in that /dev/lirc0 won't actually
exist until the first incoming ir signal is seen. lircd can handle
this case just fine, it'll wait for /dev/lirc0 to show up, but it
doesn't come up fast enough to catch and decode the very first
incoming ir signal. Subsequent ones work perfectly fine though. This
need to initialize the link via incoming ir is a bit problematic if
you're using a device for transmit-only (e.g., and mceusb device
hooked to a mythtv backend in the closet or something), as there would
be a strong possibility of /dev/lirc0 never getting hooked up. I can
think of a few workarounds, but none are particularly clean and/or
automagic.

Not sure how palatable it is, but here it is:

http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=commitdiff;h=8f2be576ecb82448daa0c0d789bf0c978c66b103


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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux