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