Posts by HiassofT

  • LIRC key unexpected repeat issues since 8.0.0

    Quote from metaron


    I'm not convinced that the gpio_ir_recv device is honouring the ir-keytable --delay commands. Setting this to 5000ms (5 sec) via the command line I still start getting rapid key repeats after about a second...


    I cannot reproduce this, this seems to be working fine here (with a Hauppauge rc5 remote).

    Code
    LibreELEC:~ # ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event1) with:
        Driver gpio-rc-recv, table rc-hauppauge
        Supported protocols: unknown other lirc rc-5 rc-5-sz jvc sony nec sanyo mce-kbd rc-6 sharp xmp
        Enabled protocols: lirc rc-5
        Name: gpio_ir_recv
        bus: 25, vendor/product: 0001:0001, version: 0x0100
        Repeat delay = 5000 ms, repeat period = 125 ms

    Key repeats in kodi are starting after a 5 second delay.

    irw output also shows the 5 second delay.

    Monitoring input events (you need to stop kodi and eventlircd to do this) is also ok, note the timestamp of the second repeat.

    Code
    LibreELEC:~ # systemctl stop kodi
LibreELEC:~ # systemctl stop eventlircd
LibreELEC:~ # ir-keytable -t | grep KEY
1488143711.483995: event type EV_KEY(0x01) key_down: KEY_UP(0x0001)
1488143716.634673: event type EV_KEY(0x01) key_down: KEY_UP(0x0001)
1488143716.764672: event type EV_KEY(0x01) key_down: KEY_UP(0x0001)
1488143716.894673: event type EV_KEY(0x01) key_down: KEY_UP(0x0001)
1488143717.024670: event type EV_KEY(0x01) key_down: KEY_UP(0x0001)
...

    so long,

    Hias

  • LIRCD / Remote Problem since Updating to Version 8


    Could you upload the full dmesg (just do "dmesg | paste" and post the URL) and lsmod output?

    Are you using userspace lirc (i.e. have you create a lircd.conf in the .config dir)? Are you running ir-keytable or other commands via http://autostart.sh/udev rules/... to setup a custom remote configuration? Which protocol/configuration are you using on your oneforall remote, is it MCE?

    If you are using the nuvoton IR receiver (of your zbox) and the remote configured to (rc6) MCE protocol could you try running "ir-keytable -p rc-6 /sys/class/rc/rc0/" (double check if rc0 really is the nuvoton, it could also be rc1 since you have 2 IR receivers installed) and test if you get any events via "ir-keytable -t"?

    It's quite odd that on the nuvoton IR the only enabled protocol is lirc and not lirc + rc-6. The kernel should enable the rc-6 protocol from loading the rc-rc6-mce keymap. But there's also a kernel bug, even if it enables the rc-6 protocol it didn't load the rc-6 protocol decoder - so decoding doesn't work. Manually enabling the protocol (eg via ir-keytable -p) triggers protocol decoder loading and decoding works fine again. I've already reported that bug and it was confirmed: Bug: decoders referenced in kernel rc-keymaps not loaded on boot — Linux media

    so long,

    Hias

  • Raspberry Pi 1 & HifiberryDAC

    Could you please test if this build works on your RPi1:
    LibreELEC-RPi.arm-8.0-devel-20170225092739-r25402-g2c2b9b7.tar

    This build contains backported fixes to the clock framework, without that switching between HDMI and I2S audio caused black screen and lockups on the RPi0.

    LE8: add backported RPi kernel fixes by HiassofT · Pull Request #1389 · LibreELEC/LibreELEC.tv · GitHub
    thread-3848.html

    Would be good to know if you are experiencing the same issue or another.

    so long,

    Hias

  • LibreELEC 8.0.0 build with Wolfson/Cirrus Logic audio card drivers

    I've uploaded a LibreELEC 8.0.0 build with Wolfson/Cirrus card drivers

    RPi: LibreELEC-RPi.arm-8.0.0-HiassofT.tar
    RPi2/3: LibreELEC-RPi2.arm-8.0.0-HiassofT.tar
    Source: GitHub - HiassofT/LibreELEC.tv at 8.0.0-cirrus

    Support for the Wolfson/Cirrus card is now also included in the LibreELEC master branch (which will become LibreELEC 9.0) and in Milhouse testbuilds.

    These 8.0.0 builds are plain LibreELEC 8.0.0 code with backports from LibreELEC master (newer RPi kernel with Wolfson/Cirrus driver plus the config scripts package). I've also included the bcm2835 DMA splitting fix which was present in kernel 4.4 but got missed in kernel 4.9, this should resolve clicking noise when playing back 192kHz audio.

    If you are upgrading from OpenELEC or LibreELEC 7.0.2 or earlier please note that the method to setup custom mixer configurations has changed. The udev rule will no longer work, custom configurations are now handled via /storage/.config/rpi-cirrus-config.sh

    Detailled installation and configuration instructions are on my website: "HiassofT" LibreELEC RPi builds

    so long,

    Hias

  • LibreELEC 7.0.3 build with new, reworked Wolfson/Cirrus driver

    Quote from JohnnyL


    Update: I tried fixing the audio config to 192kHz, but ran into another problem. Input files with sampling frequencies up to 96kHz played back fine, but files at 192kHz didn't - the audio was chopped up a few times per second, sounding terrible.

    Thanks for reporting back!

    I could reproduce the issue here, turned out that I already fixed this bug (in the bcm2835 DMA controller driver) last june but it somehow got lost during upstreaming. I've resent the path to the LKML and will include it in the upcoming LE8 Cirrus build.

    so long,

    Hias

  • Streamzap Remote not working on 7.95.3 Update

    Thanks for the info!

    I could now reproduce the issue locally (using gpio-ir-recv on RPi with the rc-streamzap keymap) and it looks like we are facing 3 issues here:

    1) The kernel doesn't seem to automatically load the rc5 protocol decoder (which handles the "rc-5-sz" RC5 streamzap protocol) when the streamzap module is loaded.. LE 7.0.x / kernel 4.4 dmesg contains the line "IR RC5(x/sz) protocol handler initialized" which is missing in 4.9/4.10 kernel logs. This seems to be a kernel bug.

    2) The fallback, ir-keytable -a, fails for 2 reasons:
    2.1) ir-keytable in LE was too old and didn't know about the RC5 streamzap protocol - the v4l-utils bump fixes this.
    2.2) even with the newer ir-keytable the streamzap keymap won't load because the protocol type "RC5_SZ" is invalid - that should be "rc-5-sz" instead.

    Simply speaking: in LE 7.0 the kernel setup your remote correctly, but in LE 7.95 that fails. ir-keytable also failed in LE 7.0 but that probably wasn't noticed before.

    I've just added another commit to the PR that fixes the illegal protocol in the file. That fix should be included in the next Milhouse build #0214. Please test if that works for you and report back.

    so long,

    Hias

  • JustBoom DAC Zero

    A very quick update before heading off to bed:

    I could reproduce the issues on Raspbian (kernel 4.9.9, kodi 17, probably any I2S soundcard that's an I2S slave) as well if I remove console=serial0 from cmdline.txt. Likewise adding that to the LE cmdline.txt prevents crashing.

    Just outputting sound via ALSA (eg running speaker-test -c 2 while kodi is setup for HDMI audio out) hasn't crashed so far.

    To crash the RPi0 we need no serial console (probably no serial device open at all) and kodi 17 switching audio out from HDMI to ALSA (short screen blank) and back to HDMI (hard crash).

    so long,

    Hias

  • JustBoom DAC Zero

    milhouse just tested with build 0211 and Justboom, same result (short blank screen when selecting audio device, crash when audio device was closed).

    Then I did another test with the Cirrus card instead of the Justboom, in this case it worked.

    Might sound odd, but an educated guess leads me to the conclusion something odd might be going with the kernel clock framework:

    Justboom DAC is configured as an I2S slave (RPi configures it's internal clocks), Cirrus is an I2S master (it drives the I2S clock and the RPi I2S driver skips changing the RPi clocks).

    Screen glitches when changing the RPi clocks have been reported before, and if the clocks are configured wrong (eg turned off completely) lockups can happen as well.

    Now to find out what exactly is happening, and why it only happens with the LE kernel not the official one. I guess we need Dom's and Phil's help.

    BTW: I could be wrong, this is just an educated guess.

    so long,

    Hias