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.
