Posts by HiassofT

This is normal. This particular IR receiver dongle registers as a keyboard/mouse with the system, you can't use ir-keytable to configure it.

so long,

Hias

Quote from JumpY

i have also problems with lirc. For several version, (last was LE 8.02 with Kodi Krypton 17.3) i have only added "dtoverlay=lirc-rpi" to config.txt and it works "out of the box"on my Raspberry PI3. Now i have installed LE 8.22 and remote doesnt anything...

Use dtoverlay=gpio-ir instead of dtoverlay=lirc-rpi. Also read the wiki page for details about this.

so long,

Hias

Quote from pipipapa

i type ir-keytable, find protocols don't enable,but i don't how to fix it.

Quote from pipipapa

Code

LibreELEC:~ # ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event0) with:        
Driver sunxi-ir, table rc-empty 
Supported protocols: rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp        
Enabled protocols:        
Name: sunxi-ir        bus: 25, vendor/product: 0001:0001, version: 0x0100        Repeat delay = 500 ms, repeat period = 125 ms

The sunxi-ir driver doesn't support the raw "lirc" protocol - it's missing in the list of "Supported protocols". This means you can't use lircd, you have to use ir-keytable.

I suggest you switch to a current LibreELEC version and then follow the guiide in the wiki: infrared_remotes [LibreELEC]

so long,

Hias

Please follow the instructions in the wiki infrared_remotes [LibreELEC]

Most tutorials that you find on the 'net, especially those that talk about setting up lirc or lirc_rpi, are heavily outdated and/or just plain wrong. The wiki contains everything you need to know and do.

so long,

Hias

Kodi / LibreELEC on RPi doesn't use the vc4 drm driver, AFAIK it uses the (downstream) bcm2708 framebuffer driver and the (also downstream) video core shared memory driver (vcsm) to interface to the GPU.

Could well be that other downstream drivers are involved, but I leave this to popcornmix to answer, he's the expert in this area, my knowledge about RPi graphics stuff is quite limited.

so long,

Hias

mchehab I managed to get LibreELEC 8.2.2 with upstream 4.14.13 booting on RPi3. The process is a bit tricky/hacky and Kodi won't start - not sure if LibreELEC's Kodi can work at all on upstream kernel, could well be that the graphics layer relies on some downstream kernel changes. popcornmix should be able to tell more.

The official way to use a different kernel in LE is to fully rebuild it from source, but this shortcut could be enough for a few quick tests:

I've done this by starting with a plain LE 8.2.2 installation on sdcard - it'd probably be best if you follow the same route, then you can enable ssh and install tvheadend from Kodi. Even if kodi won't work with upstream kernel tvheadend should run and you can test it over the net.

