Posts by HiassofT

OK, let's try something different. We can remap the OK key with a hwdb file.

First install the system tools addon (from LibreELEC repository -> Programs) as we'll need the evtest program. Also remove the udev conf file from the previous test.

Reboot with only the wireless remote connected, then ssh in and stop kodi.

systemctl stop kodi

Now lookup the remote in /proc/bus/input/devices. According to the infos in post 3 there should be 2 entries, one for the keyboard / remote part and one for the mouse - we're interested in the former. Look at the name entries (Name="2.4G Smart Remote") and the handler (Handlers=sysrq kbd eventX) to locate it - ignore the one with the mouse handler.

We need the event device number (eventX) and sysfs path from that block:

Quote

I: Bus=0003 Vendor=25a7 Product=5704 Version=0101

N: Name="2.4G Smart Remote"

P: Phys=usb-3f980000.usb-1.3/input0

S: Sysfs=/devices/platform/soc/http://3f980000.usb/usb1/1-1/1-1.3…01/input/input0

U: Uniq=

H: Handlers=sysrq kbd event0

B: PROP=0

B: EV=10001f

B: KEY=3f 3007f 0 0 0 0 483ffff 17aff32d bf544446 0 0 1 130f93 8b17c007 ffff7bfa d941dfff febeffdf ffefffff ffffffff fffffffe

B: REL=40

B: ABS=1 0

B: MSC=10

Display More

Now run evtest on the event device (substitute event0 with the event device number from above)

evtest /dev/input/event0

Press the OK button, you should get something like this:

Event: time 1510571041.251851, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1510571041.251851, type 1 (EV_KEY), code 352 (KEY_OK), value 1
Event: time 1510571041.251851, -------------- SYN_REPORT ------------
Event: time 1510571041.291835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1510571041.291835, type 1 (EV_KEY), code 352 (KEY_OK), value 0
Event: time 1510571041.291835, -------------- SYN_REPORT ------------

