OSMC Remote Support

Nicely explained.
The problem is after boot (blacklist xpad) with keys DISPLAY, REVERSE, FORWARD
If i irw i get respectively nothing(no recon), nothing (no recon), 0x9f
9f 0 KEY_FORWARD linux-input-layer 9f 1 KEY_FORWARD linux-input-layer 9f 0 KEY_FORWARD_UP linux-input-layer

As you can imagine the keys DISPLAY and REVERSE don’t work

After i pkill -15 lircd and /usr/sbin/lircd -d /dev/lirc0 i get
00000000000000d5 00 DISPLAY XboxDVDDongle 00000000000000d5 01 DISPLAY XboxDVDDongle 00000000000000d5 02 DISPLAY XboxDVDDongle 00000000000000d5 03 DISPLAY XboxDVDDongle 00000000000000e2 00 REVERSE XboxDVDDongle 00000000000000e2 01 REVERSE XboxDVDDongle 00000000000000e2 02 REVERSE XboxDVDDongle 00000000000000e2 03 REVERSE XboxDVDDongle 00000000000000e3 00 KEY_FORWARD XboxDVDDongle 00000000000000e3 01 KEY_FORWARD XboxDVDDongle 00000000000000e3 02 KEY_FORWARD XboxDVDDongle 00000000000000e3 03 KEY_FORWARD XboxDVDDongle 00000000000000e3 04 KEY_FORWARD XboxDVDDongle

and now the keys work. If i nano /lib/udev/rules.d/98-eventlircd.rules i couldn’t find a combination of ID_VENDOR_ID and ID_MODEL_ID maching my XboxDVDDongle so i added these three lines
ENV{ID_VENDOR_ID}=="045e", ENV{ID_MODEL_ID}=="0284", \ ENV{eventlircd_enable}="true", \ ENV{eventlircd_evmap}="03_$env{ID_VENDOR_ID}_$env{ID_MODEL_ID}.evmap"

but also no result (not that i can fully understand what it does)…
How can i make these two buttons work?

After today’s autoupdate works like charm!

No update has been pushed that I’m aware of that would affect remotes… are you sure it wasn’t just a reboot that helped ?

If you’re editing the remote configuration (lircd.conf) then you need to restart the lircd_helper@* service for the change to take effect. And if you are manually messing around killing and restarting lircd with different command line options a reboot will be needed to get it back in a normal state.

