Hi Dmitry,

On Fri, Sep 23, 2016 at 03:08:31PM -0700, Dmitry Torokhov wrote:

On Thu, Sep 22, 2016 at 11:57:13AM -0300, Mauro Carvalho Chehab wrote:

quoted

Em Wed, 21 Sep 2016 10:54:21 +0100
Sean Young [off-list ref] escreveu:

quoted

We might want to know what protocol a remote uses when we do not know. With
this patch and another patch for v4l-utils (follows), you can do that with:

./ir-keytable  -p rc-5,nec,rc-6,jvc,sony,sanyo,sharp,xmp -t
Testing events. Please, press CTRL-C to abort.
1474415431.689685: event type EV_MSC(0x04): protocol = RC_TYPE_RC6_MCE
1474415431.689685: event type EV_MSC(0x04): scancode = 0x800f040e
1474415431.689685: event type EV_SYN(0x00).

This makes RC_TYPE_* part of the ABI. We also remove the enum rc_type,
since in input-event-codes.h we cannot not use enums.

In addition, now that the input layer knows the rc protocol and scancode,
at a later point we could add a feature where keymaps could be created
based on both protocol and scancode, not just scancode.

We need Dmitry's ack in order to apply this one.

I'd rather not: I am trying to keep input API hardware-independent and
the kind of device emitting keycodes (a remote control in the sense of
drivers/media/rc or USB device or BT device) should not really matter to
consumers. Similarly how we do not export whether device is USB1.1 or
USB2 or USB3 (although we do have input->id.bustype, but it is more for
identification purposes rather than for adjusting properties).

Keyboards produce device dependant scancodes; the only output RC devices 
have is protocol and scancode. The scancode is already being sent to
the input layer, and if we can't send the rc protocol to the input layer
we would need a new char device just for that, which is complete overkill.

Alternatively we can put the rc protocol type in MSC_RAW, MSC_SERIAL or
ABS_MISC or one of the other existing device dependant input codes. 

For configuration (like loading keymaps) we can examine
parent hardware device and decide.

Unfortunately there is nothing to examine there. The usb device of an 
infrared receiver will tell you nothing about the remote the user is
using.

It would be really helpful if this could be merged; I don't know what
other solution there is to this problem.


Sean