You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My Raspberry Pi is connected to one of the HDMI inputs (i tried HDMI6 and HDMI8) of my Pioneer AV receiver, which is connected to an LG television. When the receiver is in standby or when it is both ON and has the Pi's input selected, I am able to issue different CEC commands with both cec-client and cec-ctl, and I get OK responses. Topology of the HDMI net is returned properly, with receiver being 1.0.0.0 and Pi - 1.6.0.0 or 1.8.0.0, depending on the input I use. But then, when I switch the input, everything goes bad. Most commands through cec-client end up in errors 64, cec-client just doesn't do much.
When I run cec-client to monitor the traffic, this is what it looks like. I think up until the last 3 lines it is normal traffic, and then CEC_EVENT_STATE_CHANGE pops up with "phys_addr=ffff" and I think this is where things go bad. Below is the output of cec-ctl that shows the physical address as f.f.f.f.
I remember cec-client working just fine on the same hardware, but with much older versions of both OS (I think it was current, like, 3-4 years ago). Maybe it wasn't handling the CEC_EVENT_STATE_CHANGE (who is picking it up, anyway?)
I really need this to work exactly when the receiver is switched away from Pi's port (to switch it back when I need to). Please advise on what to do. I did try different ports and different cables, as well as simplifying the topology by removing devices sitting in other HDMI inputs, with no avail. The Pi needs to be in one of the receiver's inputs. But I think the physical connections are all good, just that the stack is handling this event in a way that is not helpful.
A couple of environment-related outputs are also below. config.txt is more or less original, the only thing added there is hdmi_ignore_cec_init=1
so that the TV doesn't light up on boot.
TRAFFIC: [ 35956] >> 5f:a0:00:e0:36:d8
DEBUG: [ 35956] >> Audio (5) -> Broadcast (F): vendor command with id (A0)
DEBUG: [ 36046] CLinuxCECAdapterCommunication::Process - ioctl CEC_RECEIVE - rx_status=01 len=3 addr=01 opcode=89
TRAFFIC: [ 36046] >> 01:89:0b
DEBUG: [ 36046] Recorder 1 (1): power status changed from 'on' to 'in transition from standby to on'
DEBUG: [ 36046] << Recorder 1 (1) -> TV (0): in transition from standby to on
TRAFFIC: [ 36046] << 10:90:02
DEBUG: [ 36046] >> TV (0) -> Recorder 1 (1): vendor command (89)
DEBUG: [ 36133] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT - tx_status=01 len=3 addr=10 opcode=90
DEBUG: [ 36133] Recorder 1 (1): power status changed from 'in transition from standby to on' to 'on'
DEBUG: [ 41394] CLinuxCECAdapterCommunication::Process - CEC_DQEVENT - CEC_EVENT_STATE_CHANGE - log_addr_mask=0000 phys_addr=ffff
DEBUG: [ 43407] changing physical address to FFFF
DEBUG: [ 43407] SetDevicePhysicalAddress - not setting invalid physical address ffff
yuri@raspberrypi:~ $ echo "scan" | cec-client -s -d 2
opening a connection to the CEC adapter...
WARNING: [ 83] CLinuxCECAdapterCommunication::Open - physical address is invalid
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)
yuri@raspberrypi:~ $ cec-ctl
Driver Info:
Driver Name : vc4_hdmi
Adapter Name : vc4-hdmi
Capabilities : 0x0000011e
Logical Addresses
Transmit
Passthrough
Remote Control Support
Connector Info
Driver version : 6.6.51
Available Logical Addresses: 1
DRM Connector Info : card 0, connector 32
Physical Address : f.f.f.f
Logical Address Mask : 0x0000
CEC Version : 2.0
OSD Name : ''
Logical Addresses : 0 (Allow Fallback to Unregistered)
yuri@raspberrypi:~ $
yuri@raspberrypi:~ $ vcgencmd version
Aug 30 2024 19:19:11
Copyright (c) 2012 Broadcom
version 2808975b80149bbfe86844655fe45c7de66fc078 (clean) (release) (start)
yuri@raspberrypi:~ $ uname -a
Linux raspberrypi 6.6.51+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.51-1+rpt3 (2024-10-08) armv7l GNU/Linux
The text was updated successfully, but these errors were encountered:
My Raspberry Pi is connected to one of the HDMI inputs (i tried HDMI6 and HDMI8) of my Pioneer AV receiver, which is connected to an LG television. When the receiver is in standby or when it is both ON and has the Pi's input selected, I am able to issue different CEC commands with both cec-client and cec-ctl, and I get OK responses. Topology of the HDMI net is returned properly, with receiver being 1.0.0.0 and Pi - 1.6.0.0 or 1.8.0.0, depending on the input I use. But then, when I switch the input, everything goes bad. Most commands through cec-client end up in errors 64, cec-client just doesn't do much.
When I run cec-client to monitor the traffic, this is what it looks like. I think up until the last 3 lines it is normal traffic, and then CEC_EVENT_STATE_CHANGE pops up with "phys_addr=ffff" and I think this is where things go bad. Below is the output of cec-ctl that shows the physical address as f.f.f.f.
I remember cec-client working just fine on the same hardware, but with much older versions of both OS (I think it was current, like, 3-4 years ago). Maybe it wasn't handling the CEC_EVENT_STATE_CHANGE (who is picking it up, anyway?)
I really need this to work exactly when the receiver is switched away from Pi's port (to switch it back when I need to). Please advise on what to do. I did try different ports and different cables, as well as simplifying the topology by removing devices sitting in other HDMI inputs, with no avail. The Pi needs to be in one of the receiver's inputs. But I think the physical connections are all good, just that the stack is handling this event in a way that is not helpful.
A couple of environment-related outputs are also below. config.txt is more or less original, the only thing added there is
hdmi_ignore_cec_init=1
so that the TV doesn't light up on boot.
The text was updated successfully, but these errors were encountered: