Posts by HiassofT

  • MCEUSB IR blasting in Libreelec

    I never used irsend before, so not 100% sure what's going wrong.

    irsend seems to support a -#/--count option to send a command multiple times. Maybe this could help?

    Or it could be that lircd doesn't like the sony remote definition in your lircd.conf - OE 4.x came out rather long ago and LE 8.2 is using a much newer version of lirc. You could run "systemctl status lircd" and check if lircd logged any errors or warnings.

    so long,

    Hias

  • MCEUSB IR blasting in Libreelec

    Use whatever suits your needs best.

    We don't have plans to remove lirc - it's still very useful for supporting remotes which aren't handled by the kernel (yet). OTOH if you like to try something new have a look at ir-ctl.

    Sony equipment should use one of the sony protocol variants (12, 15 or 20 bits data) and Philips equipment rc5 (or maybe rc6) - these protocols are supported by the kernel and ir-ctl, so it should work.

    To find out which scancodes you need to transmit it's easiest to check with ir-keytable -t (also specify the protocol, eg -p sony, -p rc5 etc) and press the button of the remote.

    While ir-keytable will automatically decode all bit-length variants of a protocol you have to manually specify the bit-length when blasting. Just try the different sony protocol variant (eg ir-ctl -S sony12:0x11) and check which ones work.

    ir-ctl can also record and send raw signal files, details about this and the other options are in the manpage eg Ubuntu Manpage: ir-ctl - a swiss-knife tool to handle raw IR and to set lirc options

    so long,

    Hias

  • MCEUSB IR blasting in Libreelec

    In LE 8.2 the lircd socket is /run/lirc/lircd.socket - keep in mind that you also have to enable Lirc in LE Settings -> Services and probably have to disable in-kernel decoding if you want to use it. See the wiki page for details infrared_remotes [LibreELEC]

    As an alternative to lircd / ir-send you can also use ir-ctl for "IR blasting". You don't need to run lircd for that and can simply specify the IR protocol and scancode to transmit. eg:

    Code
    ir-ctl -S rc5:0x1234

    so long,

    Hias

  • Wolfson/Cirrus Logic audio card is now supported in official LibreELEC builds

    I recommend that you upgrade to the latest LibreELEC release (currently 8.2.0.1 for RPi), other than that you don't need to install any software/addons - Kodi works fine as a music player.

    Also have a look at the Yatse app for Android, it allows you to browse through your music library and start/stop/queue songs from your Android tablet or phone without having to turn on the TV. This is what I'm using here and it works really great.

    so long,

    Hias

  • [RPi3] OK Button doesn't work on H1 Remote

    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.

    Code
    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:


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

    Code
    evtest /dev/input/event0

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

    Code
    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

    Code
    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:

    Code
    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!

    Code
    evdev:input:b0003v05A4p9881*
 KEYBOARD_KEY_70028=enter

    To activate the config run the following commands:

    Code
    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

    Code
    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

  • Some key mappings don't work in 8.2.0.1

    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

  • [RPi3] OK Button doesn't work on H1 Remote

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

    Code
    # 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

  • [RPi3] OK Button doesn't work on H1 Remote

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

    Code
    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

    Code
    # 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

  • Wake up from suspend with apple ir remote broken in 8.2.0

    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:

    Code
    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

  • gpio lirc problem

    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