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:
This was outlined in my first post on the forum:
RE: Trying to understand how CEC mapping works
[…]
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…
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.