[SOLVED] My RF remote has stopped working after migration to Kodi v17

Take them to Kodi. As long as you have enabled debug logging, your sequence to create the logs will provide what they want.

I’ve used Kodi since it was born… Love it… And I hate to moan, as this wonderful free product is just simply brilliant!
And I use it with Emby.
But… Now I cant use it (on the 3 OSMC boxes I have in the house) as my Freeeway Technology remote (Air Remote) doesn’t work at all now… I’m not blaming OSMC at all, but come on…

Sorry – but from what I can see the keys are still visible in OSMC and evtest, which suggests that this isn’t an OSMC issue. It looks like there has been a change of behaviour in Kodi.

I don’t have a solution for this, as I don’t have any of these remotes to test. I’d recommend checking on the Kodi forum and with the manufacturer of the device.

Sam can you point out to the last version of OSMC with Kodi 16?

I’d like to downgrade.

Thanks.

You can grab it from the website.
Reverting isn’t really an ideal solution. Because nfortunately without any further participation you’ll have to stay on this version for the forseeable future.

We can’t watch TV anymore, and my kids are getting very impatient…

I am not sure which version on the website is the last before V17 ?

Ok – understand.

Grab anything before February 2017.

Thanks. I was thinking of buying a different remote but that won’t help the community either (and its not guaranteed that it won’t have the same problem).

Makes sense.

It depends on needs. The OSMC Remote is most popular, and will always be supported, but doesn’t meet everyone’s requirements. It does seem to meet WAF and children’s requirements though.

We plan to fix it soon, but it’s always hard without hardware in our hands. One user has actually purchased a remote for me off Amazon to test.

3 Likes

I am a Libreelec user myself, but we have the same problem with T3 and Krypton. The remote produces the same symptoms on Raspbian (Piplware repo) as well, but NOT on Windows.

I hope this gets fixed soon, I have the same air mouse as OP and navigating using just the gyroscope is a nightmare

1 Like

Hello,

I just bought my raspberry pi and installed kodi v17 on it last week, i bought my remote yesterday (this one) and I am getting the same problem. The air remote works but the keyboard and the buttons do not.

My logs contain the same text as Ori’s does:

WARNING: CLinuxInputDevice::RelEvent: Unknown rel event code: 13

I could provide more information if anyone has any clue how to resolve this?

I had the same problem running kodi 17.0-2 on Arch Linux (4.4.49-1-ARCH) on a raspberry pi 2.

I discovered that the kernel was misidentifying the keyboard part of the remote as a joystick.

Using information from https://github.com/denilsonsa/udev-joystick-blacklist I created the udev rule /etc/udev/rules.d/51-not-a-joystick.rules

SUBSYSTEM=="input", ATTRS{idVendor}=="1d57", ATTRS{idProduct}=="ad03", ENV{ID_INPUT_JOYSTICK}=="?*", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="1d57", ATTRS{idProduct}=="ad03", KERNEL=="js[0-9]*", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""

I think kodi may be only looking for specific types of input devices, that is, not joysticks.

4 Likes

Nice find @eubuleus

There have been changes to Kodi handles input, particularly with the support for games controllers now in Kodi v17.

Can anyone confirm if this also works for them?

I’ll ping Garbear who may have some ideas, as creating a number of udev rules for each affected remote to address this problem is not necessarily practical.

Sam

1 Like

Thanks @eubuleus

I can confirm that this fix works for me.

Jose

2 Likes

May be you could hold a list of list of ‘idVender:idProduct’ pairs and generate a tailored udev.rules for any that are found.

1 Like

Yes – I think that’s what we are going to need to do. We already have udev handling for some remotes and peripherals as it is.

I wasn’t aware of the GitHub project which had a list of recommend udev rules. I may consider pulling those in, although we need to be careful and make sure we don’t see any regressions.

Thanks

Sam

1 Like

Thanks @eubuleus

I can confirm that this fix works for me too

Using information from GitHub - denilsonsa/udev-joystick-blacklist: Fix for keyboard/mouse/tablet being detected as joystick in Linux I created the udev rule /etc/udev/rules.d/51-not-a-joystick.rules


sudo curl -o /etc/udev/rules.d/51-these-are-not-joysticks.rules
http://paste.osmc.io/raw/fazuposufu


# /etc/udev/rules.d/51-these-are-not-joysticks-rm.rules
#
# https://github.com/denilsonsa/udev-joystick-blacklist
# /etc/udev/rules.d/51-these-are-not-joysticks.rules
#  Using information from https://github.com/denilsonsa/udev-joystick-blacklist

SUBSYSTEM=="input", ATTRS{idVendor}=="1d57", ATTRS{idProduct}=="ad03", ENV{ID_INPUT_JOYSTICK}=="?*", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="1d57", ATTRS{idProduct}=="ad03", KERNEL=="js[0-9]*", MODE="0000", ENV{ID_INPUT_JOYSTICK}=""
1 Like

Another thanks for @eubuleus :slight_smile:
Works fine with T3 remote now.

Thanks @eubuleus, it works fine now