OSMC Remote Support

With a liitle tweaking in /etc/lirc/hardware.conf and xpad blacklisted i’ve managed it to work.
Now after boot irw receives codes. When i hit a key it shows e.g. KEY_SELECT linux-input-layer, but if i pkill -15 lircd and /usr/sbin/lircd -d /dev/lirc0 , now if i hit the same key shows KEY_SELECT XboxDVDDongle. Why it’s recognized different?

Because it’s no longer passing through eventlircd - why are you trying to kill and restart lircd with different command line options ?

Because after experimenting the only way i could make it work it was this way and i’m trying to figure out the behavior after boot (the lircd autostart). So you’re telling me for that is responsible eventlircd if i get it right…Can i do something so eventlircd recognize it as XboxDVDDongle and not as linux-input-layer?

eventlircd is configured to always report the remote as “linux-input-layer”. This is done in a udev rule:

This is done because eventlircd merges all remote devices (including those provided by a kernel driver and those provided by lircd) and sends them to kodi via the lirc socket at /var/run/lirc/lircd.

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

S

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.

Cheers

Dave


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.

Dave

This line in that file fixes it

<f14>VolumeDown</f14>

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.