CEC_FRAMEWORK_SUPPORT not enabled for Generic build

    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. /shrug

    It's historically very rare to see CEC capabilities on x86_64 hardware so the feature has long been intentionally omitted on Generic derived images (while enabled on ARM SoC devices which almost all have CEC capabilities). As such you can't claim it to be a bug. If there is now a trend of hardware being available; we might need to revise the build confguration. However it's not obvious that this is true, so I would focus on showing/sharing technical evidence of a need.

    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: Trying to understand how CEC mapping works

    ***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.