I have the same issue, but with a different remote.
This is the remote I have.
I tried the udev fix. But it did not work. I’m guessing it is because the id it is referring to is different. How do I find out what the id of my remote is?
I am new to all this and trying to work it out as I go. Feel free to talk to me like a 5 year old. 
anyone tried with a Minix A2 light? I get it and want to upgrade but…yeah you get it 
From a 6 year old in this matters (I’m new to this too so, just followed github instructions)
To find out “idVendor” and “idProduct” just do this (as per github page)
Unplug and plug your USB device while monitoring for kernel and udev events: “udevadm monitor -p”
You will then find neccessary IDs there, and from there just edit the file you already made :
sudo nano /etc/udev/rules.d/51-these-are-not-joysticks.rules
Again, as I’m as much new to this as you, there might be some easier procedure, but this is the way I did it to get my T3 working.
I unplug the USB dongle & Plug it in after booting and run
dmesg | paste-log
find out your “idVendor” and our “idProduct”
Thanks you guys. That worked. All fixed now. If anyone else has the August PCR500 the idVendor =24a7 and the idProduct=2402. Thanks again 
Thanks to @eubuleus and @schetz, both of which passed on critical info. After ssh into the box, monitoring the udev output by unplugging and replugging the 2.4 GHz dongle created lots of chatter, but the IDproduct and VendorID were right there. That is a solid way to discover the ID numbers you need.
I have a Lynec T5 remote, ProductID=2404 VendorID=25a7, and this worked like a champ.
For the record, I elected to create the file 51-these-are-not-joysticks-rm.rules (the ‘second’ method referred to in the github reference) manually. Autogenerating it created lots of entries I really didn’t need. After discovering the correct product and vendor ID’s, I navigated to the correct directory
cd /etc/udev/rules.d
and created the file I needed with
touch 51-these-are-not-joysticks-rm.rules
edit the file however you like (I installed vim) and added this text
# /etc/udev/rules.d/51-these-are-not-joysticks-rm.rules
#
# This file is auto-generated. For more information:
# https://github.com/denilsonsa/udev-joystick-blacklist
SUBSYSTEM=="input", ATTRS{idVendor}=="25a7", ATTRS{idProduct}=="2402", ENV{ID_INPUT_JOYSTICK}=="?*", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="25a7", ATTRS{idProduct}=="2402", KERNEL=="js[0-9]*", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""and saved the file. I rebooted from the interface and everything worked.
Thanks to everyone. This was a slick fix.
Here. Use this so you don’t have to bother with nano
sudo curl -o /etc/udev/rules.d/51-these-are-not-joysticks.rules \http://paste.osmc.io/mayoqozayo.vala
So im just starting to get into all this and still learning, but im having the same problem you did with the same remote. its only working as a mouse. im trying to figure out how exactly to implement this fix. if you could be so kind as to maybe elaborate for the noob please?
I’ve got an idea. How about we all post our idVendor and idProduct numbers so we can try to make a unified script. That way the devs can add it in on the next update and we can do something to help everyone out until it happens.
Hi,
I have the same problem with my remote Apple TV 3 doesn’t work with my raspberry pi 2 after upgrade osmc to last stable version krypton
Please help me ?
Thanks
Start a new post.
This post was concerning some RF remotes, and to my knowledge the AppleTV remote is IR based, so wouldn’t have been affected.
I have a T3 and after reinstalling osmc (it died) my blue OK key does not work anymore. It only works in mouse mode, but not in keyboard mode. The enter key on the other side (keyboard) doesn’t work either, so I can only perform actions in mouse mode…
Any solution?
I got same problem since last update…
Ok, I solved it the problem of Enter and OK keys not working. It’s this new annoying service, eventlircd. I noticed it didn’t start when I plugged a logitech keyboard RF receiver (everything worked fine), but it enabled automatically when I plugged the T3 RF receiver. So I disabled it via systemctl and voila, OK and Enter work again.
I hate it when the OS tries to be too smart. Seriously, if I have a RF remote, why should I want eventlircd?? Who thought the T3, MX3 and similar RF remotes with keyboards would benefit from eventlircd??
There haven’t been any changes here.
eventlircd has been used since 2014 in OSMC and is used for a variety of remotes.
I don’t have your remote in question but I’m happy to accept a PR to improve the behaviour of these remotes out of the box
Hi,
I’ve just developed this problem (the OK/Enter button not working) since the last update a few days ago.
The remote I’m using is mentioned here (it’s the August PCR500, so thanks to @NoddyJnr, I’m all set with the details - thanks for that!).
But, I have No Idea whatsoever what to do with this information. Can someone explain to a total noob what my next steps should be, please?
(Literally - I have zero clue what to do next - how to make this fix.)
Any help gratefully received.
Or, should I just buy a new remote? Would that be the easiest answer here?
I too have that remote, I did the following to fix it:
It’s unclear to me why eventlircd would be hogging the remote suddenly and causing these changes. If the vendor ID and product ID are: 1d57:ad03, then someone added improved support for these remotes to OSMC via a pull request. This PR may be responsible for the problems you are experiencing.
See
It would be good if someone with the remote could try reverting the changes to see what happens
Sam
it works for me my RF remote vendor ID and product ID are: 1d57: ad03 for kodi 17.6 in debian stretch
Are you saying reverting the above commit fixes this for you?