Mauro Carvalho Chehab [off-list ref] writes:

If you see patch 3/3, of the lirc submission series, you'll notice a driver
that has hardware decoding, but, due to lirc interface, the driver generates
pseudo pulse/space code for it to work via lirc interface.

IOW the driver generates artificial pulse code for lircd?
I think - pure bloat. lircd can get events from input layer without
problems. Perhaps I misunderstood?

It is very bad to have two interfaces for the same thing, because people
may do things like that.

I think having a "raw" scan code interface + the key code "cooked" mode
is beneficial. For remotes lacking the raw interface only the latter
could be used.

Also, there are some cases where the same V4L driver can receive IR scancodes
directly for one board, while for others, it needs to get pulse/space
decoding.

Sure.

This is an interesting discussion. We currently have lots of such tables in
kernel, but it can be a good idea to have it loaded by udev during
boot time.

Sure.

Are you meaning that we should do more than one RC per input event
interface?

I think so. Why not?

For example, one of my remotes generates codes from at least two RC5
groups (in only one "mode"). Currently a remote is limited to only one
RC5 group.

I think the mapping should be: key = proto + group + raw code, while
key2 could be different_proto + different group (if any) + another code.

If so, why do you think we need to handle more than one IR protocol at
the same time?

Why not?
There are X-in-1 remotes on the market for years. They can "speak" many
protocols at once. One may want to have a protocol to handle DVD apps
while another for DVB etc.
And someone may want to use several different remotes, why not?
Personally I use two different remotes (both set to speak RC5 but what
if I couldn't set the protocol?). Sure, it requires a bit of hackery
(not with pulse code and lircd).

I think this will just make the driver more complex without need.

Not much more, and there is a need.
-- 
Krzysztof Halasa