Posts by jc2nd

That's understandable. The technical need is where a working physical configuration yields a device ( /dev/cec0 ) via the Linux (kernel) API for CEC that can be used with cec-ctl to 1) identify as a playback device and 2) activate as the source to begin receiving the remote control messages.

In this situation with the current lack of the option, the cec-client ( using libcec and also directly reflecting the capabilities of Kodi against libcec ) isn't able to identify any devices.

Enabling the option for the build allows libcec to work with the Linux API:

LibreELEC.tv/packages/devel/libcec/package.mk at 12.0.2 · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

libcec/src/libcec/cmake/CheckPlatformSupport.cmake at libcec-4.0.7 · Pulse-Eight/libcec

USB CEC Adapter communication Library http://libcec.pulse-eight.com/ - Pulse-Eight/libcec

github.com

This was outlined in my first post on the forum:

Post

RE: [x86-64] CEC Mapping by libCEC

***Update WITH FIX to the libcec and i915 + DP++->HDMI cable with working cec-ctl behavior saga, posting for posterity:***

[…]

My suspicions were correct. To get libcec to be able to use the i915 ( core i5-7500 ) with the DP -> HDMI with tunneling working as a cec peripheral, you have to enable the Linux API ( for cec ) in the build.

Just throw the CEC_FRAMEWORK_SUPPORT="yes" value into the Generic project options file.

On the build, the Linux API is enabled in the libcec package build, and when…

jc2nd

February 13, 2025 at 12:50 PM

While the paste contents are gone ( due to age ), the details are all there.
1) A physical device for cec is created by the Linux (kernel) CEC API
2) Kodi ( through libcec, built without Linux API support ) can't use it.
3) cec-ctl is able to interact with the CEC devices and receive remote passthrough keycodes ( e.g. cec-ctl --playback; cec-ctl --active-source phys-addr=...; cec-ctl -m )

When the option is set for x86_64 hardware, libcec is able to use the Linux API created device to allow remote passthrough.

When omitting CEC_FRAMEWORK_SUPPORT, the libcec package build doesn't utilize the Linux API. This precludes a whole branch of CEC configurations that do physically work over the Linux API.

When testing a Generic build with CEC_FRAMEWORK_SUPPORT ="yes", libcec successfully built with Linux API support and was able to to register a peripheral that previously was detected ( device created at /dev/cec0 and working with cec-ctl ) but not properly registering in Kodi.

Hardware support aside (specifically the cec pin being wired or DP++->HDMI adapter with CEC over AUX), the kernel drivers could provide a device that otherwise isn't detected by libcec when support is not enabled.

The support for the Linux kernel API in libcec has been there for a while, but I don't have enough devices to test if CEC_FRAMEWORK_SUPPORT="yes" causes any regressions. A scan of the libcec version currently in use ( 4.0.7 ) appears to be able to handle common cases by detecting the Pulse-Eight USB, RPi, TDA995x and Exynos adapters first provided the APIs are available and Kodi has logic to iterate the peripherals should there be more than one for configuration in any case.

Based on these details, I suspect not enabling CEC_FRAMEWORK_SUPPORT for Generic might be considered a bug.

***Update WITH FIX to the libcec and i915 + DP++->HDMI cable with working cec-ctl behavior saga, posting for posterity:***

Quote

Just wanted to provide closure to this thread in case someone stumbles across it in the future. The peripheral mapping configuration in Kodi either isn't enough to solve this, or I just haven't invested enough time into getting it to work. I suspect the former.

My suspicions were correct. To get libcec to be able to use the i915 ( core i5-7500 ) with the DP -> HDMI with tunneling working as a cec peripheral, you have to enable the Linux API ( for cec ) in the build.

Just throw the CEC_FRAMEWORK_SUPPORT="yes" value into the Generic project options file.

On the build, the Linux API is enabled in the libcec package build, and when using a build with that enabled, the /dev/cec0 produced by the i915 and a working DP->HDMI cable/adapter will be available as a CEC peripheral in settings out of the box.

Not sure why this isn't a default configuration for the Generic project though.

Just wanted to provide closure to this thread in case someone stumbles across it in the future. The peripheral mapping configuration in Kodi either isn't enough to solve this, or I just haven't invested enough time into getting it to work. I suspect the former.

Just for context, I also rebuilt Kodi using the latest libcec. Kodi depends on libcec for cec device detection. Upstream libcec doesn't currently appear to have the logic needed to properly handle detecting the working /dev/cec0 device through the DP++->HDMI adapter path exposed through my i915 IGP driver.

So while cec-ctl ( using the Linux kernel CEC API ) is able to leverage /dev/cec0 properly and receive/send cec signals including the remote control signals, cec-client ( using libcec ) fails to detect any devices, so Kodi never knows to initialize any peripheral data. I could be missing something to making libcec work, but that will require I read through the libcec codebase further.

