Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> 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?

lircd supports input layer interface. Yet, patch 3/3 exports both devices
that support only pulse/space raw mode and devices that generate scan
codes via the raw mode interface. It does it by generating artificial
pulse codes.
> 
>> 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.

It sounds an interesting idea.

>> 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.

Yet, both are RC5. This can already be handled by the input layer.
See dvb-usb implementation.

The issue I see is to support at the same time NEC and RC5 protocols. While
this may work with some devices, for others, the hardware won't allow.

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

This may work for protocols up to RC5, that uses either 8 or 16 bits.
However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits
for a scancode. So, we don't have spare bits to represent a protocol, 
if we consider RC6 mode 6 codes as well.

>> 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.

See above. Also, several protocols have a way to check if a keystroke were
properly received. When handling just one protocol, we can use this to double
check the key. However, on a multiprotocol mode, we'll need to disable this
feature.

PS.: For those following those discussions that want to know more about
IR protocols, a good reference is at:
	http://www.sbprojects.com/knowledge/ir/ir.htm

Unfortunately, it doesn't describe RC6 mode 6.

Cheers,
Mauro.