Problems using cec-client on 64-bit installation on RPi4

[graysky2]

Similar to #540, I get failures on a 64-bit install of Arch ARM on RPi4. Latest kernel from rpi-5.10.y branch/firmware.

% echo "scan" | cec-client -s -d 1
opening a connection to the CEC adapter...
ERROR:   [              11]   Open - vc_cec could not be initialised
ERROR:   [              11]   could not open a connection (try 1)
ERROR:   [            1011]   Open - vc_cec could not be initialised
ERROR:   [            1011]   could not open a connection (try 2)
ERROR:   [            2012]   Open - vc_cec could not be initialised
ERROR:   [            2012]   could not open a connection (try 3)
ERROR:   [            3012]   Open - vc_cec could not be initialised
ERROR:   [            3012]   could not open a connection (try 4)
ERROR:   [            4013]   Open - vc_cec could not be initialised
ERROR:   [            4013]   could not open a connection (try 5)
ERROR:   [            5013]   Open - vc_cec could not be initialised
ERROR:   [            5013]   could not open a connection (try 6)
ERROR:   [            6014]   Open - vc_cec could not be initialised
ERROR:   [            6014]   could not open a connection (try 7)
ERROR:   [            7014]   Open - vc_cec could not be initialised
ERROR:   [            7014]   could not open a connection (try 8)
ERROR:   [            8015]   Open - vc_cec could not be initialised
ERROR:   [            8015]   could not open a connection (try 9)
ERROR:   [            9015]   Open - vc_cec could not be initialised
ERROR:   [            9015]   could not open a connection (try 10)
unable to open the device on port RPI
ERROR:   [           10016]   could not start CEC communications

This is in contrast to the 32-bit version of the Distro, armv7h, again with the latest kernel from rpi-5.10.y:

% echo 'scan' | cec-client -s -d 1
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)

Note that on aarch64, I can add hdmi_force_hotplug=1 to /boot/config.txt and I can get cec-client to connect but doing so ends in a core dump after a significant delay:

% echo 'scan' | cec-client -s -d 1
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)
[1]    288 done                              echo 'scan' | 
       289 segmentation fault (core dumped)  cec-client -s -d 1

Here is the info on the core dump.

% coredumpctl dump --output=dump
           PID: 346 (cec-client)
           UID: 1000 (facade)
           GID: 985 (users)
        Signal: 11 (SEGV)
     Timestamp: Sun 2020-11-29 07:31:32 EST (50s ago)
  Command Line: cec-client -s -d 1
    Executable: /usr/bin/cec-client-6.0.2
 Control Group: /user.slice/user-1000.slice/session-3.scope
          Unit: session-3.scope
         Slice: user-1000.slice
       Session: 3
     Owner UID: 1000 (facade)
       Boot ID: f037c05e68814ecf8112246aa79b4c18
    Machine ID: ef6412950137417eb861dad2ace857f9
      Hostname: workbench
       Storage: /var/lib/systemd/coredump/core.cec-client.1000.f037c05e68814ecf8112246aa79b4c18.346.1606653092000000.zst
       Message: Process 346 (cec-client) of user 1000 dumped core.
                
                Stack trace of thread 353:
                #0  0x0000007f86eb1e48 _ZN3CEC26CRPiCECAdapterMessageQueue15MessageReceivedENS_10cec_opcodeENS_19cec_logical_addressES2_j (libcec.so.6 + 0x58e48)
                #1  0x0000007f86c45c04 cecservice_notify_func (libbcm_host.so + 0x10c04)
                #2  0x0000007f86c82760 vcos_thread_entry (libvcos.so + 0x3760)
                #3  0x0000007f8742af44 start_thread (libpthread.so.0 + 0x7f44)
                #4  0x0000007f86ffe95c thread_start (libc.so.6 + 0xd395c)
                
                Stack trace of thread 351:
                #0  0x0000007f87434430 do_futex_wait.constprop.0 (libpthread.so.0 + 0x11430)
                #1  0x0000007f8743455c __new_sem_wait_slow.constprop.0 (libpthread.so.0 + 0x1155c)
                #2  0x0000007f86c49ff0 dispmanx_notify_func (libbcm_host.so + 0x14ff0)
                #3  0x0000007f86c82760 vcos_thread_entry (libvcos.so + 0x3760)
                #4  0x0000007f8742af44 start_thread (libpthread.so.0 + 0x7f44)
                #5  0x0000007f86ffe95c thread_start (libc.so.6 + 0xd395c)
                
                Stack trace of thread 350:
                #0  0x0000007f86ff6b50 ioctl (libc.so.6 + 0xcbb50)
                #1  0x0000007f86c685f0 completion_thread (libvchiq_arm.so + 0x25f0)
                #2  0x0000007f86c82760 vcos_thread_entry (libvcos.so + 0x3760)
                #3  0x0000007f8742af44 start_thread (libpthread.so.0 + 0x7f44)
                #4  0x0000007f86ffe95c thread_start (libc.so.6 + 0xd395c)
                
                Stack trace of thread 352:
                #0  0x0000007f87434430 do_futex_wait.constprop.0 (libpthread.so.0 + 0x11430)
                #1  0x0000007f8743455c __new_sem_wait_slow.constprop.0 (libpthread.so.0 + 0x1155c)
                #2  0x0000007f86c43648 tvservice_notify_func (libbcm_host.so + 0xe648)
                #3  0x0000007f86c82760 vcos_thread_entry (libvcos.so + 0x3760)
                #4  0x0000007f8742af44 start_thread (libpthread.so.0 + 0x7f44)
                #5  0x0000007f86ffe95c thread_start (libc.so.6 + 0xd395c)
                
                Stack trace of thread 346:
                #0  0x0000007f8743174c pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0 + 0xe74c)
                #1  0x0000007f86eb0010 _ZN3CEC27CRPiCECAdapterCommunication24UnregisterLogicalAddressEv (libcec.so.6 + 0x57010)
                #2  0x0000007f86eb02c8 _ZN3CEC27CRPiCECAdapterCommunicationD1Ev (libcec.so.6 + 0x572c8)
                #3  0x0000007f86eb052c _ZN3CEC27CRPiCECAdapterCommunicationD0Ev (libcec.so.6 + 0x5752c)
                #4  0x0000007f86e9e990 _ZN3CEC13CCECProcessor5CloseEv (libcec.so.6 + 0x45990)
                #5  0x000000555c5d2f48 n/a (cec-client-6.0.2 + 0x2f48)
                #6  0x0000007f86f4f538 __libc_start_main (libc.so.6 + 0x24538)
                #7  0x000000555c5d3c98 n/a (cec-client-6.0.2 + 0x3c98)
                #8  0x000000555c5d3c98 n/a (cec-client-6.0.2 + 0x3c98)

