Re: ir-keytable: infinite loops, segfaults

[Sean Young <sean@mess.org>]

On Fri, Nov 25, 2016 at 07:59:21PM +1100, Vincent McIntyre wrote:
> On 11/25/16, Sean Young <sean@mess.org> wrote:
> >
> > So if I understand you correctly, if you change the keymap, like you
> > changed 0xfe47 to KEY_PAUSE, then "ir-keytable -s rc1 -t" show you the
> > correct (new) key? So as far as ir-keytable is concerned, everything
> > works?
> >
> > However when you try to use the new mapping in some application then
> > it does not work?
> 
> That's correct. ir-keytable seems to be doing the right thing, mapping
> the scancode to the input-event-codes.h key code I asked it to.

ir-keytable reads from the input layer, so that's the key being sent. The
problem is elsewhere.

> The application I am trying to use it with is the mythtv frontend.  I
> am doing the keycode munging from an SSH session while myth is still
> running on the main screen. I didn't think this would matter (since it
> worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously
> ir-keytable -t intercepts the scancodes when it is running, but when I
> kill it myth responds normally to some keys, but not all.

X and keycodes is a bit messy. You might need xmodmap mappings. You
can check them xev. I don't know much about this, I'm afraid. What
linux distribution, version and keyboard layout are you using? I could
try and see if I can reproduce/fix this.
 
> I wanted to mention that the IR protocol is still showing as unknown.
> Is there anything that can be done to sort that out?

It would be nice if that could be sorted out, although that would be 
a separate patch.

So all we know right now is what scancode the IR receiver hardware
produces but we have no idea what IR protocol is being used. In order to
figure this out we need a recording of the IR the remote sends, for which
a different IR receiver is needed. Neither your imon nor your 
dvb_usb_af9035 can do this, something like a mce usb IR receiver would
be best. Do you have access to one? One with an IR emitter would be
best.

So with that we can have a recording of the IR the remote sends, and
with the emitter we can see which IR protocols the IR receiver 
understands.


Sean