I've been using a Rii-25 wireless remote - it's a piece of crap. I foolishly purchased another one and it, too, is a piece of crap. The issue is horrible keybounce, you simply CANNOT get a key to fire only ONCE - it's always two or ever three times. Like Neil Young sings, "Piece of CRAP!"
So, having a new RPi5 with built in bluetooth capabilities, I took a chance on a simple UGOOS BT Remote Control UR02 from Ali Express.. I figured I could risk $12 US.
I received the remote, I got it to pair, and BINGO - it works - it works and the keys DO NOT BOUNCE.. Happy dance!
Except...
The OK key the center of the click wheel doesn't do anything. Well, lets modify that, it will wake Kodi from the screen saver, so I know it WORKS and is sending something, but I can't use it to select menu items. Time to search the forums!
In this thread, 26261-fix-for-xiaomi-bluetooth-remote-with-nonworking-button, there is a description of a fix that includes two lines, an EVDEV identifier (?) string and then a KEYBOARD_KEY remap statement included in one of the init files:
QuoteCouldn't get evtest working, but got enough information from running cat /proc/bus/input/devices
Created the 70-local-keyboard.hwdb file with the code below and it worked OK
Codeevdev:input:b0003v4842p0001* KEYBOARD_KEY_c0041=enter
In theory, I should be able to use "/storage/.kodi/addons/virtual.system-tools/bin/evtest" or "cat /proc/bus/input/devices" to help me figure out the input device, then remap the code to effect an "enter" action. That's my interpretation at any rate. I reviewed more than one forum entry and this seems like this is a common issue with Blutooth remotes. Some entries refer to this work around and some are just dead threads, but in threads with a solution all the input devices appear to have a unique "evdev:input:$STRING" entry. So how do I find this identifier as it relates to my cheap little remote? (that does NOT suffer keybounce!) 
Running evtest doesn't show me anything that looks like my BT remote: (only shows the HDMI and RPi5 power button)
Livingroom:~ # evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: vc4-hdmi-0 HDMI Jack
/dev/input/event1: vc4-hdmi-1 HDMI Jack
/dev/input/event2: pwr_button
Select the device event number [0-2]:
^C
Livingroom:~ #Likewise, viewing /proc/bus/input/devices doesn't reveal anything useful to me: (again, only showing data pertinent to the HDMI ports and the integral RPi5 power switch)
Livingroom:~ # cat /proc/bus/input/devices
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="vc4-hdmi-0 HDMI Jack"
P: Phys=ALSA
S: Sysfs=/devices/platform/soc/107c701400.hdmi/sound/card0/input0
U: Uniq=
H: Handlers=event0
B: PROP=0
B: EV=21
B: SW=40
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="vc4-hdmi-1 HDMI Jack"
P: Phys=ALSA
S: Sysfs=/devices/platform/soc/107c706400.hdmi/sound/card1/input1
U: Uniq=
H: Handlers=event1
B: PROP=0
B: EV=21
B: SW=40
I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="pwr_button"
P: Phys=gpio-keys/input0
S: Sysfs=/devices/platform/pwr_button/input/input2
U: Uniq=
H: Handlers=kbd event2
B: PROP=0
B: EV=3
B: KEY=10000000000000 0
Livingroom:~ # I'm feeling a little lost here... I THINK the work around is right at my finger tips, but for the life of me I can't seem to put it all together.
I wonder if anyone has a clue how I should proceed, SPECIFICALLY, how I determine the "evdev:input:$STRING" that would apply to my bluetooth device.
Thanks so much for any and all input!
Sincerely,
-ET-
) but only by VARIATIONS on all the help quoted above and so many repetitions my head is spinning. Let me, for the record, detail EXACTLY what worked here and how to repeat this with ANY blutooth remote.. Of course this is all based on my current revision of LE (12.0.0) and HW (RPi5). Your version/HW difference may be, well, different..
) - and there are SO MANY FORUM ENTRIES ABOUT IT, but they seem a little scattered and none have the process listed from end to end, soo... Chewit detailed the leading space issue, but I missed it - dumb ass me. Hiassoft pointed me to a previous post that listed "udevadm hwdb --update" which is depreciated now and replace with systemd-hwdb.. Both work, but we should use the current stuff, right?