Is there a recommended way of extracting logging to work out whether a wireless keyboard is supported or not (namely eSynic® 2.4G Mini Wireless Keyboard or http://www.amazon.co.uk/eSynic®-Wireless-Keyboard-Touchpad-Mouse/dp/B00DUUF30Y ) and / or what might be going wrong ?

Upon initial installation today it was working fine but after applying all the updates it has stopped working.

Hmmm. Even though I reboot didn’t help, I have just tried unplugging and replugging the USB dongle for the wireless keyboard on a running system and I get

[33496.023514] usb 1-1.3.2: new low-speed USB device number 105 using dwc_otg
[33496.132224] usb 1-1.3.2: New USB device found, idVendor=1d57, idProduct=ad03
[33496.132261] usb 1-1.3.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[33496.132277] usb 1-1.3.2: Product: Mini Keyboard
[33496.132290] usb 1-1.3.2: Manufacturer: Mini Keyboard
[33496.158592] input: Mini Keyboard Mini Keyboard as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:1D57:AD03.0002/input/input1
[33496.161334] hid-generic 0003:1D57:AD03.0002: input,hidraw0: USB HID v1.10 Keyboard [Mini Keyboard Mini Keyboard] on usb-bcm2708_usb-1.3.2/input0
[33496.201640] input: Mini Keyboard Mini Keyboard as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.1/0003:1D57:AD03.0003/input/input2
[33496.207400] hid-generic 0003:1D57:AD03.0003: input,hidraw1: USB HID v1.10 Mouse [Mini Keyboard Mini Keyboard] on usb-bcm2708_usb-1.3.2/input1

from dmesg. And bizarrely it now works fine. Maybe its a boot issue and its not detecting it correctly initially… wierd!

This is very likely a power issue


Interesting. Why do you say that please?

The pi (Raspberry 1 B) is powered by a hub from ModMyPI ( https://www.modmypi.com/raspberry-pi/accessories/usb-hubs/new-link-4-port-usb-hub-uk-5v-2a) whom state they have tested it…

Hi there. Like so many others I have also got a remote that worked with Raspbmc but doesn’t with OSMC. Well actually the only button that doesn’t work is the “Vol Down” one. “Vol Up” does, but of course it just shows a display saying Vol 100%.

It’s this one actually. Runs off a usb IR:

It was such a good buy that I ended up getting two, but now I’ve upgraded both the Upstairs Pi and the Downstairs Pi to OSMC, I can’t adjust volume. I’ll try and figure it out myself, but in the meantime any help would be appreciated.

Try enabling debug mode in Kodi then tail the kodi log via an SSH session like this:

tail -f /home/osmc/.kodi/temp/kodi.log

Now when you press buttons it should show log entries of what Kodi is receiving.

Please try pressing some buttons that do work and then the ones that don’t work then upload your Kodi log with:

paste-log /home/osmc/.kodi/temp/kodi.log

And let us know which lines were printed when you pressed the buttons that didn’t work.

Try this, not sure it will work but it won’t hurt Volume Down / Mute key failure [SOVLED] - #5 by gatorback

Hi DBMandrake. Here’s a snip from kodi.log. You should be able to see me pressing the Left key at 19:20:07. Then Down at 19:20:15. 19:20:22 is Volume Up key. These of course all work.

Now at 19:20:34 we have a key “F14” with no action. That’s the Volume down key. I’m guessing that was defined in raspbmc but now has no definition in osmc.



19:20:07 T:1957273600   DEBUG: Keyboard: scancode: 0x69, sym: 0x0114, unicode: 0x0000, modifier: 0x0
19:20:07 T:1957273600   DEBUG: OnKey: left (0xf082) pressed, action is Left
19:20:13 T:1814230048   DEBUG: script.module.osmcsetting.updates :  - blurp 892 - SettingsCategory.xml
19:20:15 T:1957273600   DEBUG: Keyboard: scancode: 0x6c, sym: 0x0112, unicode: 0x0000, modifier: 0x0
19:20:15 T:1957273600   DEBUG: OnKey: down (0xf081) pressed, action is Down
19:20:22 T:1957273600   DEBUG: Keyboard: scancode: 0x73, sym: 0x00af, unicode: 0x0000, modifier: 0x0
19:20:22 T:1957273600   DEBUG: OnKey: volume_up (0xf0b9) pressed, action is VolumeUp
19:20:22 T:1957273600   DEBUG: CAnnouncementManager - Announcement: OnVolumeChanged from xbmc
19:20:22 T:1957273600   DEBUG: GOT ANNOUNCEMENT, type: 64, from xbmc, message OnVolumeChanged
19:20:22 T:1957273600   DEBUG: ------ Window Init (DialogVolumeBar.xml) ------
19:20:22 T:1957273600   DEBUG: SECTION:LoadDLL(special://xbmcbin/system/ImageLib-arm.so)
19:20:22 T:1957273600   DEBUG: Loading: /usr/lib/kodi/system/ImageLib-arm.so
19:20:23 T:1957273600   DEBUG: ------ Window Deinit (DialogVolumeBar.xml) ------
19:20:34 T:1957273600   DEBUG: Keyboard: scancode: 0x72, sym: 0x0127, unicode: 0x0000, modifier: 0x0
19:20:34 T:1957273600   DEBUG: OnKey: f14 (0xf09d) pressed, action is
19:20:41 T:1957273600   DEBUG: Keyboard: scancode: 0x73, sym: 0x00af, unicode: 0x0000, modifier: 0x0
19:20:41 T:1957273600   DEBUG: OnKey: volume_up (0xf0b9) pressed, action is VolumeUp

The file I linked above should fix it

Hi Dilligaf. Sadly it didn’t work for me. The remote no longer worked at all after reboot. Luckily removing the file and another reboot got me back again.


This line in that file fixes it


Check file permisions and try redownloading the file as I know it has worked for others

OK I have remote ssh access so I have just downloaded it again, but I’m unable to test the remote in situ until I get back from work later this evening. Perms on the file are Read for all users.

Ah! Working now, thanks. However a reboot is not enough. It required a complete power down of the Pi.

Powering down won’t do anything the reboot didn’t. Are you sure you didn’t just exit Kodi ?

Nope, I typed “sudo reboot” on the command line, and the ssh session terminated as the ssh server was closed. The first time I did this I was sitting in front of the pi and I watched it reboot.

I suppose its possible that the “warm” reset knocked out the usb IR remote. That would mean that the correct keymap was now installed…but the usb wasn’t working. I suppose if I’d re-enabled dbug mode I might have seen a complete lack of keypresses in the log file.


I bought last year an official OSMC remote with it’s small dongle, now I have an logitech harmony remote.
I would like to know if the OSMC dongle is usable with harmony remote.

If someone know something about it…


The dongle is RF.

I think Logitech Harmony is only Bluetooth and IR based; but may be wrong