We are interested in the scancode of the button, that's the value in the EV_MSC line. In the output above that would be 70028. The EV_KEY line tells us which key code the button/key is mapped to - in above example it's KEY_OK (which kodi can't handle), we want to remap that to KEY_ENTER (which kodi supports).

Now stop evtest with ctrl-c.

Next thing we need is the modalias of the input device. We can get that with udevadm using the sysfs path from above. Run the following command, replace the long /devices/platform/... path with the one you got from /proc/bus/input/devices

udevadm test /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:25A7:5704.0001/input/input0 2>&1 | grep ^MODALIAS

This should print a line like this:

MODALIAS=input:b0003v05A4p9881e0110-e0,1,4,11,14,k77,7D,7E,7F,160,ram4,l0,1,2,sfw

The important info from that line is the "input:bXXXXvYYYYpZZZZ" part. In your case that would probably be "input:b0003v25A7p5704" (b0003 is USB bus, followed by v and uppercase USB vendor id, followed by p and uppercase USB product id) - we can ignore the stuff after that (eXXXX is the version info from USB).

Now with this info we can create a /storage/.config/hwdb.d/70-local-keyboard.hwdb file with the following content. Replace the "input:..." and the scancode in KEYBOARD_KEY_XXXXX with your values. Don't forget the "*" at the end of the evdev:input:... line!

evdev:input:b0003v05A4p9881*
 KEYBOARD_KEY_70028=enter

To activate the config run the following commands:

udevadm hwdb --update
udevadm trigger -s input

Then run evtest again, press the OK button and verify that you now see KEY_ENTER in the EV_KEY lines

evtest /dev/input/event0
...
Event: time 1510573065.623580, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1510573065.623580, type 1 (EV_KEY), code 28 (KEY_ENTER), value 1
Event: time 1510573065.623580, -------------- SYN_REPORT ------------
Event: time 1510573065.663566, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1510573065.663566, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1510573065.663566, -------------- SYN_REPORT ------------

If it doesn't work please post the evtest output and the contents of your hwdb file.

so long,

Hias

Thanks for the feedback and I'm glad it works now!

In 8.0 the Lirc option was mistakingly enabled in a lot of cases without actually doing anything, but in 8.2 this can now cause issues.

So you don't loose anything by disabling it, on the contrary, you restore the state that your remote receiver was meant to be used - handled by the Linux kernel instead of Lirc.

so long,

Hias

Sorry, had a stupid little bug in the rule - missed the "\" at the end of the first line

# 2.4G Smart Remote with keyboard and mouse inputs
ENV{ID_VENDOR_ID}=="25a7",  ENV{ID_MODEL_ID}=="5704", ENV{ID_INPUT_KEYBOARD}=="?*", \
  ENV{eventlircd_enable}="true"

I fixed the file, could you re-download and try again?

so long,

Hias

Could you try downloading this file 98-eventlircd.rules to /storage/.config/udev.rules.d/98-eventlircd.rules and then reboot

wget -O /storage/.config/udev.rules.d/98-eventlircd.rules http://www.horus.com/~hias/tmp/libreelec/24gsmartremote/98-eventlircd.rules

This'll add the following block to the usb section of eventlircd udev rules file so that eventlircd will pick up input from your remote

# 2.4G Smart Remote with keyboard and mouse inputs
ENV{ID_VENDOR_ID}=="25a7",  ENV{ID_MODEL_ID}=="5704", ENV{ID_INPUT_KEYBOARD}=="?*",
  ENV{eventlircd_enable}="true"

Please check if the keyboard part of your remote still works, I fear shift, control, caps etc will then be non-functional.

so long,

Hias

Can your try disabling Lirc in LE Settings (Settings -> Services -> Lirc),, then reboot and check if it works then?

What kind of remote are you using? Did you add or change any files in /storage/.config/ like lircd.conf, udev.rules.d or rc_maps?

so long,

Hias

Did this remote come with a USB dongle?

Please post the output of the following commands:

lsusb
dmesg | paste
cat /proc/bus/input/devices

so long,

Hias

Disable Lirc in LE settings as mentioned in the release notes LibreELEC (Krypton) 8.2.0 RELEASE – LibreELEC

so long,

Hias

Hi Jeroen,

thanks a lot for the feedback! I created a PR with the changes, so the fix should be included in 8.2.1

[LE8.2] macmini IR wakeup-from-suspend fixes by HiassofT · Pull Request #2189 · LibreELEC/LibreELEC.tv · GitHub

so long,

Hias

I did some more digging but I'm still not sure who's to blame for the wakeup issues. Could be kernel 4.11, could be atvclient - no idea.

I think the best solution is to build the hid-appleir driver as a module. Other major linux distributions do this as well, people can still use the remote without atvclient and it's also easy to disable the driver via a simple modprobe blacklist entry.

Could you please do a test with this build: LibreELEC-Generic.x86_64-8.2-devel-20171108132958-r26201-g0285ca7ff1.tar

This build includes the appleir driver as a module, to disable it create a file /storage/.config/modprobe.d/disable-appleir.conf with the following content:

blacklist hid_appleir

I've also enabled wake-from-suspend per default on the appleir USB device so you should no longer need the "echo enabled > /sys/bus/usb/devices/2-1.8.2/power/wakeup" line in autostart.sh.

Could you create the modprobe file and remove the wakeup link from your autostart.sh and test if that setup works?

so long,

Hias

FLIRC doesn't use lirc or in kernel decoding so none of the stuff from the Infrared Remotes wiki page applies here.

But "RPi freezing" could indicate a marginal power supply or too high overclock setting in which case all kinds of strange things can happen. I'd start looking into that first.

so long,

Hias

USB remote dongles are often not configurable via lirc or ir-keytable, they appear to the system like a USB keyboard. The Gmyle / Ortek VRC-1100 dongle is one such example, Another common example for this class of IR receivers is the FLIRC dongle.

gpio-ir is one of the most flexible IR receivers as it supports both in-kernel decoding and can also be used with lirc. In this case it's important that only one configuration method (either ir-keytable or lirc) is used, otherwise you have 2 configuration schemes fighting against each other - a classical race condition.

so long,

Hias

When using in-kernel decoding (aka ir-keytable configuration) you have to DISABLE lirc in LE settings.

so long,

Hias

Thanks a lot for the feedback!

Wakeup states look identical for 8.2.0 and my test build, no idea why wakeup doesn't work with 8.2.0.

I'm inclined to disable the kernel appleir driver again in official builds, but I'll wait a bit for feedback from the other thread (atvclient not working).

so long,

Hias

Could you test this build (it has the appleir kernel module disabled): LibreELEC-Generic.x86_64-8.2-devel-20171030102100-r26198-g0239080387.tar

so long,

Hias

Thanks for the info!

This is very puzzling. Systemctl start atvclient does exactly the same, it runs atvclient -m, and no errors are logged. No idea why one invocation should work but not the other.

You could try playing around with the Harmony settings. A lot of IR issues stem from the Harmony working quite differently than original remotes. For example, command repeat should be set to 0. Another thing to check is the configured remote profile - there are 2 different apple remotes, see eg here: Apple remote - Official Kodi Wiki . Try both the 6 and 7 button remote profiles.

If none of this helps, it's worth testing with lircd instead of atvclient. First disable atvclient:

systemctl mask atvclient

then reboot (you can later re-enable atvclient with "systemctl unmask atvclient" plus rebooting).

Now copy /etc/lirc/lirc_options.conf to /storage/.config/lirc_options.conf and change the driver and device configuration:

driver          = macmini
device          = /dev/usb/hiddev0

Note: if you have more than one /dev/usb/hiddev* file, test with all of them.

You'll also need a /storage/.config/lircd.conf file matching your remote. You can either try the one from the kodi wiki page linked above or this one - depending on which remote you have configured - lircd.conf.macmini

If you use the latter you have to change the KEY_... definitions to KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, KEY_OK and KEY_BACK to get normal control.

Now you can enable Lirc in LibreELEC Settings -> Services and see if it works.

If none of the lircd.conf files work, you can try to create your own using irrecord. Make sure you disable lirc in LE settings before, otherwise irrecord can't access the IR receiver device.

irrecord -H macmini -d /dev/usb/hiddev0

After running that copy the newly created REMOTENAME.lircd.conf file to /storage/.config/lircd.conf and enable lirc in LE settings again.

Note: I haven't tested this myself (don't have the hardware), so it could be that I got something wrong. In this case just post here

so long,

Hias

According to the logs you posted you seem to have a FLIRC dongle plugged in. That raises 2 important questions:

What kind of remote are you using?

Do you intend to use the remote with the built-in IR receiver or with the FLIRC dongle?

so long,

Hias

This sounds like atvclient might be starting a bit too early.

Could you test if it works after running the following commands:

systemctl stop atvclient
systemctl start atvclient

also please post the output of the following commands (after running the commands above)

cat /proc/bus/input/devices | paste
systemctl status atvclient | paste

so long,

Hias

Hi Jeroen,

interesting that atvclient always worked for you - I'll probably need have a closer look into the differences between your setup and the one where atvclient failed.

Here's a build without the apple-ir driver: LibreELEC-Generic.x86_64-8.2-devel-20171030102100-r26198-g0239080387.tar

It would also be great if you could run the following commands on 8.0.2, 8.2.0, 8.2.0 with atvclient disabled, and the build above and post the output - this should hopefully give some hints if other wakeup related settings have changed:

cat /proc/acpi/wakeup
find /sys/devices -name wakeup | xargs grep .

so long,

Hias