Buster test rc6-mce remote some keys not working

Help and Support Raspberry Pi
1

Hi,
updated to buster successfully however some keys on rc6-mce remote have stopped working.
The worst offender is the “KEY_OK” as I can generally navigate but can’t select unless I connect a keyboard. See debug and output from irw below.
KEY_OK is detected by irw but it is not seen as handled in the debug log.
Any suggestions…

000000037ff07be0 00 KEY_DOWN mceusb
000000037ff07bdf 00 KEY_LEFT mceusb
000000037ff07bde 00 KEY_RIGHT mceusb
000000037ff07bdd 00 KEY_OK mceusb
000000037ff07bdc 00 KEY_ESC mceusb

2020-09-21 11:41:58.290 T:1906307296 DEBUG: LIRC: - NEW 6c 0 KEY_DOWN linux-input-layer (KEY_DOWN)
2020-09-21 11:41:58.303 T:1916179376 DEBUG: HandleKey: 167 (0xa7, obc88) pressed, action is Down
2020-09-21 11:42:00.558 T:1906307296 DEBUG: LIRC: - NEW 69 0 KEY_LEFT linux-input-layer (KEY_LEFT)
2020-09-21 11:42:00.574 T:1916179376 DEBUG: HandleKey: 169 (0xa9, obc86) pressed, action is Left
2020-09-21 11:42:02.610 T:1906307296 DEBUG: LIRC: - NEW 6a 0 KEY_RIGHT linux-input-layer (KEY_RIGHT)
2020-09-21 11:42:02.643 T:1916179376 DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is Right
2020-09-21 11:42:08.606 T:1906307296 DEBUG: LIRC: - NEW 1 0 KEY_ESC linux-input-layer (KEY_ESC)
2020-09-21 11:42:08.642 T:1916179376 DEBUG: HandleKey: menu (0xd8) pressed, action is Back

Thanks,
George

2

Sounds related to OSMC-Buster-RPI-1 Missing one IR command

3

Hi Sam (do you ever sleep?),
Yes, I thought it might be related but there seems to be a discussion regarding installed packages and this is a clean buster upgrade performed yesterday.
If it’s important this is a Pi3B+.

4

Which remote are you using?

I do most testing with an Xbox 360 MCE Remote. I think there’s some compatibility with the RC6 profile but will have to test tomorrow.

Pretty sure that we have a regression here with LIRC and you’re not the only one affected

5

I’m using a Hauppage model that came with a card.
Sticker on back has RRS9002-86XXF, but googling suggests that the code is also used by Microsoft.

7

The buster upgrade also broke my remote (which is a programmable remote set up using the rc5 protocol, I originally based it the Hauppage key codes)

I can see all the keypresses when using mode2, and even regenerated from scratch using irrecord, but lirc (and irw) can only see a subset of the buttons. up-down-left-right, FF, RW, Play, Record and Pause, but nothing else. (including the OK/select button, which pretty much halts everything. All I can do is move the cursor around the login screen)

I’ve included the fresh lirc.conf below that irrecord generated, in case someone can see anything odd in it.

My understanding is that in Buster all the lirc stuff was moved into the kernel, but I have not been able to find anything helpful about what (if anything) we should do differently to use it.

# Please take the time to finish this file as described in
# https://sourceforge.net/p/lirc-remotes/wiki/Checklist/
# and make it available to others by sending it to
# <lirc@bartelmus.de>
#
# This config file was automatically generated
# using lirc-0.9.4c(default) on Mon Sep 21 16:56:40 2020
# Command line used: -H default -d /dev/lirc0
# Kernel version (uname -r): 4.9.113-22-osmc
#
# Remote name (as of config file): int2
# Brand of remote device, the thing you hold in your hand:
# Remote device model nr:
# Remote device info url:
# Does remote device has a bundled capture device e. g., a
#     usb dongle? :
# For bundled USB devices: usb vendor id, product id
#     and device string (use dmesg or lsusb):
# Type of device controlled
#     (TV, VCR, Audio, DVD, Satellite, Cable, HTPC, ...) :
# Device(s) controlled by this remote:

begin remote

  name  int2
  bits           13
  flags RC5|CONST_LENGTH
  eps            30
  aeps          100

  one           930   824
  zero          930   824
  plead         982
  gap          112888
  toggle_bit_mask 0x800
  frequency    38000

      begin codes

          KEY_UP                   0x1794
          KEY_DOWN                 0x1795
          KEY_LEFT                 0x1796
          KEY_RIGHT                0x1797
          KEY_OK                   0x17A5

          KEY_HOME                 0x178D
          KEY_INFO                 0x17BA
          KEY_MENU                 0x179B
          KEY_BACK                 0x179F
          KEY_RED                  0x178B
          KEY_GREEN                0x17AE
          KEY_YELLOW               0x17B8
          KEY_BLUE                 0x17A9
          KEY_ZOOM                 0x178C
          KEY_STOP                 0x17B6
          KEY_RECORD               0x17B7
          KEY_REWIND               0x17B2
          KEY_FASTFORWARD          0x17B4
          KEY_PLAY                 0x17B5
          KEY_PREVIOUS             0x179E
          KEY_NEXT                 0x17A4
          KEY_PAUSE                0x17B0 0x6487C000
          KEY_CHANNELUP            0x17A0 0x6487C000
          KEY_CHANNELDOWN          0x17A1 0x6487C000
          KEY_1                    0x1781 0x6487C000
          KEY_2                    0x1782 0x6487C000
          KEY_3                    0x1783 0x6487C000
          KEY_4                    0x1784 0x6487C000
          KEY_5                    0x1785 0x6487C000
          KEY_6                    0x1786 0x6487C000
          KEY_7                    0x1787 0x6487C000
          KEY_8                    0x1788 0x6487C000
          KEY_9                    0x1789 0x6487C000
          KEY_0                    0x1780 0x6487C000
          KEY_SUBTITLE             0x179A 0x6487C000
          KEY_LANGUAGE             0x1799 0x6487C000
          KEY_TITLE                0x1798 0x6487C000
      end codes