LE uses an initrd to mount the read-only rootfs (that's the SYSTEM) file on the FAT partition. It's compresses with LZ4 so you'll also need to enable LZ4 squashfs support in the kernel.

I used this (hacky) script to extract the initramfs from the kernel image (KERNEL file on FAT partition):

#!/bin/bash

if [ $# -ne 2 ] ; then
    echo "usage: $0 zImage initramfs.cpio"
    exit 1
fi

zImage="$1"
export LC_ALL="C"

# find start of gziped kernel in the zImage file:
pos=`grep -P -a -b -m 1 -o '\x1F\x8B\x08' "$zImage" | cut -f 1 -d :`

if [ -z $pos ] ; then
    echo "gzipped kernel not found in zImage"
    exit 1
fi

echo "-I- Extracting kernel image from $zImage (start = $pos)"
dd if=$zImage bs=1 skip=$pos | gzip -d > /tmp/kernel.img

# find gzipped cpio archive in kernel
pos=`grep -P -a -b -m 1 --only-matching '\x1F\x8B\x08' /tmp/kernel.img | cut -f 1 -d :`

if [ -z $pos ] ; then
    echo "gzipped cpio not found in kernel.img"
    exit 1
fi

dd if=/tmp/kernel.img bs=1 skip=$pos | gunzip > "$2"

I started that with "./extract-initramfs KERNEL initrd-8.2.2" and copied the initrd-8.2.2 file to the root of the FAT partition. Fortunately there are no kernel modules in the initramfs, so we don't need to change that.

I then compiled a 32bit (ARCH="arm") upstream kernel using multi_v7_defconfig. I patched the the rpi3 DT so I could use PL011 as serial console and manually enabled CONFIG_SQUASHFS_LZ4. Then I copied zImage and the bcm283*.dtb files to a "upstream" directory on the FAT partition.

To get the upstream kernel booting I used these additional settings in config.txt - the initramfs entry brings in the previously extracted initrd

[PI3]
kernel=upstream/zImage
device_tree=upstream/bcm2837-rpi-3-b.dtb
avoid_warnings=2
initramfs initrd-8.2.2

and this cmdline.txt:

boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 ssh root=/dev/ram0 console=ttyAMA0,115200 earlycon=pl011,mmio32,0x3f201000

This is enough to get LE booting, but the initramfs will complain loudly because it doesn't find matching kernel modules in the rootfs (SYSTEM file) - after a minute it will continue booting up, but of course without modules it's a bit meh.

So I simply installed the modules to a temp directory on my PC, unsquashed the SYSTEM in a fakeroot, copied the modules into the unsquashed rootfs and then ran mksquashfs

cd ~/upstream-kernel
mkdir /tmp/modules
INSTALL_MOD_PATH=/tmp/modules make modules_install
cd ~/le-test
fakeroot
unsquashfs SYSTEM
cp -r /tmp/modules/lib/modules/4.14.13-dirty squashfs-root/usr/lib/modules/
mksquashfs squashfs-root SYSTEM-4.14 -comp lz4

Then I copied that SYSTEM-4.14 file to the root of the FAT partition, naming it SYSTEM. LE then booted up fine and could load at least some modules.

Hope I didn't miss an important step, if you have problems or questions just ping me.

so long,

Hias

smp have you tested if you get the same results if recording to a USB HDD instead of sdcard?

I also noticed that for some unknown reason the LE RPi kernels use the NOOP IO scheduler by default, x86 LE kernel and RPi foundation kernels use the CFQ scheduler.

You could also try changing the IO scheduler, this can be configured per device. eg:

echo cfq > /sys/block/sda/queue/scheduler

so long,

Hias

You seem to have some leftover cruft (in autostart.sh?) where you kill lircd, load the lirc_rpi module and then start lircd with the wrong options. Remove that alltogether.

Dec 15 19:37:59 Familyroom sh[382]: mkdir: can't create directory '/var/run/lirc': File exists
Dec 15 19:37:59 Familyroom sh[382]: killall: lircd: no process killed
Dec 15 19:37:59 Familyroom kernel: lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
Dec 15 19:37:59 Familyroom kernel: lirc_rpi: gpio chip not found!
...
Dec 15 19:37:59 Familyroom lircd-0.9.4d[395]: Info: Initial device: /dev/lirc0
Dec 15 19:37:59 Familyroom lircd-0.9.4d[395]: Notice: 'lirc' written to protocols file /sys/class/rc/rc0/protocols
Dec 15 19:37:59 Familyroom lircd-0.9.4d[395]: Warning: --uinput is deprecated, check the lircd manpage.

To get your hauppauge remote working it's probably enough to add the rc-map-name parameter to the dtoverlay line:

dtoverlay=gpio-ir,rc-map-name=rc-hauppauge

An alternative to that is to configure the keymap via /storage/.config/rc_maps.cfg

* * hauppauge

so long,

Hias

Please post the output of the following commands running LE 8.2.2

journalctl -a | paste
ir-keytable | paste
ir-keytable -r | paste

so long,

Hias

Lexridge the question in this thread was about an MCE remote on x64, where in-kernel decoding is used, and having Lirc enabled in addition to that will often cause double keypresses.

You, however, seem to be using a GPIO remote on RPi using the lirc-rpi dtoverlay, which is something completely different.

I'm not exactly sure what problem you are experiencing. There were no changes between 8.2.1 and 8.2.2 in that area and the dmesg lines you posted should be there both with 8.2.1 and 8.2.2 if you have the "dtoverlay=lirc-rpi" line in config.txt.

Anyways, if you are using lirc-rpi it's best to switch to gpio-ir and disable Lirc in LE settings. lirc-rpi will be dropped in LE9, gpio-ir is the more modern successor (which doesn't need lircd to work, decoding is performed in the kernel). Read the wiki for details: infrared_remotes [LibreELEC]

so long,

Hias

See the 8.2.1 release notes: LibreELEC (Krypton) v8.2.1 MR – LibreELEC

Go to LE Settings -> Services and disable Lirc

so long,

Hias

jahutchi could you test if the issue also occurs on your Revo with other Linux distributions running a current kernel like Ubuntu? And if reverting the same commit fixes it there?

Next step then would be to check if the issue also occurs if the DVB device is accessed directly (eg using VLC, Kaffeine or some other DVB player) or if tvheadend plays some part in it.

Then that needs to be discussed with upstream (dvb driver / tvheadend / kernel maintainers).

so long,

Hias

A step-by-step guide is available in the wiki: infrared_remotes [LibreELEC]

If your remote is compatible to the Microsoft Media Center (MCE) remote, you just need to add the following line to config.txt:

dtoverlay=gpio-ir

Note that the use of lirc_rpi is deprecated and will be removed in LE9. If needed gpio-ir can still be used with lirc, you have to put your lircd.conf file into /storage/.config/ and enable Lirc in LE Settings -> Services.

so long,

Hias

Please don't cut down logs, always upload full logs to a paste site (eg using the "paste" command in LE).

There are quite a lot of USB errors in the snippet you posted, but without having the full log it's impossible to know if they are related to your USB IR receiver or not.

If irw is showing button presses after resume but you don't get them in kodi you could also try disabling the kodi-lirc-suspend systemd service and see if this helps:

systemctl mask kodi-lirc-suspend.service

If it didn't help or made things worse use "unmask" instead of "mask" in the above command to re-enable it again.

so long,

Hias

AFAICT the issue you are seeing is caused by a bug / missing feature in the meson-ir driver. The in-kernel protocol decoders need to receive a trailing space (or "timeout") to know when the IR transmission is finished, and meson-ir doesn't seem to generate that.

So what's happening is that when you press a new button meson-ir sends a rather long space to the decoder which finishes decoding of the last received IR signal (the "old button") and then goes on decoding the new signals - IOW every last button is leaking into the next button.

Until this bug is fixed it's better to use userspace lirc instead, it does it's own timeout/decode-end handling and should work fine.

so long,

Hias

With older kernels you have to add vers=2.1 to the options - the default is 1.0 (aka SMB1) and thus you get the error(95) not supported.

eg.

mount -t cifs -o vers=2.1,username=xxx,password=xxx //xbmc.lan/MyBookHias/ /mnt/temp/

so long,

Hias

It's best to configure the Harmony as a MCE remote (not MCE keyboard), this setup is supported in LibreELEC out of the box.

so long,

Hias

In most cases you don't need lirc, the majority of remotes are supported directly by the linux kernel.

It's main purpose is to support rather odd remotes that aren't supported by the kernel and to use standard remotes with older IR receiver drivers (like lirc_rpi on the Raspberry Pi) that don't offer in-kernel decoding of remote signals - therefore lirc currently ships with a default config that is similar to the kernel default IR config.

In LE9 support for those older lirc-only IR drivers will be dropped and the plan is to use Lirc only for those "odd remotes" and only if the user installed a custom lirc configuration file.

so long,

Hias