I have a 58M coredump I can share if needed.

[posuch]

confirming the beahviour as described

see two screens bellow how the cec presents itself in Kodi - for 32bit arm the firmware version is 1 for 64bit the firmware version is 65535

not sure if this helps , just posting how it looks like ( more like a symptom )

32bit

64bit

[henkv1]

I have the same issue on a 32 bit installation and full kms (vc4-kms-v3d):

echo 'scan' | cec-client -s -d 1
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:        Unknown
osd string:    TV
CEC version:   unknown
power status:  unknown
language:      ???

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)
Segmentation fault (core dumped)

It works fine when I use fake kms (vc4-fkms-v3d) on the same system:

echo 'scan' | cec-client -s -d 1
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:        Samsung
osd string:    TV
CEC version:   1.3a
power status:  on
language:      dut


device #1: Recorder 1
address:       1.0.0.0
active source: yes
vendor:        Pulse Eight
osd string:    CECTester
CEC version:   1.4
power status:  on
language:      eng


currently active source: Recorder 1 (1)

[graysky2]

@henkv1 - Wondering if this is more a function of kernel code rather than Pulse-Eight code given your observation. Would you create a ticket against the kernel and let's see what they say?

[henkv1]

@graysky2 - I created a ticket for this: raspberrypi/linux#4103

[graysky2]

Thanks. I found a solution/work-around in that issue. Please let me know if it's working for you.

[graysky2]

@opdenkamp - It seems the aarch64 was a red herring. The issue could be that when we boot using vc4-kms-v3d driver, cec-client cannot connect but if we boot using vc4-fkms-v3d it does in fact connect.

How can we build it to allow for either of these?

• If I build with -DHAVE_LINUX_API=1 it works with kms.
• If I build with both -DHAVE_LINUX_API=1 and -DHAVE_RPI_API=1 it does NOT work with kms.

[popcornmix]

I've just tried this. I'm on

$ uname -a
Linux domnfs 5.10.11-v7l+ #245 SMP Fri 29 Jan 19:08:00 GMT 2021 armv7l GNU/Linux

which was a kernel build that includes raspberrypi/linux#3999 (I don't think that will have fixed this)

I built master branch of libcec with:

mkdir -p build_both && cd build_both
cmake -DHAVE_LINUX_API=1 -DHAVE_RPI_API=1 -DRPI_INCLUDE_DIR=/opt/vc/include -DRPI_LIB_DIR=/opt/vc/lib .. && \
make -j4
sudo make install && \
sudo ldconfig

pi@pi4:~ $ cec-client -i
libCEC version: 5.0.0, git revision: libcec-4.0.4+62-b7fd475, compiled on 2021-02-01 14:11:59 by pi@domnfs on Linux 5.10.11-v7l+ (armv7l), features: P8_USB, DRM, P8_detect, randr, RPi, Linux

I tested with (each one in turn):

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-fkms-v3d
#dtoverlay=vc4-kms-v3d

each time I ran cec-client and pressed buttons on remote and they logged messages. e.g.

DEBUG:   [           12571]	>> TV (0) -> Recorder 1 (1): user control pressed (44)

with kms:

