agners
commented
3 years ago Thanks for the detailed report! Hm, it seems the the drivers are enabled and the HDMI CEC access is given, but for some reason its not properly communicating.
Closed DCSBL closed 1 year ago
agners
commented
3 years ago Thanks for the detailed report! Hm, it seems the the drivers are enabled and the HDMI CEC access is given, but for some reason its not properly communicating.
oramirite
commented
3 years ago This is identical behavior to what I'm experiencing on my Pi 3B+. I just got this and am a fairly new HA user so I was trying to ensure it wasn't user error. CEC does seem to be active, because rebooting my Pi sends an input signal and switches my AVR over to HDMI5 where my Pi is plugged in.
As a Docker guy myself, is it possible this is related to containerizing everything, and that the CEC device isn't properly accessible? Just a stab in the dark...
oramirite
commented
3 years ago I just ran a duplicate of the CEC extension container manually with an interactive terminal in Privileged mode. A CEC scan works fine when this is done.
A workaround could be to allow this extension to run in privileged mode via the Supervisor panel, but that's not ideal since you'd, like... need that for the extension to work :P
It sounds like there's just some kind of device path or privilege missing from the container to get full access to CEC.
stale[bot]
commented
3 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
DCSBL
commented
3 years ago Well, I don't think it is fixed (yet)
andybjackson
commented
3 years ago I have the same experience.
N36
commented
3 years ago Same situation here on pi 3b+. HDMI cec suddenly stopped working recently. Caused HA to repeatedly reboot on loop. Had to remove hdmi_cec: from configuration.yaml to get HA stable again.
boszme
commented
3 years ago I've made some research and I believe the current docker image is compiled only for RPI based devices: /dev/vchiq is very specific for RPI: https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/misc/vc04_services/Kconfig https://raspberrypi.stackexchange.com/a/54590 https://github.com/Pulse-Eight/libcec/blob/76551ea1dd9a55f0ce1533e440dc12dbc594f7ba/src/libcec/adapter/RPi/RPiCECAdapterDetection.cpp#L51
I think the CEC addon should be blocked from installing on non-RPI based installations and a separate docker image should be created for Odroid based devices.
Based on this, my understanding is that libcec need to be compiled separately for the various OS/HWs setups, not sure if multiple detection modes could be added at the same time: https://github.com/Pulse-Eight/libcec/blob/master/docs/README.linux.md
boszme
commented
3 years ago Took a second look at this: I'm not a C/C++ expert, however it seems to me that libcec supports multiple detections to be compiled with; probably just need to recompile libcec with Odroid(even though I'm not sure yet which is the Odroid specific one) AND RPI specific cmake flags
boszme
commented
3 years ago I just ran a duplicate of the CEC extension container manually with an interactive terminal in Privileged mode. A CEC scan works fine when this is done.
A workaround could be to allow this extension to run in privileged mode via the Supervisor panel, but that's not ideal since you'd, like... need that for the extension to work :P
It sounds like there's just some kind of device path or privilege missing from the container to get full access to CEC.
@oramirite you've tested this on RPI and NOT on Odroid, right?
boszme
commented
3 years ago So it seems it is already compiled with multiple flags, however it is still failing on searching for the /dev/vchiq which is only exists on RPI: https://github.com/home-assistant/addons/blob/master/cec_scan/Dockerfile#L35
strace output:
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [], 8) = 0
clone(child_stack=0xffffaf127a70, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|0x400000, parent_tid=[17], tls=0xffffaf127b88, child_tidptr=0xffffaf5540c4) = 17
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0xaaaae41b716c, FUTEX_WAKE_PRIVATE, 1) = 1
openat(AT_FDCWD, "/dev/vchiq", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
writev(1, [{iov_base="* failed to open vchiq instance", iov_len=31}, {iov_base="\n", iov_len=1}], 2* failed to open vchiq instance
) = 32
exit_group(-1) = ?
+++ exited with 255 +++
bash-5.0#Found the root cause: it is failing due to the RPI userland code. The AdapterFactory.cpp doesn't check in runtime which OS/HW configuration is currently running on; if the RPI cmake flag is compiled in, it will try to invoke those adapter calls anyways.
However the bcm_host_init() function calls an exit(-1); if the initialization fails 🤯 which causing the issue on other OS/HW setups than RPI..
https://github.com/Pulse-Eight/libcec/blob/76551ea1dd9a55f0ce1533e440dc12dbc594f7ba/src/libcec/adapter/RPi/RPiCECAdapterCommunication.cpp#L458 https://github.com/raspberrypi/userland/blob/master/host_applications/linux/libs/bcm_host/bcm_host.c#L99
boszme
commented
3 years ago Reported to libCEC project: https://github.com/Pulse-Eight/libcec/issues/572
agners
commented
3 years ago @boszme nice find! So does returning in that case instead of exiting makes it work for other platforms?
It looks that libcec is rather stale lately. Are there maybe forks of it which are also better suited for other hardware?
agners
commented
3 years ago Btw, we do compile libcec in our base container, see: https://github.com/home-assistant/docker/blob/master/Dockerfile#L116
So if a patch fixes the problem, we can add it there for now.
boszme
commented
3 years ago I've checked if I can fix the code with some patch, but it seems way more complicated than I thought (or I'm lost in libCEC's code :D ). So as a quick check I've re-built a local docker image without the RPI flags, here are the results:
➜ ~ docker run --privileged -it --entrypoint /bin/bash local/cec-addon-aarch64:2.4
bash-5.0# ./run.sh
[18:31:55] INFO: Starting CEC client scan...
opening a connection to the CEC adapter...
requesting CEC bus information ...
ERROR: [ 106011] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
ERROR: [ 106011] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
ERROR: [ 106011] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
CEC bus information
===================
device #1: Recorder 1
address: 2.0.0.0
active source: no
vendor: Pulse Eight
osd string: CECTester
CEC version: 1.4
power status: on
language: eng
currently active source: unknown (-1)
ERROR: [ 106011] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
bash-5.0# cec-client -l
libCEC version: 4.0.3, git revision: libcec-4.0.3, compiled on Sun Jun 20 18:15:35 UTC 2021 by root@localhost on Linux 5.10.25-linuxkit (aarch64), features: P8_USB, DRM, P8_detect, Exynos, Linux, AOCEC
Found devices: 1
device: 1
com port: Linux
vendor id: 0000
product id: 0000
firmware version: 0
type: Linux
bash-5.0#Two conclusions I've made (but I might be wrong):
boszme
commented
3 years ago Another test run: built another image without Linux and AOCEC detection and it couldn't find anything :(
➜ ~ docker run --privileged -it --entrypoint /bin/bash local/cec-addon-aarch64:2.4
bash-5.0# cec-client -l
libCEC version: 4.0.3, git revision: libcec-4.0.3, compiled on Sun Jun 20 20:34:00 UTC 2021 by root@localhost on Linux 5.10.25-linuxkit (aarch64), features: P8_USB, DRM, P8_detect, Exynos
Found devices: NONE
bash-5.0# ./run.sh
[20:39:12] INFO: Starting CEC client scan...
autodetect FAILED
bash-5.0#And it is pretty much the same with AOCEC, so I'm not sure now which adapter should be used on N2+
bash-5.0# cec-client -l
libCEC version: 4.0.3, git revision: libcec-4.0.3, compiled on Mon Jun 21 05:01:50 UTC 2021 by root@localhost on Linux 5.10.25-linuxkit (aarch64), features: P8_USB, DRM, P8_detect, AOCEC
Found devices: NONE
bash-5.0# ./run.sh
[05:08:02] INFO: Starting CEC client scan...
autodetect FAILED
bash-5.0#@agners help me clarify one thing: what is the reason that both the OS and the cec-addon has libCEC?
I was investigating the cec-addon, not the base OS. I thought that the OS just need to pass the devices files (/dev/cec0, /dev/vchiq, etc..) to the docker image and everything should be handled inside docker after that. My understanding was that only the kernel modules required at OS level to populate the /dev/ system with the needed device files. libCEC is supposed to contain also the kernel modules?
agners
commented
3 years ago what is the reason that both the OS and the cec-addon has libCEC?
The OS itself comes without any CEC library. However the Home Assistant Core container ships with one (see link above). Since the add-on and core are in separate container, they both need to bring the library themselfs.
My understanding was that only the kernel modules required at OS level to populate the /dev/ system with the needed device files. libCEC is supposed to contain also the kernel modules?
In upstream Linux CEC support requires a kernel driver which exposes /dev/cecX. That driver seem to be available and enabled in ODROID-N2, since there is /dev/cec0. From there on, user space can use /dev/cec0 in a standardized way to use CEC.
Unfortunately, there are drivers/hardware which use non-"standard"/upstream way to do CEC. From the looks it seems that Raspberry Pi (used to?) have its own way of doing CEC. I've not looked in how that exactly works, but it could involve all sorts of hackery.
samueltardieu
commented
3 years ago The problem still exists in HomeAssistant 2021.7.4 on Odroid N2+. Running echo scan | cec-client -s -d 1 from within the HomeAssistant container yields:
opening a connection to the CEC adapter...
requesting CEC bus information ...
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
currently active source: unknown (-1)with the following repeated error all along the process:
ERROR: [ 27693] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64Note that the errno is 64 (ENONET) while @boszme seemed to have an errno of 22 (EINVAL) back in June, but I'm using cec-client 6.0.2 from the base image while they were using an older 4.0.3 from the addon.
strace confirms the errno:
ioctl(3, CEC_TRANSMIT, 0xffffc80520d0) = -1 ENONET (No error information)@samueltardieu which adapters were enabled in your environment? when I tried it, I got errno 22 when I disabled the RPI adapter (needed to re-compile the cec-addon docker image without RPI cmake flag). In that case I believe it tried to you use the Linux adapter which gave the errno 22 (but I'm not confirmed), but I'm still not sure which adapter is supposed to work on the Odroid N2+.
cec-client -l
libCEC version: 4.0.3, git revision: libcec-4.0.3, compiled on Sun Jun 20 18:15:35 UTC 2021 by root@localhost on Linux 5.10.25-linuxkit (aarch64), features: P8_USB, DRM, P8_detect, Exynos, Linux, AOCEC@boszme The base image no longer includes anything but the kernel-supported adapters since 2021.7.0. Moreover, strace shows that /dev/cec0 is indeed used by cec-client.
Btw:
# cec-client -l
libCEC version: 6.0.2, git revision: libcec-6.0.2, compiled on 2021-06-17 11:49:16 by root@db06922c0afe on Linux 5.8.0-1033-azure (aarch64), features: P8_USB, DRM, P8_detect, Linux
Found devices: 1
device: 1
com port: Linux
vendor id: 0000
product id: 0000
firmware version: 0
type: Linux@samueltardieu how did you run cec-client: have you enabled direct SSH and invoked from the base OS ?
samueltardieu
commented
3 years ago Yes I did exactly that.
pvizeli
commented
2 years ago I need only update the add-on to work with new hw layer + libcec version. We only support the Linux standard CEC drivers and also rpi added support for the standard kernel CEC protocol. However libcec ist stale and current there is no better library around for python
andybjackson
commented
2 years ago So have we given up, or is there something I can do to get HDMI CEC working on my Home Assistant Blue?
agners
commented
2 years ago From the OS side, update 6.3 includes some additional drivers which I am pretty sure are required forHDMI CEC. I haven't tested it though. So testing with HAOS 6.3 or newer is required.
andybjackson
commented
2 years ago Afraid HAOS 6.3 hasn't resolved the issue for me. CEC Scanner on my Home Assistant Blue still reports:
[09:00:50] INFO: Starting CEC client scan...
* failed to open vchiq instanceMy efforts with symlinking & group membership per the CEC notes yielded nought.
boszme
commented
2 years ago @andybjackson There is some misunderstanding here. The CEC Scanner addon is built from a docker image which contains a libcec implementation which is compiled with the RPI detection too. However this is not suitable for all the various hardware since the RPI adapter always tries to query the /dev/vchiq which only exists on RPI based hw. (https://github.com/home-assistant/operating-system/issues/1216#issuecomment-862558380)
Since my "research" above the base OS got some new updates however the CEC Scanner addon got none. It is expected to get the "* failed to open vchiq instance" error on non-RPI based boards until the CEC Scanner addon is not updated with a libcec version which doesn't have this "bug".
Also the libcec project got stalled so probably this needs some custom patch (or different CEC Scanner addons based on the hardware). I have not tested it but this should effect generic x86 boards as well (not just Odroid) until the RPI detection is compiled in or it is not fixed.
pvizeli
commented
2 years ago I have updated the add-on. Look it now better?
oramirite
commented
2 years ago I also updated my CEC Scanner addon. Now, instead of having a segfault after scanning the first CEC device... it simply says "autodetect failed"... and exists before even trying 😛
So yeah... far from fixed. This is on a Raspberry Pi 4B using the Argon ONE M.2 case (but I should still be seeing the CEC signals).
I've been having problems getting the CEC addon to work with both a RPi3 and RPi4 all year. I've lost track of weather or not this is even a supported feature anymore...
samueltardieu
commented
2 years ago Not OP, but with your newest version on Odroid-N2+ I get:
[18:00:27] INFO: Starting CEC client scan...
opening a connection to the CEC adapter...
ERROR: [ 6] CLinuxCECAdapterCommunication::Open - ioctl CEC_S_MODE failed - errno=16
ERROR: [ 6] could not open a connection (try 1)
ERROR: [ 1006] CLinuxCECAdapterCommunication::Open - ioctl CEC_S_MODE failed - errno=16
ERROR: [ 1006] could not open a connection (try 2)
ERROR: [ 2006] CLinuxCECAdapterCommunication::Open - ioctl CEC_S_MODE failed - errno=16
ERROR: [ 2007] could not open a connection (try 3)Thank you. Progress in that I now seem to get further on my Home Assistant Blue ODroid N2+. Now just have to work out what the messages and the errors mean.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[17:05:24] INFO: Starting CEC client scan...
opening a connection to the CEC adapter...
requesting CEC bus information ...
ERROR: [ 110530] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
ERROR: [ 110530] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
ERROR: [ 110530] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
ERROR: [ 110530] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
CEC bus information
===================
device #1: Recorder 1
address: 2.0.0.0
active source: no
vendor: Pulse Eight
osd string: CECTester
CEC version: 1.4
power status: on
language: eng
currently active source: unknown (-1)
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.Still not working in OS 7.0 & 2021.12.2
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[11:43:46] INFO: Starting CEC client scan...
opening a connection to the CEC adapter...
requesting CEC bus information ...
ERROR: [ 110439] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
ERROR: [ 110439] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
ERROR: [ 110439] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
CEC bus information
===================
device #1: Recorder 1
address: 2.0.0.0
active source: no
vendor: Pulse Eight
osd string: CECTester
CEC version: 1.4
power status: on
language: eng
currently active source: unknown (-1)
ERROR: [ 110439] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.Started to investigate into this issue a bit more.
One thing which is interesting is that Linux 5.10 seems to expose two CEC controllers:
# ls -la /dev/cec*
crw-rw---- 1 root video 250, 0 Jan 13 12:15 /dev/cec0
crw-rw---- 1 root video 250, 1 Jan 13 12:15 /dev/cec1
# find /sys -name "cec*"
/sys/devices/platform/soc/ff600000.bus/ff600000.hdmi-tx/cec0
/sys/devices/platform/soc/ff800000.bus/ff800280.cec/cec1
.../dev/cec0 seems to be provided by the Synopsis HDMI IP (through driver CONFIG_DRM_DW_HDMI_CEC), and the other, /dev/cec1 seems to be a Amlogic specific device (compiled as a module ao_cec_g12a, through driver CONFIG_CEC_MESON_G12A_AO). Btw, there seems to be even a third IP but it seems to be disabled in the ODROID-N2 device tree, so I assume its not meant to be used. The driver CONFIG_CEC_MESON_AO is available as ao_cec module though.
Since Pascal updated the CEC Scanner addon in https://github.com/home-assistant/addons/pull/2240 it comes with the "vanilla" libcec 6.0.2 (at this point still the latest release).
Starting the add-on manually allows to run cec-client with all output enabled.
# docker run -it --rm --privileged --entrypoint /bin/bash homeassistant/aarch64-addon-cec_scan:3.0
bash-5.1# cec-client -sHowever, for me this did not really work well. It seems that messages get sent, but time out all the time (see dmesg)
Unfortunately, there is no way to tell cec-client to use /dev/cec1, it defaults to /dev/cec0, always. I worked around that limitation by creating the device file for the second instance with the name/dev/cec0`:
rm /dev/cec0
mknod /dev/cec0 c 250 1I do get errors from the cec-meson_g12a_ao_cec driver this time, but other than that, the behavior is pretty much the same as above :cry:
[ 114.909180] cec-meson_g12a_ao_cec: message ff 84 24 00 06 timed out
[ 117.213165] cec-meson_g12a_ao_cec: message ff 87 00 15 82 timed out
[ 119.517159] cec-meson_g12a_ao_cec: message f0 timed out
[ 121.821158] cec-meson_g12a_ao_cec: message f0 timed out
[ 124.125140] cec-meson_g12a_ao_cec: message f0 timed out
[ 126.429135] cec-meson_g12a_ao_cec: message f0 timed out
[ 128.733132] cec-meson_g12a_ao_cec: message 11 timed out
[ 131.037129] cec-meson_g12a_ao_cec: message 11 timed out
[ 133.341151] cec-meson_g12a_ao_cec: message 11 timed out
[ 135.644925] cec-meson_g12a_ao_cec: message 11 timed out
[ 137.948725] cec-meson_g12a_ao_cec: message 22 timed out
[ 140.252534] cec-meson_g12a_ao_cec: message 22 timed out
[ 142.556341] cec-meson_g12a_ao_cec: message 99 timed out
[ 144.860180] cec-meson_g12a_ao_cec: message 99 timed outI am a bit out of ideas here. I wonder if HDMI CEC every worked on upstream Linux on this platform. Is anyone aware if it works with Armbian/LibreELEC or similar distributions?
agners
commented
2 years ago It seems that LIbreELEC doesn't support ODROID-N2+ (anymore). However, CoreELEC 19.4-Matrix_rc1 does, but they seem to use the downstream 4.9.113 kernel :spider_web:
It seems that this old kernel has a widely different CEC stack using the input subsystem to expose the device. CoreELEC does use libCEC 6.0.2. So from that exercise I know that my setup does support HDMI CEC and that HAOS should be using the CONFIG_CEC_MESON_G12A_AO driver (or /dev/cec1).
oramirite
commented
2 years ago Thank you Stefan for looking into this so deeply.
I just want to mention that a clue of versions of HA ago, I was able to manually run the CEC scanner container in privileged mode and correctly scan for devices. Simply changing to privileged and running the same command worked. I was never able to get the CEC integration to work though.
On Thu, Jan 13, 2022, 8:01 AM Stefan Agner @.***> wrote:
It seems that LIbreELEC doesn't support ODROID-N2+ (anymore). However, CoreELEC 19.4-Matrix_rc1 does, but they seem to use the downstream 4.9.113 kernel 🕸️
CoreELEC:~ # cec-client -s
opening a connection to the CEC adapter...
DEBUG: [ 14] Broadcast (F): osd name set to 'Broadcast'
NOTICE: [ 14] connection opened
DEBUG: [ 14] << Broadcast (F) -> TV (0): POLL
TRAFFIC: [ 14] << f0
DEBUG: [ 14] processor thread started
DEBUG: [ 43] >> POLL sent
DEBUG: [ 43] TV (0): device status changed into 'present'
DEBUG: [ 43] << requesting vendor ID of 'TV' (0)
TRAFFIC: [ 43] << f0:8c
TRAFFIC: [ 247] >> 0f:87:00:e0:91
CoreELEC:~ # dmesg | grep cec
[ @.*** cectx ff80023c.aocec: cec driver date:2020/03/16:reduece no msg in sleep time
[ @.*** cectx ff80023c.aocec: compatible:amlogic, aocec-g12a
[ @.*** cectx ff80023c.aocec: cecb_ver:0x1
[ @.*** cectx ff80023c.aocec: line_reg:0x1
[ @.*** cectx ff80023c.aocec: line_bit:0x3
[ @.*** cectx ff80023c.aocec: ee_to_ao:0x1
[ @.*** input: cec_input as /devices/virtual/input/input0
[ @.*** cectx ff80023c.aocec: not find 'port_num'
[ @.*** cectx ff80023c.aocec: using cec:1
[ @.*** cectx ff80023c.aocec: no hdmirx regs
[ @.*** cectx ff80023c.aocec: no hhi regs
[ @.*** cectx ff80023c.aocec: not find 'arc_port_mask'
[ @.*** cectx ff80023c.aocec: not find 'output'
[ @.*** cectx ff80023c.aocec: wakeup_reason:0x0
[ @.*** cectx ff80023c.aocec: cev val1: 0x0;val2: 0x0
[ @.*** cectx ff80023c.aocec: aml_cec_probe success end
[ @.*** cectx ff80023c.aocec: bad iniator with self 0x0
It seems that this old kernel has a widely different CEC stack using the input subsystem to expose the device. CoreELEC does use libCEC 6.0.2. So from that exercise I know that my setup does support HDMI CEC and that HAOS should be using the CONFIG_CEC_MESON_G12A_AO driver (or /dev/cec1).
— Reply to this email directly, view it on GitHub https://github.com/home-assistant/operating-system/issues/1216#issuecomment-1012115557, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUWDRS7LTKEHIYGKMZXRY3UV3ELHANCNFSM4XGWXENQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
agners
commented
2 years ago @oramirite from what I see that was on Raspberry Pi 3 correct? This issue is really about ODROID-N2. While errors could look similar, its likely a different root cause as the two boards use different kernel versions and drivers. If that is indeed still a problem and you'd still like to use HDMI CEC on Raspberry Pi, then we should open a separate issue for that.
oramirite
commented
2 years ago Youre right - will do
On Thu, Jan 13, 2022, 8:31 AM Stefan Agner @.***> wrote:
@oramirite https://github.com/oramirite from what I see that was on Raspberry Pi 3 correct? This issue is really about ODROID-N2. While errors could look similar, its likely a different root cause as the two boards use different kernel versions and drivers. If that is indeed still a problem and you'd still like to use HDMI CEC on Raspberry Pi, then we should open a separate issue for that.
— Reply to this email directly, view it on GitHub https://github.com/home-assistant/operating-system/issues/1216#issuecomment-1012139422, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUWDRSSAK37XE6U4YQZC53UV3H45ANCNFSM4XGWXENQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
agners
commented
2 years ago Disabling the DW HDMI CEC driver in #1216 does help to make /dev/cec0 to be the correct device, however, at least in my setup HDMI CEC still seems not to work :cry: .
andybjackson
commented
2 years ago Thanks @agners & @oramirite. I have tried both the Odroid & the Pi and get different errors with ultimately the same outcome. Makes me wonder how the 7 reporting users of this feature got it to work. Look forward to testing the changed code and will update ASAP.
rigrig
commented
2 years ago Makes me wonder how the 7 reporting users of this feature got it to work.
As (I think) one of those data points: I didn't. I installed the addon & integration a while ago on my odroid-n2+, noticed they didn't work, found this issue, and simply haven't removed them yet (hoping for a fix).
agners
commented
2 years ago I got a hint on the mailing list that Arch Linux ARM with Linux 5.15.13 works. It turns out that Arch Linux compiles some drivers as a module, which seems to change behavior such that it works :man_shrugging:
I'll prepare a PR to get this fixed.
agners
commented
2 years ago Btw, it seem that there is a more "upstream" Linux friendly tool called cec-ctl which is part of the v4l-utils package in Alpine Linux. We should consider using it instead of libcec.
agners
commented
2 years ago HDMI CEC should now be functional on ODROID-N2(+) with HAOS 7.2 (currently in beta channel).
rigrig
commented
2 years ago I installed the beta (and reinstalled the addon), but both the addon and the integration are still broken for me :-(
| version | core-2021.12.9 |
|---|---|
| installation_type | Home Assistant OS |
| dev | false |
| hassio | true |
| docker | true |
| user | root |
| virtualenv | false |
| python_version | 3.9.7 |
| os_name | Linux |
| os_version | 5.10.91 |
| arch | aarch64 |
| timezone | Europe/Amsterdam |
agners
commented
2 years ago Just double checked here, works fine with HAOS 7.2 and CEC Scanner 3.0.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[23:30:34] INFO: Starting CEC client scan...
opening a connection to the CEC adapter...
requesting CEC bus information ...
CEC bus information
===================
device #0: TV
address: 0.0.0.0
active source: no
vendor: LG
osd string: TV
CEC version: 1.3a
power status: standby
language: eng
...Errno 16 means "Device or resource busy", it sounds as if something else is using the device. Do you maybe have a CEC configuration active in HAOS? Any other Add-on which might be using the CEC device?
rigrig
commented
2 years ago Do you maybe have a CEC configuration active in HAOS?
Yes, that was it, thanks! I didn't realise mixing the addon and the integration would cause problems.
agners
commented
2 years ago I didn't realise mixing the addon and the integration would cause problems.
I'd say, it didn't cause problems: The system prevented the second user from interfering, by returning error 16. libcec should really print a nicer message here :)
ERROR: [ 7] CLinuxCECAdapterCommunication::Open - ioctl CEC_S_MODE failed - errno=16
ERROR: [ 7] could not open a connection (try 1)But yeah, I know what you mean, it is not obvious that you can't use the two of them at the same time.
Hardware Environment
Home Assistant OS release:
After starting 'CEC Scanner' add-on:
Journal logs:
Kernel logs:
Kernel logs
``` [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.9.16 (builder@3e21b14cdb2d) (aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot -ge648285f) 9.3.0, GNU ld (GNU Binutils) 2.34) #1 SMP PREEMPT Fri Jan 1 15:05:13 UTC 2021 [ 0.000000] Machine model: Hardkernel ODROID-N2Plus [ 0.000000] efi: UEFI not found. [ 0.000000] Reserved memory: created CMA memory pool at 0x00000000e0c00000, size 256 MiB [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] NUMA: No NUMA configuration found [ 0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000000f4e5afff] [ 0.000000] NUMA: NODE_DATA [mem 0xf465e100-0xf465ffff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000003fffffff] [ 0.000000] DMA32 [mem 0x0000000040000000-0x00000000f4e5afff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000004ffffff] [ 0.000000] node 0: [mem 0x0000000005300000-0x00000000f4e5afff] [ 0.000000] Zeroed struct page in unavailable ranges: 421 pages [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000f4e5afff] [ 0.000000] On node 0 totalpages: 1002331 [ 0.000000] DMA zone: 4096 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 261376 pages, LIFO batch:63 [ 0.000000] DMA32 zone: 11578 pages used for memmap [ 0.000000] DMA32 zone: 740955 pages, LIFO batch:63 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci: PSCIv1.0 detected in firmware. [ 0.000000] psci: Using standard PSCI v0.2 function IDs [ 0.000000] psci: MIGRATE_INFO_TYPE not supported. [ 0.000000] psci: SMC Calling Convention v1.1 [ 0.000000] percpu: Embedded 23 pages/cpu s53912 r8192 d32104 u94208 [ 0.000000] pcpu-alloc: s53912 r8192 d32104 u94208 alloc=23*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [ 0.000000] Detected VIPT I-cache on CPU0 [ 0.000000] CPU features: detected: ARM erratum 845719 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 986657 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: zram.enabled=1 zram.num_devices=3 apparmor=1 security=apparmor systemd.machine_id=b31decd78a21418f8e682af4fabe190a cgroup_enable=memory fsck.repair=yes root=PARTUUID=48617373-08 rootfstype=squashfs ro rootwait rauc.slot=B console=tty0 console=ttyAML0,115200n8 [ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) [ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] software IO TLB: mapped [mem 0x3bfff000-0x3ffff000] (64MB) [ 0.000000] Memory: 3578968K/4009324K available (13440K kernel code, 990K rwdata, 4160K rodata, 2560K init, 463K bss, 168212K reserved, 262144K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 [ 0.000000] rcu: Preemptible hierarchical RCU implementation. [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=6. [ 0.000000] Trampoline variant of Tasks RCU enabled. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6 [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] irq_meson_gpio: 100 to 8 gpio interrupt mux initialized [ 0.000000] random: get_random_bytes called from start_kernel+0x32c/0x4ec with crng_init=0 [ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [ 0.000004] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [ 0.000170] Console: colour dummy device 80x25 [ 0.000523] printk: console [tty0] enabled [ 0.000609] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000) [ 0.000629] pid_max: default: 32768 minimum: 301 [ 0.000712] LSM: Security Framework initializing [ 0.000795] AppArmor: AppArmor initialized [ 0.000850] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) [ 0.000878] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) [ 0.002581] rcu: Hierarchical SRCU implementation. [ 0.004318] EFI services will not be available. [ 0.004726] smp: Bringing up secondary CPUs ... [ 0.005355] Detected VIPT I-cache on CPU1 [ 0.005406] CPU1: Booted secondary processor 0x0000000001 [0x410fd034] [ 0.006551] CPU features: detected: ARM erratum 858921 [ 0.006559] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware [ 0.006567] Detected VIPT I-cache on CPU2 [ 0.006590] arch_timer: Enabling local workaround for ARM erratum 858921 [ 0.006605] arch_timer: CPU2: Trapping CNTVCT access [ 0.006612] CPU2: Booted secondary processor 0x0000000100 [0x410fd092] [ 0.007226] Detected VIPT I-cache on CPU3 [ 0.007242] arch_timer: Enabling local workaround for ARM erratum 858921 [ 0.007248] arch_timer: CPU3: Trapping CNTVCT access [ 0.007253] CPU3: Booted secondary processor 0x0000000101 [0x410fd092] [ 0.007822] Detected VIPT I-cache on CPU4 [ 0.007837] arch_timer: Enabling local workaround for ARM erratum 858921 [ 0.007844] arch_timer: CPU4: Trapping CNTVCT access [ 0.007849] CPU4: Booted secondary processor 0x0000000102 [0x410fd092] [ 0.008478] Detected VIPT I-cache on CPU5 [ 0.008493] arch_timer: Enabling local workaround for ARM erratum 858921 [ 0.008499] arch_timer: CPU5: Trapping CNTVCT access [ 0.008505] CPU5: Booted secondary processor 0x0000000103 [0x410fd092] [ 0.008575] smp: Brought up 1 node, 6 CPUs [ 0.008722] SMP: Total of 6 processors activated. [ 0.008735] CPU features: detected: 32-bit EL0 Support [ 0.008746] CPU features: detected: CRC32 instructions [ 0.008757] CPU features: detected: 32-bit EL1 Support [ 0.018991] CPU: All CPU(s) started at EL2 [ 0.019055] alternatives: patching kernel code [ 0.020797] devtmpfs: initialized [ 0.026440] Registered cp15_barrier emulation handler [ 0.026464] Registered setend emulation handler [ 0.026474] KASLR disabled due to lack of seed [ 0.026716] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.026738] futex hash table entries: 2048 (order: 5, 131072 bytes, linear) [ 0.030827] pinctrl core: initialized pinctrl subsystem [ 0.031152] DMI not present or invalid. [ 0.031483] NET: Registered protocol family 16 [ 0.032834] DMA: preallocated 512 KiB GFP_KERNEL pool for atomic allocations [ 0.033015] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [ 0.033252] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations [ 0.033270] audit: initializing netlink subsys (disabled) [ 0.033366] audit: type=2000 audit(0.032:1): state=initialized audit_enabled=0 res=1 [ 0.033628] thermal_sys: Registered thermal governor 'step_wise' [ 0.033851] cpuidle: using governor menu [ 0.034146] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. [ 0.034239] ASID allocator initialised with 65536 entries [ 0.035069] Serial: AMBA PL011 UART driver [ 0.061050] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages [ 0.061068] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages [ 0.061078] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages [ 0.061086] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages [ 0.061799] cryptd: max_cpu_qlen set to 1000 [ 0.063362] ACPI: Interpreter disabled. [ 0.064042] 5V: supplied by 12V [ 0.064689] VDDAO_3V3: supplied by 12V [ 0.064968] iommu: Default domain type: Translated [ 0.065077] vgaarb: loaded [ 0.065281] SCSI subsystem initialized [ 0.065379] libata version 3.00 loaded. [ 0.065505] usbcore: registered new interface driver usbfs [ 0.065535] usbcore: registered new interface driver hub [ 0.065583] usbcore: registered new device driver usb [ 0.065793] mc: Linux media interface: v0.10 [ 0.065812] videodev: Linux video capture interface: v2.00 [ 0.065836] pps_core: LinuxPPS API ver. 1 registered [ 0.065843] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo GiomettiDescription of problem:
No HDMI-CEC functions are working. I have tried the CEC Scanner add-on and the HDMI-CEC integration.
This issue is reported to the add-on repository (https://github.com/home-assistant/addons/issues/1771), but maybe it it related to the OS. To summarize: After starting the CEC Scanner add-on, it immediately stops and has the following in the log file:
I can also see this in the Home Assistant log when I've added the
hdmi_cecintegration toconfiguration.yaml, and then calling thehdmi_cec.power_onservice:I have:
Welcome to Home Assistant(\n) Homeassistant login: _)