However, after upgrading using the nightlies, these keys are no longer working. Trying to follow the guide again to set it up doesn’t change anything. In fact, using evtest fails - it says the device is grabbed by another process (/usr/sbin/eventlircd).
The logs are also different for a keypress. Previously, it would show for example
2024-11-11 15:34:45.771 T:4103 debug <general>: Keyboard: scancode: 0x67, sym: 0x111 (up), unicode: 0x00, modifier: 0x0
2024-11-11 15:34:45.771 T:4103 debug <general>: HandleKey: up (0xf080) pressed, window 10003, action is Up
LIRC is for IR control, it’s used by Mesor-IR & the ir-blaster. Meson-IR is automatically loaded, unless you have a remote.conf file present under /storage/.config/.
remote.conf loads the amremote driver instead, which doesn’t used LIRC.
I’m not sure why you are your evtest for Bluetooth is returning LIRC related information, Bluetooth should be independent.
Did you previously have a remote.conf file present, and now it’s gone, switching CE back to loading the meson-ir driver?
What CE version were you on prior to updating to CE-NG 21.2?
Yes, I do have a remote.conf under /storage/.config/ but this is for an old tiny Apple remote that works over IR.
I have been on the nightlies for a long time (since 20.5/21), I would get updates almost everyday. This issue seemed to start happening after the switch to 21.2.
Also the evtest is not returning LIRC related information, it’s saying it cannot run because the device is in use by another process (eventlircd). I can stop eventlircd and then evtest will read the keys from the Sony PS3 BT Remote normally. Those logs were from Kodi. Additionally it seems to be remapping some keys as some of them are performing different actions than they use to (for example, the PS key in the middle is being mapped to KEY_MEDIA as seen in the log when it should be KEY_HOMEPAGE).
It sounds like LIRCD is grabbing the bluetooth device, but it shouldn’t be, and in the past it wasn’t. LIRCD should only grab IR devices. Will need to look into what might have changed recently.
As a temporary fix you can disable LIRCD systemctl stop lircd systemctl mask lircd
It won’t load again until you unmask it (systemctl unmask lircd). Amremote doesn’t need LIRCD, so your Apple remote will continue to work.
EDIT: can you do a journalctl | paste after LIRCD has grabbed the BT device, and post it.
Sorry I can’t get an answer for you at this moment, I will test it when I get a chance. Thank you.
However, after reading the issue you posted, I am wondering if that is actually the correct approach. Actually, the reason I remapped the RED, GREEN, BLUE, YELLOW buttons to F2 - F5 in the hwdb from my initial post was because they were not being picked up in Kodi and I’m guessing the real issue is actually what is being described in that GitHub issue.
(Of course, I probably could have avoided this whole thing if I just used different keys on the remote but I just wanted them all aligned in one row)
I don’t clearly understand the impact of having eventlircd handle the BT device, it may mean that your mapping just can’t be done through a hwdb file. When you get to it, see if the Kodi keymap editor is now able to detect those PS3 buttons
I tested this out after removing my 99-ps3-bd-remote.hwdb changes and the old 98-eventlircd.rules. Now the RED button is clearly being picked up by Kodi.
2025-01-25 15:41:36.163 T:4067 debug <general>: LIRC: - NEW 18e 0 KEY_RED devinput (KEY_RED)
2025-01-25 15:41:36.205 T:4062 debug <general>: HandleKey: 251 (0xfb, obc4) pressed, window 10016, action is ActivateWindow(TVChannels)
Following along from here https://kodi.wiki/view/LIRC, Lircmap.xml, and remote.xml, we can see that it is correctly reading and performing the action <red>ActivateWindow(TVChannels)</red> correctly.
So the question is, moving forward, will the 98-eventlircd.rules be reverted or should we adjust to this new approach?
That change only affected 4 BT devices (Nintendo Wii Remote, BD Remote Control, PS3 BD Remote Version 2, Amazon Fire TV stick). It’s up to you, I think you are the first to mention a problem.