On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote: > On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky > <maximlevitsky@xxxxxxxxx> wrote: > > On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote: > >> Maxim Levitsky <maximlevitsky@xxxxxxxxx> writes: > >> > >> >> And that's good. Especially for a popular and simple protocol such as > >> >> RC5. > >> >> Actually, it's not about adding the decoder. It's about fixing it. > >> >> I can fix it. > >> > > >> > This is nonsense. > >> > >> You forgot to say why do you think so. > > > > Because frankly, I am sick of this discussion. > > Generic decoder that lirc has is actually much better and more tolerant > > that protocol specific decoders that you propose, > > Porting the decoder engine from lirc into the kernel is also a possibility. > > I'm asking to have an architecture design discussion, not to pick one > of the various implementations. This is something that we have to live > with for twenty years and it is a giant pain to change if we get wrong > initially. > > > You claim you 'fix' the decoder, right? > > But what about all these lirc userspace drivers? > > How they are supposed to use that 'fixed' decoder. > > Some of that user space hardware belongs in the trash can and will > never work reliably in a modern system. For example - sitting in a > tight user space loop reading the DTS bit from a serial port or > parallel port and then using the system clock to derive IR timings. > That process is going to be inaccurate or it is going to make video > frames drop. Big banging from user space is completely unreliable. > > If you really want to use your microphone input as a DAC channel, run > a little app that reads the ALSA input and converts it to a timing > stream and then inject this data into the kernel input system using > uevent. > > Both of these are hobbyist class solutions. They are extremely cheap > but they are unreliable and create large CPU loads. But some people > want to use a $300 CPU to eliminate $2 worth of IR hardware. This type > of hardware will continue to work via event injection. But neither of > these solutions belong in the kernel. > > What are other examples of user space IR drivers? > many libusb based drivers? Regards, Maxim Levitsky -- 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
