Posts by HiassofT

  • Allo Digione

    AlleyCat just saw your additional comment (maybe it was held back for moderation?)

    Non-working passthrough and missing alsa card conf sounds familiar... Blame it on the RPi sound card manufacturers who build a plethora of cards based on the same chip (wm8804 in your case) and choose to write separate sound card drivers with different card names instead of using unified drivers per chip. And blame it on the RPi kernel maintainers for accepting that stuff in their tree - this is not allowed in the upstream Linux kernel for very good reasons (you just noticed one of these).

    Anyways, could you test if this build works?

    LibreELEC-RPi2.arm-8.2-devel-20180403014343-r26324-gd125c30462.tar


    so long,

    Hias

  • Allo Digione

    The loaded modules look fine. Does it show up in Settings->System->Audio and can you select it as an audio output device?

    If yes and you still get no output (eg the GUI sound clicks) please use the Log Upload option in LibreELEC settings to upload full system logs.

    so long,

    Hias

  • No driver for eHome IR Transceiver

    Thanks a lot for the feedback, glad you got it working!

    To make this permanent create a /storage/.config/autostart.sh file with the 2 commands. You might have to put a "sleep 1" after the unbind command so the kernel has some time to do the unbinding.

    Using an MCE keyboard is going to be tricky.

    These keyboards use a special IR protocol (mce_kbd) which you have to enable in addition to the rc-6 protocol used for MCE remotes:

    Code
    ir-keytable -p rc-6,mce_kbd

    Now you should see scancodes in ir-keytable -t which you can map to keycodes (not 100% sure, never tried this, I don't have such a keyboard).

    One problem though will be that all these scancodes/keycodes will hit kodi as LIRC events, meaning you'd have to map A-Z keys and special keys like "Shift" etc won't be processed as usual.

    One way around this would be to disable eventlircd (which translates input to lirc events). If you do this you'll have to use a modified rc6_mce keytable as some keycodes (eg "KEY_OK") aren't supported by kodi.

    so long,

    Hias

  • Kernel module GPIO-IR sending IR-Codes

    In LE8.2 this doesn't work yet, but you'll be able to do that in LE9.0 (it'll work eg in current Milhouse builds).

    LE9.0 uses the newer 4.14 kernel which added support for gpio-ir-tx and pwm-ir-tx. With either one of these dtoverlays you can define a GPIO for transmitting IR data.

    If you don't need analog audio on the RPi I'd recommend using pwm-ir-tx, this results in lower CPU load compared to gpio-ir-tx (the latter has to bit-bang the GPIO at ~38kHz whereas the former offloads lots of the heavy lifting to the PWM).

    With these overlays you get a separate /dev/lircX device node and can use eg ir-ctl -S ... to transmit IR signals.

    so long,

    Hias

  • No driver for eHome IR Transceiver

    Ah, sorry, I completely forgot about the dynamic device id feature.

    The unbind from usbhid looks fine, but to use the device with the mceusb driver you have to extend mceusb's device id table. Try this:

    Code
    echo -n "054c 037c" > /sys/bus/usb/drivers/mceusb/new_id

    There exist several variants/generations of MCE USB receivers, the line above will use the MCE Gen2 variant (which is also used by the Philips eHome receiver). If this doesn't work you can tell new_id to copy the configuration from an existing device.

    This line should make mceusb use the original Microsoft (MCE GEN1) protocol version:

    Code
    echo -n "054c 037c 0 045e 006d" > /sys/bus/usb/drivers/mceusb/new_id

    "045e 006d" are the USB vendor/product ID of the microsoft MCE receiver. Have a look at the usb device id table in the mceusb driver for supported devices / variants linux/mceusb.c at master · torvalds/linux · GitHub (VENDOR_XXX definitions are a few lines above).

    so long,

    Hias

  • speeding up build process (make -j?)

    The build should automatically use all available cores.

    You can manually configure the number of parallel processes by setting the environment variable CONCURRENCY_MAKE_LEVEL (eg to 8).

    Also note that for a few packages parallel build is disabled as it doesn't work reliably (for example busybox).

    LTO also increases build time (and for most packages linking with LTO only uses a single core), so you could try setting LTO_SUPPORT="no" in ~/.libreeelc/options - but note this isn't always fully tested and building without LTO can sometimes result in link errors. PRs to fix this (mostly missing -fPIC options in libs) are welcome, though :)

    so long,

    Hias

  • Allo Digione

    If the card doesn't have an eeprom with the dtoverlay (so it's automatically enabled) you could try adding this to your config.txt (remove the old dtoverlay=hifiberry... line first)

    Code
    dtoverlay=allo-digione

    so long,

    Hias

  • VS1838B does not work in raspberry pi (SOLVED)

    There's not much info about the VS1838 except for a chinese datasheet and some posts stating that the Vishay (TSOP) receivers perform better.

    One thing you should check is that you have proper filitering on the IR receiver's VCC pin. The datasheet shows a 100uF capacitor in parallel to a 100nF - which usually should be soldered very near to the receiver. A 100 ohm series resistor can further help reducing noise on the VCC line. From the datasheet it's not clear if this is needed, but as noise on the VCC line can impact performance it won't hurt if you added that filtering.

    Personally I have only used Vishay parts so far, the well known TSOP34438 should do fine. I'm currently using the older TSOP34138 receivers here, which uses an older AGC version (1 instead of 4, the latter is recommended by Vishay for NEC and RC-5/6 remotes).

    So far I didn't have VCC noise issues with these receivers. The receivers are connected via approx. 0.5m long shielded cable and I haven't soldered filtering caps to the receiver.

    so long,

    Hias

  • Raspberry Pi 3 B+ reboot problems

    The issue seems to be a race condition in the ethernet driver when shutting down the network interface. This class of issues is one of the nastiest as it depends on exact timing if you hit the issue or not - and for that reason they can be extremely hard to reproduce.

    Simply speaking: it's rather random of the issue shows up or not.

    You don't need to spend more time on that, I managed to find out what's happening and why.

    A possible solution for the issue is already on the horizon, but it could take a bit until the fix is finished and added to the driver.

    Details of my analysis are in this RPi kernel issue: oops in lan78xx_delayedwork on kernel 4.9 when rebooting · Issue #2467 · raspberrypi/linux · GitHub

    so long,

    Hias

  • Raspberry Pi 3 B+ reboot problems

    I've seen this happen 2 or 3 times as well but it was rather hard to reproduce - most of the time reboot worked just fine.

    I just managed to reproduce it and capture the kernel output - it seems to be a bug in the RPi3B+'s ethernet driver which let's the kernel crash.

    I'll try to dig into that a bit and see if it's a general problem with the RPI3B+'s ethernet driver or something specific to LibreELEC.

    so long,

    Hias

  • 8.2.4 MR audio issue

    grael

    Do you get the same issue when using the newer firmware on 8.2.3 builds?

    Do you have Resample Qualtiy set to "GPU accelerated" in Settings->System->Audio (settings level must be advanced or expert to see/change that)?

    Does it go away when changing Resampling Quality to Medium or High?

    so long,

    Hias

  • Sharp IR Remote on Intel NUC 2820 double presses

    Wow, thanks a lot David, this must have been the most detailled bug report I've received here so far! And it contained more than enough info to reproduce and understand the issue.

    The problem stems from the combination of using a Sharp remote with an ite-cir receiver. The Sharp IR remote messages are rather long (about 86ms in the sample you provided) and the default idle timeout of the ite-cir driver is also rather high (200ms). So what is happening is that when you release the button (no matter if it's a short or a long button press) the sum of that - 286ms - exceeds the default kernel "key release" timeout of 250ms - and the last message (which is delayed to the timeout) is seen as another button press.

    With other remotes, like for example MCE remotes, this does not occur because the sum of message time (about 40ms in case of rc-6 MCE) and 200ms timeout is just below that magical 250ms limit.

    I've recently discussed these issues with long timeouts with the kernel developer and hopefully there'll be a good solution in the future - it could take a bit, though, it's all a bit tricky.

    Fortunately, there's an easy workaround you can use for now, you can manually configure the driver to use a lower timeout. The minimum timeout of ite-cir is 100ms, I'd use that and if that causes other problems I'd try a bit longer values (125-150ms).

    You can set the timeout with ir-ctl -t TIMEOUT, but keep in mind that ir-ctl expects the value to be in microseconds, not milliseconds. So use eg "ir-ctl -t 100000" to set a 100ms timeout. You can either add that to autostart.sh or add an udev rule for that. I've posted info how to do that in the Amlogic IR remote thread here: LE9.0 remote configs ir-keytable Amlogic devices (replace "meson-ir" with "ite-cir" to make this work).

    With the rather long messages you could run into key repeat more easily, you can change that with "ir-keytable -D DELAY" - that's the delay before repeat starts, default is 500ms. Ah, and here the delay is in milliseconds, so use eg "ir-keytable -D 700" to use a slightly longer delay.

    so long,

    Hias