search

clontarfx / kodi-rc6-mce-nolirc

Files required to use most RC6 MCE remotes with Kodi and Ubuntu 17, without LIRC
29 stars 6 forks source link

Kubuntu 18.04.x and 20.04.x woots and woes #3

Open Martii opened 3 years ago

Martii commented 3 years ago

This worked well in 18.04.x :+1: but doesn't appear to do much in 20.04.1 :-1:

Hauppauge RC6 remote (RRS9002-86XXF)

IR (USB) receiver (TSES-IR01)

$ lsusb
...
Bus 003 Device 004: ID 1784:0001 TopSeed Technology Corp. eHome Infrared Transceiver
...
$ # Kubuntu 18.04.4
$ sudo ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event4) with:
        Name: Media Center Ed. eHome Infrared Remote Transceiver (1784:0001)
        Driver: mceusb, table: rc-rc6-mce
        lirc device: /dev/lirc0
        Supported protocols: other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp 
        Enabled protocols: lirc rc-6 
        bus: 3, vendor/product: 1784:0001, version: 0x0000
        Repeat delay = 500 ms, repeat period = 125 ms

vs.

$ # Kubuntu 20.04.1
$ sudo ir-keytable
Found /sys/class/rc/rc0/ with:
        Name: Media Center Ed. eHome Infrared Remote Transceiver (1784:0001)
        Driver: mceusb
        Default keymap: rc-rc6-mce
        Input device: /dev/input/event8
        LIRC device: /dev/lirc0
        Attached BPF protocols: Operation not supported
        Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm 
        Enabled kernel protocols: lirc rc-6 
        bus: 3, vendor/product: 1784:0001, version: 0x0000
        Repeat delay = 500 ms, repeat period = 125 ms

Btw... doing sudo apt-get remove *lirc* can be pretty nasty in either one of these distro's as it would remove Kodi and a few other binaries including vlc... plus it doesn't seem to be necessary.

