Trying to use IR driver for my SoC

Trying to use IR driver for my SoC

[Mason]

Hello,

I'm trying to use an IR driver written for my SoC:
https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c

I added these options to my defconfig:

+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_DEVICES=y
+CONFIG_IR_TANGO=y

(I don't think I need the RC decoders, because the HW is supposed
to support HW decoding of NEC, RC5, RC6).

These are the logs printed at boot:

[    1.827842] IR NEC protocol handler initialized
[    1.832407] IR RC5(x/sz) protocol handler initialized
[    1.837491] IR RC6 protocol handler initialized
[    1.842049] IR JVC protocol handler initialized
[    1.846606] IR Sony protocol handler initialized
[    1.851248] IR SANYO protocol handler initialized
[    1.855979] IR Sharp protocol handler initialized
[    1.860708] IR MCE Keyboard/mouse protocol handler initialized
[    1.866575] IR XMP protocol handler initialized
[    1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21
[    1.878241] Registered IR keymap rc-empty
[    1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0
[    1.889473] tango_ir_open
[    1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0


I was naively expecting some kind of dev/input/event0 node
I could cat to grab all the remote control key presses.

But I don't see anything relevant in /dev

/sys/devices/platform/soc/10518.ir/rc/rc0/input0$ ls -l
total 0
drwxr-xr-x    2 root     root             0 Jan  1 00:00 capabilities
lrwxrwxrwx    1 root     root             0 Jan  1 00:07 device -> ../../rc0
drwxr-xr-x    2 root     root             0 Jan  1 00:07 id
-r--r--r--    1 root     root          4096 Jan  1 00:07 modalias
-r--r--r--    1 root     root          4096 Jan  1 00:00 name
-r--r--r--    1 root     root          4096 Jan  1 00:07 phys
-r--r--r--    1 root     root          4096 Jan  1 00:00 properties
lrwxrwxrwx    1 root     root             0 Jan  1 00:07 subsystem -> ../../../../../../../class/input
-rw-r--r--    1 root     root          4096 Jan  1 00:00 uevent
-r--r--r--    1 root     root          4096 Jan  1 00:07 uniq

$ cat *
cat: read error: Is a directory
cat: read error: Is a directory
cat: read error: Is a directory
input:b0000v0000p0000e0000-e0,1,4,14,k98,ram4,lsfw
tango-ir
tango-ir/input0
0
cat: read error: Is a directory
PRODUCT=0/0/0/0
NAME="tango-ir"
PHYS="tango-ir/input0"
PROP=0
EV=100013
KEY=1000000 0 0 0 0
MSC=10
MODALIAS=input:b0000v0000p0000e0000-e0,1,4,14,k98,ram4,lsfw


The IR interrupt count remains at 0, even I use the RC nearby.
(It works in a legacy system, using a different driver.)


I suppose I am missing some important piece of the puzzle?
I hope someone can point me in the right direction.

Regards.

Re: Trying to use IR driver for my SoC

[Mason]

On 29/06/2017 17:29, Mason wrote:

> I suppose I am missing some important piece of the puzzle?
> I hope someone can point me in the right direction.

FWIW,

$ ir-keytable -v
Found device /sys/class/rc/rc0/
Input sysfs node is /sys/class/rc/rc0/input0/
Couldn't find any node at /sys/class/rc/rc0/input0/event*.
Segmentation fault

$ ir-keytable --version
IR keytable control version 1.12.2

Regards.

Re: Trying to use IR driver for my SoC

[Sean Young]

Hello,

On Thu, Jun 29, 2017 at 05:29:01PM +0200, Mason wrote:
> I'm trying to use an IR driver written for my SoC:
> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c
> 
> I added these options to my defconfig:
> 
> +CONFIG_MEDIA_SUPPORT=y
> +CONFIG_MEDIA_RC_SUPPORT=y
> +CONFIG_RC_DEVICES=y
> +CONFIG_IR_TANGO=y
> 
> (I don't think I need the RC decoders, because the HW is supposed
> to support HW decoding of NEC, RC5, RC6).

I haven't seen this driver before, what hardware is this for?

> These are the logs printed at boot:
> 
> [    1.827842] IR NEC protocol handler initialized
> [    1.832407] IR RC5(x/sz) protocol handler initialized
> [    1.837491] IR RC6 protocol handler initialized
> [    1.842049] IR JVC protocol handler initialized
> [    1.846606] IR Sony protocol handler initialized
> [    1.851248] IR SANYO protocol handler initialized
> [    1.855979] IR Sharp protocol handler initialized
> [    1.860708] IR MCE Keyboard/mouse protocol handler initialized
> [    1.866575] IR XMP protocol handler initialized
> [    1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21
> [    1.878241] Registered IR keymap rc-empty
> [    1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0
> [    1.889473] tango_ir_open
> [    1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0
> 
> 
> I was naively expecting some kind of dev/input/event0 node
> I could cat to grab all the remote control key presses.
> 
> But I don't see anything relevant in /dev

Do you have CONFIG_INPUT_EVDEV set? Is udev setup to create the devices?
 
> /sys/devices/platform/soc/10518.ir/rc/rc0/input0$ ls -l
> total 0
> drwxr-xr-x    2 root     root             0 Jan  1 00:00 capabilities
> lrwxrwxrwx    1 root     root             0 Jan  1 00:07 device -> ../../rc0
> drwxr-xr-x    2 root     root             0 Jan  1 00:07 id
> -r--r--r--    1 root     root          4096 Jan  1 00:07 modalias
> -r--r--r--    1 root     root          4096 Jan  1 00:00 name
> -r--r--r--    1 root     root          4096 Jan  1 00:07 phys
> -r--r--r--    1 root     root          4096 Jan  1 00:00 properties
> lrwxrwxrwx    1 root     root             0 Jan  1 00:07 subsystem -> ../../../../../../../class/input
> -rw-r--r--    1 root     root          4096 Jan  1 00:00 uevent
> -r--r--r--    1 root     root          4096 Jan  1 00:07 uniq
> 
> $ cat *
> cat: read error: Is a directory
> cat: read error: Is a directory
> cat: read error: Is a directory
> input:b0000v0000p0000e0000-e0,1,4,14,k98,ram4,lsfw
> tango-ir
> tango-ir/input0
> 0
> cat: read error: Is a directory
> PRODUCT=0/0/0/0
> NAME="tango-ir"
> PHYS="tango-ir/input0"
> PROP=0
> EV=100013
> KEY=1000000 0 0 0 0
> MSC=10
> MODALIAS=input:b0000v0000p0000e0000-e0,1,4,14,k98,ram4,lsfw
> 
> 
> The IR interrupt count remains at 0, even I use the RC nearby.
> (It works in a legacy system, using a different driver.)

By opening the /dev/input/event0 device, tango_ir_open() gets called which
presumably enables interrupts or IR decoding for the device. It's hard to
say without knowing anything about the soc.

It would be nice to see this driver merged to mainline.


Sean

Re: Trying to use IR driver for my SoC

[Mason]

Hello,

On 29/06/2017 17:55, Sean Young wrote:

> On Thu, Jun 29, 2017 at 05:29:01PM +0200, Mason wrote:
> 
>> I'm trying to use an IR driver written for my SoC:
>> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c
>>
>> I added these options to my defconfig:
>>
>> +CONFIG_MEDIA_SUPPORT=y
>> +CONFIG_MEDIA_RC_SUPPORT=y
>> +CONFIG_RC_DEVICES=y
>> +CONFIG_IR_TANGO=y
>>
>> (I don't think I need the RC decoders, because the HW is supposed
>> to support HW decoding of NEC, RC5, RC6).
> 
> I haven't seen this driver before, what hardware is this for?

Sigma Designs tango3/tango4 (SMP86xx and SMP87xx)

>> These are the logs printed at boot:
>>
>> [    1.827842] IR NEC protocol handler initialized
>> [    1.832407] IR RC5(x/sz) protocol handler initialized
>> [    1.837491] IR RC6 protocol handler initialized
>> [    1.842049] IR JVC protocol handler initialized
>> [    1.846606] IR Sony protocol handler initialized
>> [    1.851248] IR SANYO protocol handler initialized
>> [    1.855979] IR Sharp protocol handler initialized
>> [    1.860708] IR MCE Keyboard/mouse protocol handler initialized
>> [    1.866575] IR XMP protocol handler initialized
>> [    1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21
>> [    1.878241] Registered IR keymap rc-empty
>> [    1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0
>> [    1.889473] tango_ir_open
>> [    1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0
>>
>>
>> I was naively expecting some kind of dev/input/event0 node
>> I could cat to grab all the remote control key presses.
>>
>> But I don't see anything relevant in /dev
> 
> Do you have CONFIG_INPUT_EVDEV set? Is udev setup to create the devices?

I was indeed missing CONFIG_INPUT_EVDEV.

As for udev:
[    2.199642] udevd[960]: starting eudev-3.2.1

$ ls -l /dev/input/
total 0
drwxr-xr-x    2 root     root            60 Jan  1 00:00 by-path
crw-rw----    1 root     input      13,  64 Jan  1 00:00 event0

But still no cookie:
$ cat /dev/input/event0
remains mute :-(

$ ir-keytable -v -t
Found device /sys/class/rc/rc0/
Input sysfs node is /sys/class/rc/rc0/input0/
Event sysfs node is /sys/class/rc/rc0/input0/event0/
Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
/sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
/sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
/sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-empty
input device is /dev/input/event0
/sys/class/rc/rc0/protocols protocol rc-5 (disabled)
/sys/class/rc/rc0/protocols protocol nec (disabled)
/sys/class/rc/rc0/protocols protocol rc-6 (disabled)
Opening /dev/input/event0
Input Protocol version: 0x00010001
Testing events. Please, press CTRL-C to abort.
^C

Is rc-empty perhaps not the right choice?

> By opening the /dev/input/event0 device, tango_ir_open() gets called which
> presumably enables interrupts or IR decoding for the device. It's hard to
> say without knowing anything about the soc.

Actually tango_ir_open() is called at boot, before any process
has a chance to open /dev/input/event0

[    1.926730] [<c03cd9a4>] (tango_ir_open) from [<c03c8554>] (rc_open+0x44/0x6c)
[    1.933994] [<c03c8554>] (rc_open) from [<c03be890>] (input_open_device+0x74/0xac)
[    1.941610] [<c03be890>] (input_open_device) from [<c032f96c>] (kbd_connect+0x64/0x80)
[    1.949570] [<c032f96c>] (kbd_connect) from [<c03bf0dc>] (input_attach_handler+0x1bc/0x1f4)
[    1.957965] [<c03bf0dc>] (input_attach_handler) from [<c03bf58c>] (input_register_device+0x3b4/0x42c)
[    1.967234] [<c03bf58c>] (input_register_device) from [<c03c9be8>] (rc_register_device+0x2d8/0x52c)
[    1.976327] [<c03c9be8>] (rc_register_device) from [<c03cdcfc>] (tango_ir_probe+0x328/0x3a4)
[    1.984815] [<c03cdcfc>] (tango_ir_probe) from [<c03508b0>] (platform_drv_probe+0x34/0x6c)
[    1.993124] [<c03508b0>] (platform_drv_probe) from [<c034f360>] (really_probe+0x1c4/0x250)

But I have a printk in the ISR, and it's obviously not called.

> It would be nice to see this driver merged to mainline.

+1 (especially if I can get it to work)

Regards.

Re: Trying to use IR driver for my SoC

[Sean Young]

On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote:
> On 29/06/2017 17:55, Sean Young wrote:
> 
> > On Thu, Jun 29, 2017 at 05:29:01PM +0200, Mason wrote:
> > 
> >> I'm trying to use an IR driver written for my SoC:
> >> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c
> >>
> >> I added these options to my defconfig:
> >>
> >> +CONFIG_MEDIA_SUPPORT=y
> >> +CONFIG_MEDIA_RC_SUPPORT=y
> >> +CONFIG_RC_DEVICES=y
> >> +CONFIG_IR_TANGO=y
> >>
> >> (I don't think I need the RC decoders, because the HW is supposed
> >> to support HW decoding of NEC, RC5, RC6).
> > 
> > I haven't seen this driver before, what hardware is this for?
> 
> Sigma Designs tango3/tango4 (SMP86xx and SMP87xx)
> 
> >> These are the logs printed at boot:
> >>
> >> [    1.827842] IR NEC protocol handler initialized
> >> [    1.832407] IR RC5(x/sz) protocol handler initialized
> >> [    1.837491] IR RC6 protocol handler initialized
> >> [    1.842049] IR JVC protocol handler initialized
> >> [    1.846606] IR Sony protocol handler initialized
> >> [    1.851248] IR SANYO protocol handler initialized
> >> [    1.855979] IR Sharp protocol handler initialized
> >> [    1.860708] IR MCE Keyboard/mouse protocol handler initialized
> >> [    1.866575] IR XMP protocol handler initialized
> >> [    1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21
> >> [    1.878241] Registered IR keymap rc-empty
> >> [    1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0
> >> [    1.889473] tango_ir_open
> >> [    1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0
> >>
> >>
> >> I was naively expecting some kind of dev/input/event0 node
> >> I could cat to grab all the remote control key presses.
> >>
> >> But I don't see anything relevant in /dev
> > 
> > Do you have CONFIG_INPUT_EVDEV set? Is udev setup to create the devices?
> 
> I was indeed missing CONFIG_INPUT_EVDEV.
> 
> As for udev:
> [    2.199642] udevd[960]: starting eudev-3.2.1
> 
> $ ls -l /dev/input/
> total 0
> drwxr-xr-x    2 root     root            60 Jan  1 00:00 by-path
> crw-rw----    1 root     input      13,  64 Jan  1 00:00 event0
> 
> But still no cookie:
> $ cat /dev/input/event0
> remains mute :-(
> 
> $ ir-keytable -v -t
> Found device /sys/class/rc/rc0/
> Input sysfs node is /sys/class/rc/rc0/input0/
> Event sysfs node is /sys/class/rc/rc0/input0/event0/
> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
> Parsing uevent /sys/class/rc/rc0/uevent
> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
> input device is /dev/input/event0
> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
> /sys/class/rc/rc0/protocols protocol nec (disabled)
> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
> Opening /dev/input/event0
> Input Protocol version: 0x00010001
> Testing events. Please, press CTRL-C to abort.
> ^C
> 
> Is rc-empty perhaps not the right choice?

rc-empty means there is no mapping from scancode to keycode. When you
run "ir-keytable -v -t" you should at see scancodes when the driver
generates them with rc_keydown().

> > By opening the /dev/input/event0 device, tango_ir_open() gets called which
> > presumably enables interrupts or IR decoding for the device. It's hard to
> > say without knowing anything about the soc.
> 
> Actually tango_ir_open() is called at boot, before any process
> has a chance to open /dev/input/event0
> 
> [    1.926730] [<c03cd9a4>] (tango_ir_open) from [<c03c8554>] (rc_open+0x44/0x6c)
> [    1.933994] [<c03c8554>] (rc_open) from [<c03be890>] (input_open_device+0x74/0xac)
> [    1.941610] [<c03be890>] (input_open_device) from [<c032f96c>] (kbd_connect+0x64/0x80)
> [    1.949570] [<c032f96c>] (kbd_connect) from [<c03bf0dc>] (input_attach_handler+0x1bc/0x1f4)
> [    1.957965] [<c03bf0dc>] (input_attach_handler) from [<c03bf58c>] (input_register_device+0x3b4/0x42c)
> [    1.967234] [<c03bf58c>] (input_register_device) from [<c03c9be8>] (rc_register_device+0x2d8/0x52c)
> [    1.976327] [<c03c9be8>] (rc_register_device) from [<c03cdcfc>] (tango_ir_probe+0x328/0x3a4)
> [    1.984815] [<c03cdcfc>] (tango_ir_probe) from [<c03508b0>] (platform_drv_probe+0x34/0x6c)
> [    1.993124] [<c03508b0>] (platform_drv_probe) from [<c034f360>] (really_probe+0x1c4/0x250)

Ah, that's interesting. The vt console taking a feed from the device, that
makes sense.

> But I have a printk in the ISR, and it's obviously not called.

>From a cursory glance at the driver I can't see anything wrong.

The only thing that stands out is RC5_TIME_BASE. If that is the bit
length or shortest pulse/space? In the latter case it should be 888 usec.

It might be worth trying nec, rc5 and rc6_0 and seeing if any of them decode.

Failing that some documentation would be great :)

> > It would be nice to see this driver merged to mainline.
> 
> +1 (especially if I can get it to work)


Sean

Re: Trying to use IR driver for my SoC

[Mason]

On 29/06/2017 19:50, Sean Young wrote:

> On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote:
>
>> $ ir-keytable -v -t
>> Found device /sys/class/rc/rc0/
>> Input sysfs node is /sys/class/rc/rc0/input0/
>> Event sysfs node is /sys/class/rc/rc0/input0/event0/
>> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
>> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
>> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
>> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
>> Parsing uevent /sys/class/rc/rc0/uevent
>> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
>> input device is /dev/input/event0
>> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
>> /sys/class/rc/rc0/protocols protocol nec (disabled)
>> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)

I had overlooked this. Is it expected for these protocols
to be marked as "disabled"?

>> Opening /dev/input/event0
>> Input Protocol version: 0x00010001
>> Testing events. Please, press CTRL-C to abort.
>> ^C
>>
>> Is rc-empty perhaps not the right choice?
> 
> rc-empty means there is no mapping from scancode to keycode. When you
> run "ir-keytable -v -t" you should at see scancodes when the driver
> generates them with rc_keydown().

So the mapping can be done either in the kernel, or in
user-space by the application consuming the scancodes,
right?

> From a cursory glance at the driver I can't see anything wrong.
> 
> The only thing that stands out is RC5_TIME_BASE. If that is the bit
> length or shortest pulse/space? In the latter case it should be 888 usec.

Need to locate some docs.

> It might be worth trying nec, rc5 and rc6_0 and seeing if any of them decode.

What do you mean? How do I try them?

> Failing that some documentation would be great :)

I will try finding some.

Regards.

Re: Trying to use IR driver for my SoC

[Sean Young]

On Thu, Jun 29, 2017 at 09:12:48PM +0200, Mason wrote:
> On 29/06/2017 19:50, Sean Young wrote:
> 
> > On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote:
> >
> >> $ ir-keytable -v -t
> >> Found device /sys/class/rc/rc0/
> >> Input sysfs node is /sys/class/rc/rc0/input0/
> >> Event sysfs node is /sys/class/rc/rc0/input0/event0/
> >> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
> >> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
> >> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
> >> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
> >> Parsing uevent /sys/class/rc/rc0/uevent
> >> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
> >> input device is /dev/input/event0
> >> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
> >> /sys/class/rc/rc0/protocols protocol nec (disabled)
> >> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
> 
> I had overlooked this. Is it expected for these protocols
> to be marked as "disabled"?

Ah, good point, I forgot about that. :/

"ir-keytable -p all -t -v" should enable all protocols and test.

> >> Opening /dev/input/event0
> >> Input Protocol version: 0x00010001
> >> Testing events. Please, press CTRL-C to abort.
> >> ^C
> >>
> >> Is rc-empty perhaps not the right choice?
> > 
> > rc-empty means there is no mapping from scancode to keycode. When you
> > run "ir-keytable -v -t" you should at see scancodes when the driver
> > generates them with rc_keydown().
> 
> So the mapping can be done either in the kernel, or in
> user-space by the application consuming the scancodes,
> right?

That's right, although I do not know of any user-space application that does
this; scancodes are mostly useful for debugging.

> > From a cursory glance at the driver I can't see anything wrong.
> > 
> > The only thing that stands out is RC5_TIME_BASE. If that is the bit
> > length or shortest pulse/space? In the latter case it should be 888 usec.
> 
> Need to locate some docs.
> 
> > It might be worth trying nec, rc5 and rc6_0 and seeing if any of them decode.
> 
> What do you mean? How do I try them?

Well, presumably you're using a remote control for testing. It would be 
useful if you had remotes which could do all protocols that the IR 
receiver supports, so you can try all three of them.

Another way of doing this is using an IR transmitter and using ir-ctl to
send scancodes.


Sean

Re: Trying to use IR driver for my SoC

[Mason]

On 29/06/2017 19:50, Sean Young wrote:

> The only thing that stands out is RC5_TIME_BASE. If that is the bit
> length or shortest pulse/space? In the latter case it should be 888 usec.

IR_RC5_DECODER_CLK_DIV
Length of 1 bit of the RC5 code in units of 27 MHz clks

Default value = 0xbb86  => 1.778 ms

#define RC5_TIME_BASE	1778
(time in microseconds apparently)

clkdiv = clkrate * RC5_TIME_BASE / 1e6 = 48006 = 0xbb86

I don't really see the point of reprogramming the
default value, though...

I'm thinking GPIO directions might be misconfigured, which
could explain why no IRQs are firing. Back to basics.

Regards.

Re: Trying to use IR driver for my SoC

[Mason]

On 29/06/2017 21:44, Sean Young wrote:

> On Thu, Jun 29, 2017 at 09:12:48PM +0200, Mason wrote:
>
>> On 29/06/2017 19:50, Sean Young wrote:
>>
>>> On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote:
>>>
>>>> $ ir-keytable -v -t
>>>> Found device /sys/class/rc/rc0/
>>>> Input sysfs node is /sys/class/rc/rc0/input0/
>>>> Event sysfs node is /sys/class/rc/rc0/input0/event0/
>>>> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
>>>> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
>>>> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
>>>> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
>>>> Parsing uevent /sys/class/rc/rc0/uevent
>>>> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
>>>> input device is /dev/input/event0
>>>> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
>>>> /sys/class/rc/rc0/protocols protocol nec (disabled)
>>>> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
>>
>> I had overlooked this. Is it expected for these protocols
>> to be marked as "disabled"?
> 
> Ah, good point, I forgot about that. :/
> 
> "ir-keytable -p all -t -v" should enable all protocols and test.

After hours of thrashing around, I finally figured out that
the IRQ was misconfigured... Doh!

Here's the output from pressing '1' for one second on the RC:

# cat /dev/input/event0 | hexdump -vC
00000000  04 04 00 00 7a 08 07 00  04 00 04 00 41 cb 04 00  |....z.......A...|
00000010  04 04 00 00 7a 08 07 00  00 00 00 00 00 00 00 00  |....z...........|
00000020  04 04 00 00 f4 da 07 00  04 00 04 00 00 00 00 00  |................|
00000030  04 04 00 00 f4 da 07 00  00 00 00 00 00 00 00 00  |................|
00000040  04 04 00 00 f1 7f 09 00  04 00 04 00 00 00 00 00  |................|
00000050  04 04 00 00 f1 7f 09 00  00 00 00 00 00 00 00 00  |................|
00000060  04 04 00 00 f2 24 0b 00  04 00 04 00 00 00 00 00  |.....$..........|
00000070  04 04 00 00 f2 24 0b 00  00 00 00 00 00 00 00 00  |.....$..........|
00000080  04 04 00 00 f3 c9 0c 00  04 00 04 00 00 00 00 00  |................|
00000090  04 04 00 00 f3 c9 0c 00  00 00 00 00 00 00 00 00  |................|
000000a0  04 04 00 00 f6 6e 0e 00  04 00 04 00 00 00 00 00  |.....n..........|
000000b0  04 04 00 00 f6 6e 0e 00  00 00 00 00 00 00 00 00  |.....n..........|
000000c0  05 04 00 00 ba d1 00 00  04 00 04 00 00 00 00 00  |................|
000000d0  05 04 00 00 ba d1 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  05 04 00 00 bb 76 02 00  04 00 04 00 00 00 00 00  |.....v..........|
000000f0  05 04 00 00 bb 76 02 00  00 00 00 00 00 00 00 00  |.....v..........|
00000100  05 04 00 00 bd 1b 04 00  04 00 04 00 00 00 00 00  |................|
00000110  05 04 00 00 bd 1b 04 00  00 00 00 00 00 00 00 00  |................|
00000120  05 04 00 00 be c0 05 00  04 00 04 00 00 00 00 00  |................|
00000130  05 04 00 00 be c0 05 00  00 00 00 00 00 00 00 00  |................|
00000140  05 04 00 00 c2 65 07 00  04 00 04 00 00 00 00 00  |.....e..........|
00000150  05 04 00 00 c2 65 07 00  00 00 00 00 00 00 00 00  |.....e..........|

I'm not sure what these mean. There seems to be some kind of
timestamp? And something else? How do I tell which protocol
this RC is using?

Repeating the test (pressing '1' for one second) with ir-keytable:

# ir-keytable -p all -t -v
Found device /sys/class/rc/rc0/
Input sysfs node is /sys/class/rc/rc0/input0/
Event sysfs node is /sys/class/rc/rc0/input0/event0/
Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
/sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
/sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
/sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-empty
input device is /dev/input/event0
/sys/class/rc/rc0/protocols protocol rc-5 (disabled)
/sys/class/rc/rc0/protocols protocol nec (disabled)
/sys/class/rc/rc0/protocols protocol rc-6 (disabled)
Opening /dev/input/event0
Input Protocol version: 0x00010001
/sys/class/rc/rc0//protocols: Invalid argument
Couldn't change the IR protocols
Testing events. Please, press CTRL-C to abort.
1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41
1296.124872: event type EV_SYN(0x00).
1296.178753: event type EV_MSC(0x04): scancode = 0x00
1296.178753: event type EV_SYN(0x00).
1296.286526: event type EV_MSC(0x04): scancode = 0x00
1296.286526: event type EV_SYN(0x00).
1296.394303: event type EV_MSC(0x04): scancode = 0x00
1296.394303: event type EV_SYN(0x00).
1296.502081: event type EV_MSC(0x04): scancode = 0x00
1296.502081: event type EV_SYN(0x00).
1296.609857: event type EV_MSC(0x04): scancode = 0x00
1296.609857: event type EV_SYN(0x00).
1296.717635: event type EV_MSC(0x04): scancode = 0x00
1296.717635: event type EV_SYN(0x00).
1296.825412: event type EV_MSC(0x04): scancode = 0x00
1296.825412: event type EV_SYN(0x00).
1296.933189: event type EV_MSC(0x04): scancode = 0x00
1296.933189: event type EV_SYN(0x00).
1297.040967: event type EV_MSC(0x04): scancode = 0x00
1297.040967: event type EV_SYN(0x00).
1297.148745: event type EV_MSC(0x04): scancode = 0x00
1297.148745: event type EV_SYN(0x00).
1297.256522: event type EV_MSC(0x04): scancode = 0x00
1297.256522: event type EV_SYN(0x00).

It looks like scancode 0x00 means "REPEAT" ?
And 0x4cb41 would be '1' then?

If I compile the legacy driver (which is much more cryptic)
it outputs 04 cb 41 be

So 0x4cb41 in common - plus a trailing 0xbe (what is that?
Some kind of checksum perhaps?)

(For '2', I get 04 cb 03 fc)

I'm a bit confused between "protocols", "decoders", "scancodes",
"keys", "keymaps". Is there some high-level doc somewhere?

I found this, but it seems to dive straight into API details:
https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/rc/remote_controllers.html

I'll start a separate thread to discuss the available IR hardware
on the board I'm using.

Regards.

Re: Trying to use IR driver for my SoC

[Sean Young]

On Mon, Jul 10, 2017 at 10:40:04AM +0200, Mason wrote:
> On 29/06/2017 21:44, Sean Young wrote:
> 
> > On Thu, Jun 29, 2017 at 09:12:48PM +0200, Mason wrote:
> >
> >> On 29/06/2017 19:50, Sean Young wrote:
> >>
> >>> On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote:
> >>>
> >>>> $ ir-keytable -v -t
> >>>> Found device /sys/class/rc/rc0/
> >>>> Input sysfs node is /sys/class/rc/rc0/input0/
> >>>> Event sysfs node is /sys/class/rc/rc0/input0/event0/
> >>>> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
> >>>> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
> >>>> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
> >>>> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
> >>>> Parsing uevent /sys/class/rc/rc0/uevent
> >>>> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
> >>>> input device is /dev/input/event0
> >>>> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
> >>>> /sys/class/rc/rc0/protocols protocol nec (disabled)
> >>>> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
> >>
> >> I had overlooked this. Is it expected for these protocols
> >> to be marked as "disabled"?
> > 
> > Ah, good point, I forgot about that. :/
> > 
> > "ir-keytable -p all -t -v" should enable all protocols and test.
> 
> After hours of thrashing around, I finally figured out that
> the IRQ was misconfigured... Doh!
> 
> Here's the output from pressing '1' for one second on the RC:
> 
> # cat /dev/input/event0 | hexdump -vC
> 00000000  04 04 00 00 7a 08 07 00  04 00 04 00 41 cb 04 00  |....z.......A...|
-snip-

It might be easier to use "ir-keytable -t" for this, or evtest. 

> I'm not sure what these mean. There seems to be some kind of
> timestamp? And something else?

You're reading "struct input_event" here, see the input api.

> How do I tell which protocol
> this RC is using?

That's an awkward question to answer. This is not passed to user space
at the moment, that's one of addition I want to make to the lirc user
space api in the near future.

For the moment I would suggest just putting printk() in your code when
you call rc_keydown().

> Repeating the test (pressing '1' for one second) with ir-keytable:
> 
> # ir-keytable -p all -t -v
> Found device /sys/class/rc/rc0/
> Input sysfs node is /sys/class/rc/rc0/input0/
> Event sysfs node is /sys/class/rc/rc0/input0/event0/
> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
> Parsing uevent /sys/class/rc/rc0/uevent
> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
> input device is /dev/input/event0
> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
> /sys/class/rc/rc0/protocols protocol nec (disabled)
> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
> Opening /dev/input/event0
> Input Protocol version: 0x00010001
> /sys/class/rc/rc0//protocols: Invalid argument
> Couldn't change the IR protocols
> Testing events. Please, press CTRL-C to abort.
> 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41
> 1296.124872: event type EV_SYN(0x00).
> 1296.178753: event type EV_MSC(0x04): scancode = 0x00
> 1296.178753: event type EV_SYN(0x00).
> 1296.286526: event type EV_MSC(0x04): scancode = 0x00
> 1296.286526: event type EV_SYN(0x00).
> 1296.394303: event type EV_MSC(0x04): scancode = 0x00
> 1296.394303: event type EV_SYN(0x00).
> 1296.502081: event type EV_MSC(0x04): scancode = 0x00
> 1296.502081: event type EV_SYN(0x00).
> 1296.609857: event type EV_MSC(0x04): scancode = 0x00
> 1296.609857: event type EV_SYN(0x00).
> 1296.717635: event type EV_MSC(0x04): scancode = 0x00
> 1296.717635: event type EV_SYN(0x00).
> 1296.825412: event type EV_MSC(0x04): scancode = 0x00
> 1296.825412: event type EV_SYN(0x00).
> 1296.933189: event type EV_MSC(0x04): scancode = 0x00
> 1296.933189: event type EV_SYN(0x00).
> 1297.040967: event type EV_MSC(0x04): scancode = 0x00
> 1297.040967: event type EV_SYN(0x00).
> 1297.148745: event type EV_MSC(0x04): scancode = 0x00
> 1297.148745: event type EV_SYN(0x00).
> 1297.256522: event type EV_MSC(0x04): scancode = 0x00
> 1297.256522: event type EV_SYN(0x00).
> 
> It looks like scancode 0x00 means "REPEAT" ?

This looks like nec repeat to me; nec repeats are sent every 110ms;
however when a repeat occurs, the driver should call rc_repeat(),
sending a scancode of 0 won't work.

> And 0x4cb41 would be '1' then?
> 
> If I compile the legacy driver (which is much more cryptic)
> it outputs 04 cb 41 be

~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this
into extended nec (so the driver should send RC_TYPE_NECX), see
https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68

> So 0x4cb41 in common - plus a trailing 0xbe (what is that?
> Some kind of checksum perhaps?)

That's part of the nec protocol.

> (For '2', I get 04 cb 03 fc)

See http://www.sbprojects.com/knowledge/ir/nec.php

> I'm a bit confused between "protocols", "decoders", "scancodes",
> "keys", "keymaps". Is there some high-level doc somewhere?

I don't think there is. The infrared led is either on or off[1], so an 
IR message is a series of pulses and spaces (pulse for IR on, space for
IR absent). There are different protocols for encoding these IR messages,
e.g. nec, rc5. When they are decoded, you end up with a scancode 
(32 bit number). The keymap maps scancodes to keys, so in your case we
would want a keymap with:
scancode 0x4cb41 = KEY_1
scancode 0x4cb03 = KEY_2
etc.
Then KEY_1 will be reported to the input layer and you can use the
remote as you would expect.

The decoder can either be done in hardware (firmware?) and in software; 
in your case it is done in hardware.

[1] Ignoring the carrier for simplicity, that rarely matters.

> I found this, but it seems to dive straight into API details:
> https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/rc/remote_controllers.html
> 
> I'll start a separate thread to discuss the available IR hardware
> on the board I'm using.


Sean

Re: Trying to use IR driver for my SoC

[Mason]

On 11/07/2017 20:35, Sean Young wrote:

> Mason wrote:
>
>> Repeating the test (pressing '1' for one second) with ir-keytable:
>>
>> # ir-keytable -p all -t -v
>> Found device /sys/class/rc/rc0/
>> Input sysfs node is /sys/class/rc/rc0/input0/
>> Event sysfs node is /sys/class/rc/rc0/input0/event0/
>> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
>> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
>> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
>> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
>> Parsing uevent /sys/class/rc/rc0/uevent
>> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
>> input device is /dev/input/event0
>> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
>> /sys/class/rc/rc0/protocols protocol nec (disabled)
>> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
>> Opening /dev/input/event0
>> Input Protocol version: 0x00010001
>> /sys/class/rc/rc0//protocols: Invalid argument
>> Couldn't change the IR protocols
>> Testing events. Please, press CTRL-C to abort.
>> 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41
>> 1296.124872: event type EV_SYN(0x00).
>> 1296.178753: event type EV_MSC(0x04): scancode = 0x00
>> 1296.178753: event type EV_SYN(0x00).
>> 1296.286526: event type EV_MSC(0x04): scancode = 0x00
>> 1296.286526: event type EV_SYN(0x00).
>> 1296.394303: event type EV_MSC(0x04): scancode = 0x00
>> 1296.394303: event type EV_SYN(0x00).
>> 1296.502081: event type EV_MSC(0x04): scancode = 0x00
>> 1296.502081: event type EV_SYN(0x00).
>> 1296.609857: event type EV_MSC(0x04): scancode = 0x00
>> 1296.609857: event type EV_SYN(0x00).
>> 1296.717635: event type EV_MSC(0x04): scancode = 0x00
>> 1296.717635: event type EV_SYN(0x00).
>> 1296.825412: event type EV_MSC(0x04): scancode = 0x00
>> 1296.825412: event type EV_SYN(0x00).
>> 1296.933189: event type EV_MSC(0x04): scancode = 0x00
>> 1296.933189: event type EV_SYN(0x00).
>> 1297.040967: event type EV_MSC(0x04): scancode = 0x00
>> 1297.040967: event type EV_SYN(0x00).
>> 1297.148745: event type EV_MSC(0x04): scancode = 0x00
>> 1297.148745: event type EV_SYN(0x00).
>> 1297.256522: event type EV_MSC(0x04): scancode = 0x00
>> 1297.256522: event type EV_SYN(0x00).
>>
>> It looks like scancode 0x00 means "REPEAT" ?
> 
> This looks like nec repeat to me; nec repeats are sent every 110ms;
> however when a repeat occurs, the driver should call rc_repeat(),
> sending a scancode of 0 won't work.

IIUC, the driver requires some fixup, to behave as user-space
would expect; is that correct?

Are you the reviewer for rc drivers?


>> And 0x4cb41 would be '1' then?
>>
>> If I compile the legacy driver (which is much more cryptic)
>> it outputs 04 cb 41 be
> 
> ~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this
> into extended nec (so the driver should send RC_TYPE_NECX), see
> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68

Another required fixup IIUC, right?

Thank you so much for all the insight you've provided.

Regards.

Re: Trying to use IR driver for my SoC

[Sean Young]

On Tue, Jul 11, 2017 at 11:51:02PM +0200, Mason wrote:
> On 11/07/2017 20:35, Sean Young wrote:
> 
> > Mason wrote:
> >
> >> Repeating the test (pressing '1' for one second) with ir-keytable:
> >>
> >> # ir-keytable -p all -t -v
> >> Found device /sys/class/rc/rc0/
> >> Input sysfs node is /sys/class/rc/rc0/input0/
> >> Event sysfs node is /sys/class/rc/rc0/input0/event0/
> >> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
> >> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
> >> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
> >> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
> >> Parsing uevent /sys/class/rc/rc0/uevent
> >> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
> >> input device is /dev/input/event0
> >> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
> >> /sys/class/rc/rc0/protocols protocol nec (disabled)
> >> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
> >> Opening /dev/input/event0
> >> Input Protocol version: 0x00010001
> >> /sys/class/rc/rc0//protocols: Invalid argument
> >> Couldn't change the IR protocols
> >> Testing events. Please, press CTRL-C to abort.
> >> 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41
> >> 1296.124872: event type EV_SYN(0x00).
> >> 1296.178753: event type EV_MSC(0x04): scancode = 0x00
> >> 1296.178753: event type EV_SYN(0x00).
> >> 1296.286526: event type EV_MSC(0x04): scancode = 0x00
> >> 1296.286526: event type EV_SYN(0x00).
> >> 1296.394303: event type EV_MSC(0x04): scancode = 0x00
> >> 1296.394303: event type EV_SYN(0x00).
> >> 1296.502081: event type EV_MSC(0x04): scancode = 0x00
> >> 1296.502081: event type EV_SYN(0x00).
> >> 1296.609857: event type EV_MSC(0x04): scancode = 0x00
> >> 1296.609857: event type EV_SYN(0x00).
> >> 1296.717635: event type EV_MSC(0x04): scancode = 0x00
> >> 1296.717635: event type EV_SYN(0x00).
> >> 1296.825412: event type EV_MSC(0x04): scancode = 0x00
> >> 1296.825412: event type EV_SYN(0x00).
> >> 1296.933189: event type EV_MSC(0x04): scancode = 0x00
> >> 1296.933189: event type EV_SYN(0x00).
> >> 1297.040967: event type EV_MSC(0x04): scancode = 0x00
> >> 1297.040967: event type EV_SYN(0x00).
> >> 1297.148745: event type EV_MSC(0x04): scancode = 0x00
> >> 1297.148745: event type EV_SYN(0x00).
> >> 1297.256522: event type EV_MSC(0x04): scancode = 0x00
> >> 1297.256522: event type EV_SYN(0x00).
> >>
> >> It looks like scancode 0x00 means "REPEAT" ?
> > 
> > This looks like nec repeat to me; nec repeats are sent every 110ms;
> > however when a repeat occurs, the driver should call rc_repeat(),
> > sending a scancode of 0 won't work.
> 
> IIUC, the driver requires some fixup, to behave as user-space
> would expect; is that correct?

Yes, it does.

> Are you the reviewer for rc drivers?

Yes, I am. However there is plenty of knowledge on rc on this list. :)

> >> And 0x4cb41 would be '1' then?
> >>
> >> If I compile the legacy driver (which is much more cryptic)
> >> it outputs 04 cb 41 be
> > 
> > ~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this
> > into extended nec (so the driver should send RC_TYPE_NECX), see
> > https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68
> 
> Another required fixup IIUC, right?

Yes, there is.

> Thank you so much for all the insight you've provided.

np. It's nice to see this driver mainlined.

Thanks,
Sean