On Wed, Apr 7, 2010 at 9:29 AM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: > On the implementation I did, each event is passed to each decoder serialized (yet, as one keystroke > is a series of events, it behaves as if they are processed in parallel). We might create separate > kthreads for each decoder, and use a spinlock at kfifo, but I suspect that the end result will be > very close and we'll have more threads interfering at the samples collect, especially on those > (broken) hardware that don't have IRQ's to indicate a state transition, so the driver needs > to poll the samples. Polling should be the driver's problem. They can set up a timer interrupt and do it that way. Do all of the protocols have a long enough lead one for a timer tick to catch them? If so, look for it in the timer event, then go into a polling loop. You'd be way better off buying new hardware since your video is going to stop while this pooling loop runs. Do modern serial ports interrupt on DTR or whatever those Iguana devices use? What is an example of a polled input device? I can't think of one, even IR diode on mic input is interrupt driven (that require a special ALSA driver to pass the data into RC core). No need to use different kthreads for each protocol decoder, but don't lock up the default kernel thread waiting for a user space response. What I meant by parallel was that pulses are fed one at a time into each of the decoders, don't wait for a long space and then feed the entire message into the decoders. > > -- > > Cheers, > Mauro > -- Jon Smirl jonsmirl@xxxxxxxxx -- 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
