I guess this is coming from the kernel if I’m not mistaken. As DietPi is not creating kernel, it might be out of our hand. I found this old forum post on Odroid board https://forum.odroid.com/viewtopic.php?t=19926 . Looks like it should work
It should work with libcec4 package and Linux 4.14 as well: https://forum.odroid.com/viewtopic.php?p=255259#p255259
The udev rule is to allow world access, however as you’re using root, permissions are not the issue, also 660 root:video actually are reasonable defaults to me.
Which versions of cec packages are installed, actually?
root@DietPi:~# dpkg -l | grep cec
ii cec-utils 4.0.4+dfsg1-2 armhf USB CEC Adaptor communication Library (utility programs)
ii libcec4:armhf 4.0.4+dfsg1-2 armhf USB CEC Adaptor communication Library (shared library)
Ah it’s the package from the Debian repository that is installed on Buster. Meveric compiled that exact version for the Stretch images, not sure if there is any difference, but let’s simply try it out:
cd /tmp
wget https://dietpi.com/meveric/pool/backports/libc/libcec/cec-utils_4.0.4+dfsg1-2~bpo9_armhf.deb
wget https://dietpi.com/meveric/pool/backports/libc/libcec/libcec4_4.0.4+dfsg1-2~bpo9_armhf.deb
dpkg -i libcec4_4.0.4+dfsg1-2~bpo9_armhf.deb cec-utils_4.0.4+dfsg1-2~bpo9_armhf.deb
I have two other HDMI devices on that bus (including, obviously, the TV itself) but they don’t show up.
I guess it’s caused by that CEC_TRANSMIT failed error…
apt install ./path/to/package.deb can be used to have dependencies automatically installed.
It’s not a downgrade, both are version 4.0.4+dfsg1-2, but it’s a different build, probably with other build options or even patches, not sure. I’ll ask Meveric if we get it running.
Not sure whether libcec4 A works with cec-utils B. Could you retry after installing it as well:
cd /tmp
wget https://dietpi.com/meveric/pool/backports/libc/libcec/cec-utils_4.0.4+dfsg1-2~bpo9_armhf.deb
apt install ./cec-utils_4.0.4+dfsg1-2~bpo9_armhf.deb
I did install both libcec4 and cec-utils from the links you specified, using apt install.
I am still not getting anything in dmesg regarding CEC and cec-client behaves exactly the same, i.e. not transmitting anything.
CEC bus information
device #1: Recorder 1
address: 1.0.0.0
active source: no
vendor: Pulse Eight
osd string: CECTester
CEC version: 1.4
power status: on
language: eng
I have tested this on 3 (yes, three, don’t ask me why I got so many XU4s ) different Odroids, and the result is the same.
I’m now calculating the probability of 3 broken CEC Odroids ending up in my possession…
I’ve now broken down and started trying random images to test CEC and get to the bottom of this.
I’ve collected and tested these:
Debian-Jessie-1.1.4-20171121-XU3+XU4.img.xz
Debian-Stretch-1.0_RC2-20180403-XU3-XU4.img.xz
ubuntu-18.04.3-4.14-minimal-odroid-xu4-20190910.img.xz
ubuntu-20.04-5.4-minimal-odroid-xu4-20210112.img.xz
and, obviously, the latest DietPi.
The only one that has a working CEC (on all 3 XU4s, no less) is Debian Jessie.
The problem with that one is it’s old and doesn’t offer an easy way to run a new(ish) Kodi.
Which is why I was putting so much hope in DietPi, with its very nice software and configuration programs.
Basically, all I want is to have an (easily kept) updated Kodi with a few extras (transmission, samba) on a fast USB3+gigabit XU4, as I grew tired of the Raspberries’ shared USB limitations…
Since the two packages were compiled on/for Stretch, probably some other libraries not not match, causing the issue. I asked Meveric if those were patched or compiled with options different from the regular Debian repo packages, to work with Odroids. If so, we’d need to compile own Odroid-ready packages for Debian Buster.
I’ve compiled the latest libcec6 (which is already patched for kernel CEC framework) directly on the latest DietPi.
It also throws the same transmit errors as in my previous logs.
Also, dmesg does not show anything CEC-related, even though the kernel has the support (I checked in /proc/config.gz) and boot.ini has CEC enabled explicitly. It’s almost like the CEC hardware is not there when the system boots. Something is really messing with 4.x kernels on the XU4…
I’m having the same issue. Switched from Ubuntu 20.04 LTS to DietPI, because I could not get cec working.
I have never seen or used cec, so I don’t exactly know what to look for in dmesg. The following returns nothing:
root@DietPi:~# dmesg | grep -i cec
Kernel config:
root@DietPi:~# zgrep -i cec /proc/config.gz
CONFIG_TABLET_USB_ACECAD=m
CONFIG_CEC_CORE=y
CONFIG_CEC_NOTIFIER=y
CONFIG_MEDIA_CEC_SUPPORT=y
# CONFIG_MEDIA_CEC_RC is not set
# USB HDMI CEC adapters
# CONFIG_USB_PULSE8_CEC is not set
# CONFIG_USB_RAINSHADOW_CEC is not set
# CONFIG_VIDEO_VIVID_CEC is not set
CONFIG_CEC_PLATFORM_DRIVERS=y
CONFIG_VIDEO_SAMSUNG_S5P_CEC=y
So, DietPI kernel is not “far” from when CEC support was included in the kernel:
just to avoid a misunderstanding. DietPi is not creating any kernel. The kernel is provided by the base image used. DietPi is not an own OS, it is a set of scripts on top of a Debian based destro/image. The image used depends on the SBC you are using. It could be a Raspberry OS, Armbian, plain Debian or Meveric image.
─────────────────────────────────────────────────────
DietPi v6.34.3 : 26 APT updates available
─────────────────────────────────────────────────────
- Device model : RPi 4 Model B (armv7l)
- Uptime : up 3 days, 15 hours, 8 minutes
- CPU temp : 41'C : 105'F (Optimal temperature)
- LAN IP : 192.168.0.11 (eth0)
- Info Text : !!! PRODUCTION SYSTEM !!!
─────────────────────────────────────────────────────
DietPi Team : MichaIng (lead), Daniel Knight (founder), Joulinar (support)
Image : DietPi Core Team (pre-image: Raspbian Lite)
Web : https://dietpi.com | https://twitter.com/DietPi_
Donate : https://dietpi.com/#donate
DietPi Hosting : Powered by https://myvirtualserver.com
apt upgrade : Run now to apply 26 available APT package upgrades.
root@DietPiProd:~#
In my case it’s RPi OS
Image : DietPi Core Team (pre-image: Raspbian Lite)
I already forwarded the CEC topic to him and he’s testing it on Debian Buster. The libcec packages from the Debian Buster repositories have Exynos CEC support enabled by default, so likely it’s related to the kernel indeed.
Debian bug reports are likely not helpful here, since it’s not the Debian kernel but Hardkernel’s (Odroid SBC manufacturer) kernel sources, built and packaged by Meveric. But interesting to learn about the options, many thanks for sharing .