Kernel support for infrared receivers

I have dealt with the devices (and I wrote the winbond-cir.c driver which is in the 2.6.32 kernel).

There aren't nearly as many protocols as you seem to think, especially not if you weigh the different protocols by market share. Providing in-kernel decoders for RC5, RC6, Sony12/15/20 and NEC(x)1/2 would mean that the vast majority of all remotes you're likely to find in someone's home would work out-of-the-box (for less than 20k of code). It would be easy to support further protocols by providing an additional kernel module if size is an issue.

Saying that the kernel should have no protocol understanding because you might wish to decode the signals from the remote to your 1976 airconditioner using a diode hooked to the mic connector on your soundcard sound to me like saying TCP/IP and the e1000 driver shouldn't be in the kernel because you might want to run SNA/SDLC over your homebrew hardware connected to a serial port (hint, you can - from userspace).

It's not like LIRC is a magic solution that can decode every single protocol either, some protocols will require a very high frequency sampling for a robust decode, which means hardware will have to be setup in advance, which in turn means that you need to know in advance which mode you want the hardware to operate in...LIRC doesn't have any framework for that as far as I know.

In-kernel decoding means that you abstract away the differences between hardware that does the decoding for you and hardware which doesn't (which sounds like a perfect description of why we want device drivers in the first place - to abstract away hardware differences).

Finally, if you do have a truly bizarre remote, the ability to decode raw signals in userspace isn't something any of the people discussing in-kernel LIRC want to remove - they just want to provide something which is more user-friendly in the vast majority of cases.