pi@pi4:~ $ cec-client -l
libCEC version: 5.0.0, git revision: libcec-4.0.4+62-b7fd475, compiled on 2021-02-01 14:11:59 by pi@domnfs on Linux 5.10.11-v7l+ (armv7l), features: P8_USB, DRM, P8_detect, randr, RPi, Linux
ERROR:   [            3601]	error opening serial port '': No such file or directory
ERROR:   [            3601]	could not open a connection (try 1)
ERROR:   [            6438]	error opening serial port '': No such file or directory
ERROR:   [            6438]	could not open a connection (try 2)
ERROR:   [            8328]	error opening serial port '': No such file or directory
ERROR:   [            8328]	could not open a connection (try 3)
ERROR:   [            9588]	error opening serial port '': No such file or directory
ERROR:   [            9588]	could not open a connection (try 4)
Found devices: 3

device:              1
com port:            /dev/cec0
vendor id:           0000
product id:          0000
firmware version:    0
type:                Linux

device:              2
com port:            /dev/cec1
vendor id:           0000
product id:          0000
firmware version:    0
type:                Linux

device:              3
com port:            
vendor id:           0000
product id:          0000
firmware version:    65535

with fkms or none:

pi@pi4:~/projects/libcec $ cec-client -l
libCEC version: 5.0.0, git revision: libcec-4.0.4+62-b7fd475, compiled on 2021-02-01 14:11:59 by pi@domnfs on Linux 5.10.11-v7l+ (armv7l), features: P8_USB, DRM, P8_detect, randr, RPi, Linux
Found devices: 1

device:              1
com port:            RPI
vendor id:           2708
product id:          1001
firmware version:    1
type:                Raspberry Pi

[ioogithub]

I have been trying to get my TV remote working with my Raspberry Pi 4 Model B and the 64 bit OS without success. It works as expected using the 32 bit OS.

Note that on aarch64, I can add hdmi_force_hotplug=1 to /boot/config.txt and I can get cec-client to connect

I tried adding the hdmi_force_hotplug=1 option but it didn't make any difference:

$ cec-client -l
Found devices: NONE

$echo "scan" | cec-client -s d1
..same as above:
"could not open connection"
"could not start CEC commuications"

@opdenkamp - It seems the aarch64 was a red herring. The issue could be that when we boot using vc4-kms-v3d driver, > cec-client cannot connect but if we boot using vc4-fkms-v3d it does in fact connect.

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-fkms-v3d
#dtoverlay=vc4-kms-v3d

Ive tried setting all of these all of these and none of them worked.

Thanks. I found a solution/work-around in that issue. Please let me know if it's working for you.

What solution did you ultimately find? I followed the linked thread but it was a bit over my head.

uname -a
Linux raspberrypi 5.10.17-v8+ #1403 SMP PREEMPT Mon Feb22 11:37 GMT 2021 aarch64 GNU/Linux

All packages are from official repository

LibCEC version: 4.0.5, complied on 2020-05-04 13:29:44 by pbuilder@guillaume.marillat.net on Linux 5.6.0-1-arm64 (aarch64), features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC

[popcornmix]

If using the kms driver (dtoverlay=vc4-kms-v3d) you need libcec to be built with right options.
Try building this lib with:

cmake -DHAVE_LINUX_API=1 -DHAVE_RPI_API=0

[ioogithub]

If using the kms driver (dtoverlay=vc4-kms-v3d)
I am using the fkms which I believe is the default and this doesn't work. Is using the kms driver built with the right options the only way currently to get it working?

I have never build a linux driver before, is there a guide somewhere for doing this?

Do you think this will be fixed eventually?

[graysky2]

@ioogithub - Driver or program... doesn't matter. You just need the build dependencies and you build it. For a recipe, see this.

[popcornmix]

Building instructions are here:
https://github.com/Pulse-Eight/libcec/blob/master/docs/README.linux.md

I don't know if there is anything to fix. This repo contains code that works with 64-bit kms kernel.

If you want a prebuilt library in the distribution of your choice, then you can request that there. e.g.
https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues

[Jibun-no-Kage]

This issue was never closed? Was it resolved? I have a Vizio TV (32in) that CEC and Pi have been working fine with, now I can seeing all kinds of CEC_TRANSMIT errors. Pi 3B+ running 64 bit. But I am not running KMS but FKMS driver. A CEC scan works. Get power state, power off and power on work. But switching from HDMI1 to HDMI2 or back HDMI2 to HDMI1 fails via cec-client. This was working fine before moving to 64 bit and Bullseye recently. I have swapped cables, done a hard reset of the TV, even used a new Pi OS 11 image on a different SD card, but I still can't get cec-client to switch HDMI ports via CEC protocol.

[inspector71]

@opdenkamp - It seems the aarch64 was a red herring. The issue could be that when we boot using vc4-kms-v3d driver, cec-client cannot connect but if we boot using vc4-fkms-v3d it does in fact connect.

How can we build it to allow for either of these?

* If I build with `-DHAVE_LINUX_API=1` it works with kms.

* If I build with both `-DHAVE_LINUX_API=1` and `-DHAVE_RPI_API=1` it does NOT work with kms.

But, does it work with Fakey fKMS ? That is: vc4-fkms-v3d to be specific (and less casual :) )

[graysky2]

#543 (comment)

Also, vc4-fkms-v3d has been deprecated in favor of vc4-kms-v3d as I recall.