Jon Smirl wrote: > On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa <khc@xxxxxxxxx> wrote: >> Once again: how about agreement about the LIRC interface >> (kernel-userspace) and merging the actual LIRC code first? That's fine for me. >> In-kernel >> decoding can wait a bit, it doesn't change any kernel-user interface. This may occur in parallel, but, as we've been discussing, there are still some needs there that will require kernel-user interfaces. > I'd like to see a semi-complete design for an in-kernel IR system > before anything is merged from any source. There are some tasks there that are independent of any API design. For example, I'm currently doing some cleanups and improvements at the existing IR in-kernel code to create a common IR core that replaces the already existing feature of handling 7-bits scancode/keycode table to use the complete scancodes found at the current in-kernel drivers. This approach works for the current drivers, as none of them currently support any protocol that requires more than 16 bits for scancodes. However, the current EVIOGKEYCODE implementation won't scale with bigger scancode spaces. This code is written to be generic enough to be used by V4L, DVB and LIRC drivers. So, after having this work done, it should be easy to connect the lirc_dev to a decoder and to this core support. There are already some in-kernel decoders that can be used for some protocols, but the better is to review the decoders in the light of lirc. I expect that the lirc decoders will be in a better shape. While I'm here, I intend also to create the sysfs bits to create sys/class/irrcv, as already discussed and submit the patch here for discussions. Of course, after writing different API's to control the IR tables, we'll need to improve it, but this depends on the results of the architecture discussions. Cheers, Mauro -- 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