end remote
8

This is not right.

Buster is just a userland. Our kernels remain the same and the IR decode pathway is unchanged at this time.

You could move IR decoding in to the kernel, using ir-keytable, but this has been possible since 2010, and nothing has changed in that regard for a decade now.

The changes certainly stem from our need to bump from LIRC 0.9.0 to 0.9.4 and we are investigating why these changes have occurred.

Sam

9

It seems really odd that some of the keys still work, but others stopped. Is there another mapping file somewhere in lirc that needs to be updated? (mapping things like KEY_OK to something different? Or are some of the older keycodes just not supported anymore? changed to something else?)

10

We don’t know yet. The loss of uinput aggregation doesn’t help.

Currently we are trying to get a remote profile from a user and a remote where we can actually reproduce this.

12

I’ve set up a mapping table under rc_keymaps that works for all my buttons when using
sudo ir-keytable -c -p rc-5 -w /etc/rc_keymaps/inteset_pvr

sudo ir-keytable -t
shows all the correct KEY_xyz codes for the buttons. Is there any way to get kodi to use that?

13

I’ve done a bit more testing and experimentation

my original lircd.conf has these keycodes mapped:
KEY_OK 0x17A5
KEY_HOME 0x178D

resulting in irw reporting no response for 0x17A5, but seeing 0x178D when pressed:
66 0 KEY_HOME linux-input-layer
66 1 KEY_HOME linux-input-layer

So I swapped the mappings, and then the originally non-functioning button now works (now mapped to KEY_HOME) and the other one stopped working

KEY_HOME 0x17A5
KEY_OK 0x178D

irw:
66 0 KEY_HOME linux-input-layer
66 1 KEY_HOME linux-input-layer

So, it’s not that lirc isn’t picking up the IR codes, its that it does not like “KEY_OK”, regardless of what code/button I map it to, but KEY_HOME is fine no matter what code/button I put it on.

I also tried KEY_SELECT (no response) and KEY_ENTER (works, although I don’t have kodi set up to pay attention to that)

So, from my lirc.conf, these are recognized but the rest are not.
66 0 KEY_HOME linux-input-layer
9e 0 KEY_BACK linux-input-layer
8b 0 KEY_MENU linux-input-layer
69 0 KEY_LEFT linux-input-layer
6a 0 KEY_RIGHT linux-input-layer
67 0 KEY_UP linux-input-layer
6c 0 KEY_DOWN linux-input-layer
80 0 KEY_STOP linux-input-layer
a7 0 KEY_RECORD linux-input-layer
d0 0 KEY_FASTFORWARD linux-input-layer
cf 0 KEY_PLAY linux-input-layer
a8 0 KEY_REWIND linux-input-layer

And I noticed that KEY_ENTER also works when I experimented with that.
Presumably, I could go through the list from irrecord --list-namespace and maybe find enough working codes and remap my kodi keymap. (time consuming and ugly).
I also see some configurations files under /etc/eventilircd.d, whose function are not clear to me.

Do I need to create an evmap file under /etc/eventlircd.d to map the lirc key codes to eventlirc values (or something?) I have not been able to find any documentation about what the values in those files mean, or how to configure which of those files are used, so have no clue how to start.

1 Like
14

I have found one reliable indicator of which codes work, vs which codes do not work.

This has a list of all the linux input mappings in the kernel (the KEY_xxx codes)

All of the ones defined as a decimal number in that header file (below 256) [that I tried] work. All of the ones defined as a hex number (above 256) [that I tried] do not work. I am not sure if that relates, but it is a rather interesting coincidence.

1 Like
15

My Vero 4K+ problem seems to be related too.

16

I’ve noticed that the RF remotes do not seem to have a problem. Only IR remotes (using the meson-ir device in the vero) I’ve seen some [older] discussion threads [via google] which talked about similar problems on the Pi after a buster upgrade, where they talked about changing pin assignments or some such [I did not really understand what they were talking about], or they just suggest reverting back to lirc 9.0 as the preferred solution.

17

OSMC remotes don’t use LIRC - assuming that’s what you mean by RF remotes.

I’ll have a look at the keycode issue shortly.

18

I can see the issue now.

1 Like
19

We’ve taken a stab at this and this should now be fixed. Simply update via My OSMC or accept the update when prompted.

22

Thanks Sam,
That looks like it has resolved my remote issues.
My custom remote.xml is also now working which involved another key.
Cheers,
George

1 Like