So you could add 18.x to the wiki page however any help would be seriously appreciated for 20.x of Kubuntu (or Ubuntu 20.x itself as that's the back-end of Kubuntu).

Both systems are current atm however I'm looking to upgrade the older Kubuntu without losing the remote. Same specs on IR/Remote for both machines... and I've tried swapping them just to be sure... only works on 18.x with Kodi 17.6 and not Kodi 18.6 (or 18.8 via the stable PPA) in Kubuntu 20.x. :\

Thank you so kindly.

Martii commented 3 years ago

Small recent correction. The latest update to the kernel along with probably input lib has killed it in 18.04.x. So much for several years of the remote working fully. :disappointed:

Ref:

NOTE This section is bound to change a bit:

Additional info:

Cc: @torvalds (also where can I report/query this since it appears to be related to the kernel with these kernel objects?) Thanks for the visit/look.

Martii commented 3 years ago

Confirmed that rebooting loses the custom keymap. This is a change in behavior.

Decided to try altering /usr/lib/udev/rc_keymaps/rc6_mce.toml with my custom keys/setup and it too was ignored after a reboot.

So something appears to be broken with the kernel/input lib where it's not currently applying it initially system wide... even if I do $ sudo ir-keytable -c -w /etc/rc_keymaps/rc6_mce_hauppauge.toml manually or in a startup script. When done manually it does show KEY_OK as being transformed to KEY_ENTER with ir-keytable -t but it's not being "bubbled up" to Kodi at all now on either distro whereas Kubuntu 18.x used to before the kernel update and libinput update via apt.

Misc ref(s):

Martii commented 3 years ago

Aha... this seems to work (for now) in Kubuntu 20.x:

# cd ~
# mkdir ~/scripts
# cd scripts
# touch ~/scripts/initrckeymap.sh
# chmod +x ~/scripts/initrckeymap.sh

... and in initrckeymap.sh do this:

#!/bin/bash
/usr/bin/ir-keytable -c -w /etc/rc_keymaps/rc6_mce_hauppauge.toml

... then:

# crontab -e

... and add and save this line near the top:

@reboot /bin/bash /root/scripts/initrckeymap.sh

... then:

# reboot

... then check with:

$ sudo ir-keytable -t

... and then launch Kodi and check if buttons are remapped.

Will have to try this in Kubuntu 18.x since that machine is the hts station vs dev station here and report back. :smile_cat:

Martii commented 3 years ago

Okay with current Kubuntu 18.x it doesn't like the rc6_mce_hauppauge.toml file in .toml file format so this repo's current rc6_mce should be the way to go for now.

Basically this changed in Kubuntu 20.x (Remember Ubuntu 20.x is the backend so should work there too)

However the good news is this methodology works (for now). :smile_cat:

@clontarfx

This should be enough I think (again for now) to add to the wiki?

Moved hts station to 20.x so no more 18.x.

Created a downstream fork branch on https://github.com/Martii/kodi-rc6-mce-nolirc/tree/whatIUse

Please let me know if you want any kind of PR. Thank you again for posting this years ago.

cotman commented 3 years ago

I had a related problem...so thanks for this.

After months of everything working correctly, with my own /etc/rc_keymaps/rc6_mce.toml on Ubuntu 20.04, suddenly most of my remote buttons didn't work; the mappings weren't being applied, presumably after a dist-upgrade.

The workaround above doesn't quite work for me - if I use it I get the following at boot:

Oct 31 11:03:26 htpc CRON[343]: (root) CMD (/usr/bin/ir-keytable -c -w /etc/rc_keymaps/rc6_mce.toml 2>&1 | logger -t ir-keytable-fudge)
Oct 31 11:03:26 htpc ir-keytable-fudge: Read rc6_mce table
Oct 31 11:03:26 htpc ir-keytable-fudge: /sys/class/rc/: No such file or directory
Oct 31 11:03:26 htpc ir-keytable-fudge: No devices found

What does work is if I create an /etc/rc.local with the following:

#!/bin/bash

/usr/bin/ir-keytable -c -w /etc/rc_keymaps/rc6_mce.toml 2>&1 | /usr/bin/logger -t ir-keytable-fudge

Then, after:

chmod +x /etc/rc.local
reboot

...in /var/log/syslog post-boot I get the following:

Oct 31 11:12:15 htpc ir-keytable-fudge: Read rc6_mce table
Oct 31 11:12:15 htpc ir-keytable-fudge: Old keytable cleared
Oct 31 11:12:15 htpc ir-keytable-fudge: Wrote 64 keycode(s) to driver
Oct 31 11:12:15 htpc ir-keytable-fudge: Protocols changed to rc-6

So: that's good, the /etc/rc_keymaps/rc6_mce.toml is successfully applied and the OK/Select button now works again on my remote.

However, other buttons that worked previously with the very same /etc/rc_keymaps/rc6_mce.toml(and with no change in Kodi) don't e.g. my back button. Bit more investigation for me to do there. The mappings are being applied for these keys (for example, for the back button, KEY_BACK, KEY_EXIT, or whatever, running ir-keytable -t shows that) but Kodi just doesn't respond to them... Bit bemused as to why, at the moment I only have the main navigation keys working, the select button and the power button, and the volume buttons - everything else doesn't work, but did previously...

Kodi is picking up some of the buttons, but without applying an action e.g. in the Kodi debug log for the back button again:

2020-10-31 11:34:47.344 T:139768719903424   DEBUG: HandleKey: 0 (0xf200, obc-61697) pressed, action is

However, for many of the others I see nothing in the Kodi log.

So, in summary:

I've posted this on the Kodi forums to see if anyone else is seeing this behaviour here: https://forum.kodi.tv/showthread.php?tid=358079

Martii commented 3 years ago

@cotman

Oct 31 11:03:26 htpc ir-keytable-fudge: /sys/class/rc/: No such file or directory

This probably means that your IR receiver hasn't been found yet. @reboot may not be at the right boot stage yet for your speed/class of machine.

Perhaps time to create a one time run systemd service but not sure where in the boot sequence it would need to be placed. udev, and related, can be a tricky thing sometimes to deal with. A short term hacky fix might be to add a sleep 1 to the shell script? If it's too long on faster machines it may not "bubble up" properly and be back to square one... although seems like that's still an issue with your setup.

I should add some more notes:

Refs:

Thanks for posting your trials and tribulations too. :smile_cat:

cotman commented 3 years ago

@Martii

Perhaps time to create a one time run systemd service but not sure where in the boot sequence it would need to be placed. udev, and related, can be a tricky thing sometimes to deal with. A short term hacky fix might be to add a sleep 1 to the shell script? If it's too long on faster machines it may not "bubble up" properly and be back to square one... although seems like that's still an issue with your setup.

This is a very good point - in fact, the rc.local hack/workaround I tried didn't actually work properly for me, I found after some testing. In the end I found this and ending up doing this.

Touch wood, that seems to be working great now.

Thanks for spotting and documenting this issue, as I would have been floundering for some time without it :smile: .

Martii commented 3 years ago

@cotman

Giving bluetooth.service a gander... it currently looks like this:

$ cat /usr/lib/systemd/system/bluetooth.service
[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)
ConditionPathIsDirectory=/sys/class/bluetooth

[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/lib/bluetooth/bluetoothd
NotifyAccess=main
#WatchdogSec=10
Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNPROC=1
ProtectHome=true
ProtectSystem=full

[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service

Since IR is RF technically, just in the light spectrum instead of radio waves, I see something that might pertain to your instance i.e. ConditionPathIsDirectory=/sys/class/bluetooth .

Would you be willing to try an altered version of this for your class without the sleep command?

Similar to this:

ConditionPathIsDirectory=/sys/class/rc/rc0

... and let us know if it works for you (bubbling and all)? I think the Unit should start when the path does exist if I'm reading systemd correctly.

You should be able to tell if your .service ran successfully with systemctl status servicename (no need for sudo on my end btw) too.

I can't really test with reliable results since mine works at @reboot stage with crontab... so perhaps we can derive a less hacky fix?

This works here (so far... after I removed lirc itself after I installed it earlier for a remote control test I'm also working on) for a service... albeit tailored closer to the the crontab test point parallel:

/etc/systemd/system/ir-keytable-setup.service (root:root, 644) NOTE /usr/local/bin/ir-keytable-setup.service if you want to use sudo systemctl enable ir-keytable-setup.service.

[Unit]
Description=Set IR Keytable
After=cron.service
ConditionPathIsDirectory=/sys/class/rc

[Service]
Type=oneshot
ExecStart=/bin/bash /usr/local/bin/ir-keytable-setup.sh

[Install]
WantedBy=multi-user.target

/usr/local/bin/ir-keytable-setup.sh (root:root, 755)

#!/bin/bash
/usr/bin/ir-keytable -c -w /etc/rc_keymaps/rc6_mce_hauppauge.toml

... so this is what I'd like to know if it works on your end without the sleep in the script. The /bin/bash is probably optional but it's in there for my tests atm. Thanks.

kopr12 commented 3 years ago

I'm on Gentoo but had the same problem, what works for me is that it accepts only .toml format, when some key is changed and written with ir-keytable, it works right away with ir-keytable -t but for it to work outside of it reboot is needed. No need for service and launch it every time on startup. This change is weird, after years of working nicely. There are some keys which are still not working, like numbers and color keys, they don't register at all outside of ir-keytable, luckily I don't use those keys.

cotman commented 3 years ago

mmm...well, this issue has cropped up again, but in a different way (possibly due to a recent 20.04 upgrade).

My rc6_mce.toml is being applied on reboot etc, and ir-keytable -t shows it's working on the command line, but I now have no remote functionality in Kodi at all i.e. no keys respond.

Bit bemused by this at the moment... No remote activity at all in the Kodi logs, and the fact that ir-keytable -t seems OK leaves me scratching my head.

There are some issues with ir-keytable and keymap loading in general with recent kernels (listed in an update to one of the above, linked, threads): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089 . Not sure if it's entirely related though.

Martii commented 3 years ago

@cotman

possibly due to a recent 20.04 upgrade

Working well with both methods retested up there and over there.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089

$ # Some ouput sanitized

$ apt-cache madison kodi
      kodi | 2:18.9+git20201024.0821-final-0focal | http://ppa.launchpad.net/team-xbmc/ppa/ubuntu focal/main amd64 Packages
      kodi | 2:18.6+dfsg1-2ubuntu1 | http://us.archive.ubuntu.com/ubuntu focal/universe amd64 Packages

$ apt-cache madison ir-keytable
ir-keytable | 1.18.0-2build1 | http://us.archive.ubuntu.com/ubuntu focal/universe amd64 Packages

$ uname -a
Linux 5.4.0-65-generic #73-Ubuntu SMP Mon Jan 18 17:25:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Way past 5.4.0-51 and 5.4.0-52

me scratching my head

Since you never got back to me about the try and responded if that worked for you... perhaps time for some glue to replace some hairs? :smile_cat:

Martii commented 3 years ago

Over there retested and working in:

$ # This is the default kernel type for Kubuntu 20.04.2.0
$ dpkg -l | grep linux-image-generic-hwe
ii  linux-image-generic-hwe-20.04                 5.8.0.44.50~20.04.30                             amd64        Generic Linux kernel image

$ uname -a
Linux 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Since dev station is now out of sync with the production machine may have to find some time to retest the systemd service (and perhaps the original method on the new box) when I have more time.

Martii commented 3 years ago

This is fun... dev station is in sync with production for a short while but...

With:

... both methods up there and over there "kind of work".

After the infamous nVidia black screen of death on the kernel update for the fourth time in the last month¹, which they should always recompile proprietary drivers like some other distros, I found that doing sudo ir-keytable -t and pressing once the OK key sends it to back-end a few thousand times i.e.

$ # Pressing OK key once and very briefly
$ sudo ir-keytable -t
[sudo] password: 
Testing events. Please, press CTRL-C to abort.
75.890492: lirc protocol(rc6_mce): scancode = 0x800f0422
75.890511: event type EV_MSC(0x04): scancode = 0x800f0422
75.890511: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
75.890511: event type EV_SYN(0x00).

76.416142: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
76.416142: event type EV_SYN(0x00).

76.548146: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
76.548146: event type EV_SYN(0x00).

76.680148: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
76.680148: event type EV_SYN(0x00).

76.812149: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
76.812149: event type EV_SYN(0x00).

76.944146: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
76.944146: event type EV_SYN(0x00).

77.076145: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
77.076145: event type EV_SYN(0x00).

77.208147: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
77.208147: event type EV_SYN(0x00).

77.340145: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
77.340145: event type EV_SYN(0x00).

77.472145: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
77.472145: event type EV_SYN(0x00).

77.604145: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
77.604145: event type EV_SYN(0x00).

77.736144: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
77.736144: event type EV_SYN(0x00).

77.868147: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
77.868147: event type EV_SYN(0x00).

78.000141: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
78.000141: event type EV_SYN(0x00).

78.132147: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
78.132147: event type EV_SYN(0x00).

78.264146: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
78.264146: event type EV_SYN(0x00).

^C

$ # Nice breakage at kernel

So the methodology probably still works, since it's translating to KEY_ENTER but now the kernel is foo'd yet again with ir-keytable which translates everywhere... Volume up or down goes wild and continues for a really long time; Any key action included.

NOTE(S): ¹ nVidia black screen of death work-around (might be cleaner ways of doing this but doing it this way)

$ # Opened TTY with Ctrl+Alt+F2 on nVidia black screen of death

$ # Find what's available from the command line since X isn't visible... hence the black screen

$ ubuntu-drivers devices
== /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0 ==
modalias : pci:*BIGLONGNUMBER*
vendor   : NVIDIA Corporation
model    : *THEMODELNUMBEROFCARD*
driver   : nvidia-driver-390 - distro non-free
driver   : nvidia-driver-460 - distro non-free recommended
driver   : nvidia-driver-460-server - distro non-free
driver   : nvidia-driver-418-server - distro non-free
driver   : nvidia-driver-450-server - distro non-free
driver   : nvidia-driver-450 - distro non-free
driver   : xserver-xorg-video-nouveau - distro free builtin

$ # Move to nouveau temporarily
$ sudo apt-get install xserver-xorg-video-nouveau
$ sudo reboot

$ # Reopened TTY with Ctrl+Alt+F2 on nVidia black screen of death since nouveau doesn't really do multiple monitors well.

$ # Move back to proprietary so it recompiles for the current kernel
$ sudo apt-get install nvidia-driver-460
$ sudo reboot

Cc: @torvalds

Martii commented 3 years ago

LOL... now they update the video driver after they killed multiple machines with the black screen of death:

The following packages will be upgraded: libjs-underscore libnvidia-cfg1-460 libnvidia-common-460 libnvidia-compute-460 libnvidia-compute-460:i386 libnvidia-decode-460 libnvidia-decode-460:i386 libnvidia-encode-460 libnvidia-encode-460:i386 libnvidia-extra-460 libnvidia-fbc1-460 libnvidia-fbc1-460:i386 libnvidia-gl-460 libnvidia-gl-460:i386 libnvidia-ifr1-460 libnvidia-ifr1-460:i386 nvidia-compute-utils-460 nvidia-dkms-460 nvidia-driver-460 nvidia-kernel-common-460 nvidia-kernel-source-460 nvidia-utils-460 xserver-xorg-video-nvidia-460 23 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

\/me goes to update again

Martii commented 3 years ago

Hmm...

$ uname -a
Linux 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Button repeat freak out seems to be fixed... but for how long. Currently using the up there oneshot system service and that appears to be working as well.

Will retest on other machine the over there option after a bit (machines have changed and probably not even initialized over there yet). EDIT Machine retested. @reboot method working okay too and no button repeat freak out.

Aside: RF media remote has been a bit twitchy since last kernel update though but it is a new addition and not IR (usually... has dual selectable modes when desired which I haven't played with much yet)

ErnstNeger commented 2 years ago

Hmm...

$ uname -a
Linux 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Button repeat freak out seems to be fixed... but for how long. Currently using the up there oneshot system service and that appears to be working as well.

Will retest on other machine the over there option after a bit (machines have changed and probably not even initialized over there yet). EDIT Machine retested. @reboot method working okay too and no button repeat freak out.

Aside: RF media remote has been a bit twitchy since last kernel update though but it is a new addition and not IR (usually... has dual selectable modes when desired which I haven't played with much yet)

Can't confirm the issues on 5.10.90-1-rpi-ARCH armv7l anymore, see #5 .