Christoph Bartelmus wrote:

Hi Mauro,

I just don't want to change a working interface just because it could be  
also implemented in a different way, but having no other visible advantage  
than using more recent kernel features.

I agree. The main reasons to review the interface is:
	1) to avoid any overlaps (if are there any) with the evdev interface;
	2) to have it stable enough to be used, without changes, for a long
	   time.

quoted

I haven't seen such limitations on his proposal. We currently have in-kernel
decoders for NEC, pulse-distance, RC4 protocols, and some variants. If
non-RC5 decoders are missing, we need for sure to add them.

That was not my point. If you point a NEC remote at the Igor USB device,  
you won't be able to use a NEC decoder because the device will swallow  
half of the bits. LIRC won't care unless the resulting scancodes are  
identical.

If the difference is just the bits order, and assuming that we use a standard
NEC decoder, a (kernel) driver will simply provide a different scancode for
that device, and the keymap table will be different, but it will still work
(an can still be plug and play).

In this specific case, we can opt to simply don't add any special hack for
Igor USB at the driver, but to leting the userspace tool to invert the bits
order when loading the keymap for that device.

quoted

Providing that we agree on what we'll do, I don't see why not
adding it on staging for 2.6.33 and targeting to have
everything done for 2.6.34 or 2.6.35.

The problem that I see here is just that even when we have very talented  
people working on this, that put together all resources, we won't be able  
to cover all the corner cases with all the different receivers and remote  
control protocols out there. It will still require lots of fine-tuning  
which was done in LIRC over the years.

True, but even if we want to merge lirc drivers "as-is", the drivers will
still need changes, due to kernel CodingStyle, due to the usage of some API's
that may be deprecated, due to some breakage with non-Intel architectures, due
to some bugs that kernel hackers may discover, etc. 

Also, there will be the needs for integrating with V4L/DVB code that may
also require some changes.

So, the drivers will still be different than what you currently have
and they may still need some fine-tuning after the merge.

Cheers,
Mauro