Trying to understand how CEC mapping works

    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:

    Display Spoiler

    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.

    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.

    As MatteN says not many PCs have built in support for CEC and even if they have there may be a number of obstacles.

    You have 5 components 1. PC, 2. DisplayPort to HDMI adapter, 3 HDMI cable, 4. TV, 5. things connected to the TV any one of which could be the problem. My guess would be number 1 - the PC.

    Simple tests:

    If there is anything else connected to the TV disconnect everything, turn of mains power and leave to c10 minutes then plug the PC's HDMI cable back in. Why this may work I do not know but in my case (Dell Optiplex) I had to switch the DVD player to SCART.

    If you have a RPi or can borrow one try that - it will prove (or fail) the TV and HDMI cable. If this works you'll probably need a Pulse-Eight adapter which is what I have.

    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.

    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.