If you are testing the "functionality" of cec using the kernel API, you can use cec-ctl to register ( not sure if I'm using the terminology properly here ) the device type ( I use --playback ) and set features ( e.g. --osd-name "Kodi" --feat-deck-control --rc-src-media-top ) and the CEC enabled devices through the "cec bus" will start rambling if working.

If you're driver is already creating a /dev/cec0, you're part way there and cec-ctl will work when you register as a playback device.

If you can see the other cec devices and the signals/messages while monitoring ( e.g. cec-ctl --show-topology --monitor --raw-msg ), then there isn't any actual physical component issue. Messages going back and forth between external devices and your playback device means that physically, your CEC functionality is present.

When I had a non-functioning / cheap cable, I didn't see the topology consistently if at all ( TV, soundbar, etc will show up in messages and topology ). With a better quality cable ( apparently thicker gauge/fuller ), the topology and messages showed up fine when monitoring with cec-ctl, and I could even suspend, power off/power on the TV and take focus using various messages to the TV ( e.g. using cec-ctl --to ).

Perhaps I will explore looking into what improvements libcec might need to better detect this particular arrangement, as this is probably so niche that it likely won't ever see any effort. The alternative of adapting Kodi to use Linux API + libcec to detect cec devices it would be significantly high effort as well, and the workarounds ( LIRC / PulseEight / Etc ) is commonly lowest effort to get something up and running as is regularly recommended here on the forums.

In any case, the test steps outlined in this thread I think are a better, more conclusive way to determine CEC functionality on Linux and doesn't appear to be well documented anywhere else. This is irrespective if the software stack ( Kodi on libcec ) can take advantage of it or not.

Hey, thanks for the follow up. I initially suspected an issue across these components which is why my first steps were to isolate and verify operation of the cec device.

The cec-ctl testing shows that communication works fine through the devices involved. I can send standby and wake up the tv with it in addition to being able to capture the remote control signals coming from it.

This works consistently well across reboots and detachment/re-attachment of the adapter and cable, that it is very unlikely a factor in the issue with Kodi not registering a cec peripheral at this point.

The cec-ctl binary however doesn't ( as far as I can tell ) have a mechanism to integrate with kodi, as typically kodi would be the one to initialise the cec peripheral when it detects and registers it through libcec.

The issue starts with the logic in Kodi for scanning buses for peripherals and recognizing the cec feature/peripheral over the this particular bus. I've isolated this to the peripheral logic in the Kodi code base, and I'm going to continue reading through it in the coming weeks to get a better understanding of how the peripheral.xml mapping config integrates with the logic to see if adding an additional entry is sufficient to get it to detect this case.

Once Kodi can actually attempt to register the cec device, it will hopefully log the attempt ( and any failure ) which could surface gaps in the cec initialisation logic or underlying libcec.

Okay, after reading through some of the peripheral logic, I suspect that there may be a few limitations affecting this.

I think this may be missing an entry in the peripherals.xml mapping file. At present, I don't think it's scanning for the cec device based on this configuration. And because it doesn't get scanned, it never gets initialised. Otherwise, I would have expected more from the logs or even a peripheral_data file on the system.

What I don't know is if specifying bus="pci" and mapTo="cec" would be enough to have the CEC Adapater logic run on finding something with the cec feature on it.

Hello. I've recently deployed LibreELEC/Kodi 12.0.0 to a refurbished Lenovo m910x. It is connected to a Samsung RU7100 (65), via CD0712 ( active DP++ to HDMI ) and an HDMI cable that should allow the CEC pass through, but I never was able to receive any listing in the Settings -> Input -> Peripherals menu.

I've read through the other forums on this topic, and I've tested as far as I could with respect to the CEC interoperability. I started with first verifying that the device was being detected by the kernel:

media-client0:~ # udevadm monitor -k -u
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[825.644127] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV  [825.646289] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
KERNEL[826.667171] remove   /devices/pci0000:00/0000:00:02.0/cec0 (cec)
UDEV  [826.668230] remove   /devices/pci0000:00/0000:00:02.0/cec0 (cec)
KERNEL[828.826361] add      /devices/pci0000:00/0000:00:02.0/cec0 (cec)
UDEV  [828.827249] add      /devices/pci0000:00/0000:00:02.0/cec0 (cec)
KERNEL[828.882211] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV  [828.882960] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)

This does not appear to be the problem. Detected on boot up, as well as detects and recreates device node on re-seating of the adapter.

I then tried to verify that CEC was in fact working with cec-ctl when it is registered as a playback device:

hastebin

This also does not appear to be an issue. From this output, it suspect that the driver, the adapter and the cable allow the messages to make it the system without issue.

This is when I began to suspect something was going on with the way Kodi was initializing through libcec or how libcec was identifying devices, after all, it's the client software that ultimately needs to receive those messages.

These are the debug logs, and I enabled the libcec component hoping that something obvious would stand out to me in the log.

hastebin

I saw a section about CEC adapter mappings being loaded, and I tried to explore them further to better understand how that translated to identifying CEC functionality in this setup. Sadly, I am still too unfamiliar with the overall architecture of the software to make progress on this front.

At this point, I'm concerned that I've missed something obvious, such as some option ( it took me 3 hours to figure out the wifi thing w/ REGDOMAIN ), but everything that I've read up to now suggests that this should populate in in the input peripheral settings.

The next level of testing I've been looking into is whether I can test with libelec directly to see if I can isolate it there. It's still beyond me for now, but I'm hoping this post can help surface my next step on getting this particular environment working.

Any pointers are welcome.