Maxim Levitsky [off-list ref] writes:

There are many protocols,

Few of them really popular.

There are many receivers, and all have different accuracy.

Receivers? Accuracy? What do you mean exactly?

Most remotes aren't designed to be used with PC, thus user has to invent
mapping between buttons and actions.

Of course. You can't change that. Being designed to be used with PC is
not relevant.

Its is not possible to identify remotes accurately, many remotes send
just a 8 bit integer that specifies the 'model' thus many remotes can
share it.

I have never seen a remote that sends "model" number.
But I admit I only used few universal (including programmable) and few
simple bundled remotes.

Some don't send anything.

How do they communicate with the receiver?

There are some weird remotes that send whole packet of data will all
kind of states.

Of course. This is called "encoding".

Think about it, video capture device is also an input device, a scanner
is an input device too, sound card can work as input device too.

But their primary function isn't passing keystrokes, is it?

Kernel job is to take the information from device and present it to
userspace using uniform format, that is kernel does 1:1 translating, but
doesn't parse the data.

Why do you think so?
This is less efficient, and more complicated. And would require
incompatible changes to drivers already in the kernel. Keyword:
"regression".

lirc is well capable to decode it, and its not hard to add
auto-detection based on existing configuration drivers, so IR devices
will work with absolutely no configuration.

Really? You don't know what you're talking about. Forget this idea,
there is absolutely no way to use this without prior configuration. You
can get as far as suggesting default "bundled" model, if there was
something bundled with the receiver of course.

Then as soon as you press a key, lirc can scan its config database, and
find a config file to use.

Forget it.

Also don't forget that there are pure userspace drivers. They won't have
access to in-kernel decoder so they will still have to parse protocols,
so will have code duplication, and will still need lirc thus.

This is not a problem. BTW I have nothing against lirc. It can get
keystrokes from input layer. That's the way I use it in fact.
-- 
Krzysztof Halasa