I’ve got a Nexbox A95X-B7N (2G, 16G) with PCB labelled as A7_S905X_V2_3.
I’m using the dtb file gxl_p212_2g.dtb, as per the ‘Which DTB file should I use’.
However, there is no direct match for my box in the list, as it only mentions a 2G, 8G combination.
I’ve confirmed that my unit has 16G by running an older LibreELEC version again.
When the box boots for the first time using 8.90.4, then the supplied remote doesn’t work at all.
However, if I copy the a95x file from /usr/lib/udev/rc_keymaps/a95x to /storage/.config/rc_keymaps/a95x and create the appropriate entry in /storage/.config/rc_maps.cfg, the remote works just fine.
The cfg file is as follows:
meson-ir * a95x
I then load the config and start Kodi and eventlircd back up with:
The remote has always worked out of the box with previous LibreELEC releases from kszaq.
I figured it was time to do a fresh install, as I saw that updating to CoreELEC from a kszaq release wasn’t supported.
I’m guessing this is a bug, or perhaps something a bit amiss with the device tree that means it doesn’t quite match my device.
If there is any troubleshooting information I can gather, please let me know.
With regards to the comparisons, then it’s simply an attempt to provide useful information with regards to troubleshooting the issue and identifying at what point it got broken. We can then play the differences and changes game to see what might have changed to break it.
For example, it works out of the box with these two images:
LibreELEC-S905.arm-adamg-1.0.5.img
LibreELEC-S905.arm-adamg-1.0.8.img
It’s with these that I was making the most direct comparison, as I know that you created them.
I can also say for sure that it’s broken in:
LibreELEC-S905.arm-8.90.6.img
which was the last build I tried before the fork to CoreELEC.
Hopefully, @TheCoolest might be able to shed some light on the issue.
In the meantime, I’ll do a fresh install on a different memory stick and see if I can find anything in the logs which might be useful.
I can confirm this issue on X96 S905X box. It seems that the remote.conf and also the dtb are no longer automatically copied from the Android firmware upon first boot like in previous builds.
@Bagpuss@KOPRajs I have already said that these builds DO NOT use remote.conf. The DTB has never been copied from the Android firmware, not even in kszaq’s releases.
@anon88919003 Totally understand about CoreELEC not using remote.conf. I’ve merely been trying to see what change occurred which has broken things. It would seem that the move away from remote.conf is a factor in this.
For the LibreELEC-S905.arm-8.90.6 build, the problem was simply that there was no a95x remote definition in the image. I’ve checked the /usr/lib/udev/rc_keymaps directory and the file just doesn’t exist.
However, it is present and correct in the latest CoreELEC image, as evidenced by the fact that it works when copied into /storage/.config/rc_keymaps.
I’m still looking through the logs on a fresh install to see if there are any messages that might point me in the right direction.
@anon88919003 Any chance you could be a bit more verbose?
From what I can see, the rc_maps.cfg file in /etc is hard wired to use libreelec_multi_amlogic instead of a95x.
That file is for various of MCE compatible remotes, which doesn’t include the standard A95X remote.
The logs did give me a bit of a pointer, as there were lines like this in the journal.
Mar 05 22:16:37 CoreELEC kernel: input: MCE IR Keyboard/Mouse (meson-ir) as /devices/virtual/input/input3
Mar 05 22:16:37 CoreELEC kernel: rc rc0: lirc_dev: driver ir-lirc-codec (meson-ir) registered at minor = 0
Mar 05 22:16:39 CoreELEC systemd-logind[2557]: Watching system buttons on /dev/input/event3 (MCE IR Keyboard/Mouse (meson-ir))
Looks like it’s built here:
Am I looking along the right lines?
If so, I might try rebuilding the squashfs with the change, assuming I can find time to setup the environment.
Please consider also adding a keymap for X96 standard remote. It is a generic remote used on many boxes and it used to work out of box on previous releases.
@anon88919003 Thanks for getting the fix into the next release. Much appreciated.
Was wondering if there’s a good resource (other than the source) which documents how all the remote infrastructure hangs together?
Does the current code just use the multimap by default, or is it more discriminatory e.g. it installs a different map, dependent on the device tree in use?
No, there’s a multimap with just a few remote configurations in it however if a user has their own remote configuration installed then that takes priority over the multimap.