Raspberry Pi 5: VC4 HDMI CEC adapter never acquires physical address (f.f.f.f) despite valid EDID

[dkeppens]

Describe the bug

On a Raspberry Pi 5 running Raspberry Pi OS Trixie (64-bit), the VC4 HDMI CEC adapter never acquires a valid physical address.

The system reads the monitor/AVR EDID correctly, HDMI video and audio function normally, and the CEC controller is able to transmit and receive CEC messages. However, the adapter permanently reports a physical address of f.f.f.f, preventing logical address allocation.

As a consequence, applications such as Kodi cannot initialise CEC correctly because the kernel never provides a valid physical address.

This is a fresh installation of Raspberry Pi OS Trixie. No previous Kodi configuration has been migrated.

Hardware
Raspberry Pi 5
Raspberry Pi OS Trixie (64-bit)
Connected through an AV receiver
AVR HDMI output connected to HDMI-A-1
Software

Kernel:

Linux 6.18.34+rpt-rpi-2712

Firmware:

vcgencmd version
2026/05/26
version 086b83e3

EEPROM:

Current bootloader installed.

HDMI operation

HDMI functions normally.

Video works correctly
HDMI audio works correctly
3840×2160@60 is available and selected
DRM reports HDMI-A-1 as connected
HDMI-A-2 is disabled

Example:

/sys/class/drm/card1-HDMI-A-1/status

connected

modetest also reports HDMI-A-1 correctly with the expected modes.

EDID

The EDID is successfully read.

edid-decode /sys/class/drm/card1-HDMI-A-1/edid

The HDMI Vendor Specific Data Block contains:

Source physical address: 2.2.0.0

Therefore the physical address is present in the EDID and is being read successfully.

CEC devices

The kernel CEC device exists:

/dev/cec0

The connected output is associated with connector 35 (HDMI-A-1).

Observed behaviour

Running

cec-ctl -d0 -S

always reports

Physical Address : f.f.f.f
Logical Address : Not Allocated

This remains true indefinitely after boot.

The adapter never acquires a logical address.

CEC communication

The controller is able to transmit CEC messages.

For example,

cec-ctl --playback --monitor

shows repeated transmissions such as

IMAGE_VIEW_ON

The TV also replies correctly, for example:

DEVICE_VENDOR_ID (LG)

Therefore:

transmit works
receive works
the CEC bus is operational

Only the local adapter state never transitions from physical address f.f.f.f.

Kodi

Kodi reports an invalid physical address and therefore cannot initialise libCEC correctly.

However, the same behaviour is observed with Kodi completely stopped.

For example:

fuser /dev/cec0

returns no users of the device, yet cec-ctl still reports the adapter at f.f.f.f.

This appears to rule out Kodi or libCEC as the cause.

Diagnostics performed

Verified:

HDMI video works
HDMI audio works
DRM connector is connected
EDID is successfully read
EDID contains physical address 2.2.0.0
modetest reports the expected connector
cec-ctl can transmit
cec-ctl receives replies from the TV
Kodi is not required to reproduce the issue. Conclusions are the same even without kodi starting up
Fresh Raspberry Pi OS Trixie installation

Despite all of the above, the kernel never assigns a physical address to the local CEC adapter.

Expected behaviour

After parsing the EDID, the VC4 HDMI driver should update the CEC notifier with the physical address extracted from the HDMI Vendor Specific Data Block.

The adapter should report something similar to

Physical Address : 2.2.0.0

followed by logical address allocation.

Actual behaviour

The adapter remains permanently at

Physical Address : f.f.f.f

and no logical address is ever allocated.

The evidence suggests that the HDMI subsystem successfully reads and parses the EDID, but the CEC adapter is never updated with the extracted physical address.

Steps to reproduce the behaviour

Install a fresh Raspberry Pi OS Lite (Trixie 64-bit) on a Raspberry Pi 5.
Update the system (apt update && apt full-upgrade).
Connect the Pi's HDMI0 output to an HDMI AVR (in my case an LG TV via an AVR/repeater; the EDID identifies itself as SII SPRT RPT which is a wireless Harman Kardon 5.1 installation).
Boot the Pi.
Verify that HDMI video works normally.
Run:
cec-ctl -d0 -S
Observe that the CEC adapter reports:
Physical Address: f.f.f.f
Logical Address: Not Allocated

even though:

edid-decode /sys/class/drm/card1-HDMI-A-1/edid

reports

Vendor-Specific Data Block (HDMI)
Source physical address: 2.2.0.0 (in my case, replace by applicable CEC topology)

Device (s)

Raspberry Pi 5

System

root@KeppieMC1:~ # cat /etc/rpi-issue
Raspberry Pi reference 2026-06-18
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, ca8aeed0ae300c2a89f55ce9617d5f96a27e99e5, stage2
root@KeppieMC1:~ # vcgencmd version
2026/05/26 16:01:25
Copyright (c) 2012 Broadcom
version 086b83e3 (release) (embedded)
root@KeppieMC1:~ # uname -a
Linux KeppieMC1 6.18.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.34-1+rpt1 (2026-06-09) aarch64 GNU/Linux
root@KeppieMC1:~ #
Please note that this system does not have a graphical environment installed. In case of kodi, it's started as standalone.

Logs

cec-ctl.txt

cmdline.txt

dmesg.txt

modetest.txt

kodi.log

edid-decode.txt

Additional context

cec-ctl.txt contains output of cec-ctl -d0 -S
cmdline.txt contains output of cat /proc/cmdline
dmesg.txt contains output of dmesg
modetest.txt contains output of modetest -M vc4 -c
kodi.log contains a kodi.log right after reboot and kodi startup as standalone
edid-decode.txt contains output of edid-decode /sys/class/drm/card1-HDMI-A-1/edid

[popcornmix]

Does your system have working hotplug detect?
Does this make a difference?

echo detect | sudo tee /sys/class/drm/card1-HDMI-A-1/status
cec-ctl -d0 -S

Can you try with this removed:

vc4.force_hotplug=0x01 video=HDMI-A-1:3840x2160@60D,margin_left=120,margin_right=120,margin_top=100,margin_bottom=100

I think the forced hotplug detect may cause the driver to skip the hotplug related cec initialisation.

[popcornmix]

(if the command line edit helps, try with just the 'D' removed from 'video=')

[dkeppens]

I tried several reboots.
1- Removing both parameters requested : CEC addresses do indeed get populated correctly.
2- Added back in vc4.force_hotplug=0x01 : Still works. Adapter address is correct
3- Added in video=HDMI-A-1:3840x2160@60,margin_left=120,margin_right=120,margin_top=100,margin_bottom=100 (Note no D to bypass hot plug this time) : Again, still works. No issues at all
4- Added back in the additional D again for a final reboot to make sure : Indeed back to no valid CEC address

So, it is strictly the additional D that causes this. You have my thanks.
If i'm allowed an additional question though, have the recent changes to libCEC made it behave correctly and was adding the forced output parameter supposed to break CEC in this way or is this CEC breakdown still unexpected ? I'm asking because i never experienced this on Bullseye

[popcornmix]

I think there is a flaw in the (generic upstream) hdmi driver code where the presence of the D flag skip the cec init.
I doubt it is related to libcec changes (the libcec project rarely updates).
It's possible an earlier kernel in bullseye behaved differently.
There's been a fair amount of work in kernel drm code to move more code into generic helpers that are shared by multiple platforms, rather than each platform rolling its own. In general this is a good thing but sometimes the final implementation is subtly different.

Let me submit a PR for the suspected cec init issue, and you can test if that allows your cec use with the 'D' option.

[popcornmix]

Looks like 6.19 and later upstream kernel trees have a potentially useful commit in.

If you wait about half an hour you can install a test kernel that may fix this issue (allowing the 'D' option). Run:
sudo rpi-update pulls/7490

(but read the caveats first).