CEC functionality stops working with hdmi_ignore_cec_init

[edrikk]

Hi,

I created a Ticket for the PINN project ( https://github.com/procount/pinn/issues/49 ) which was confirmed by the PINN Developer. However, it seems that the initialization code is the same as that of BerryBoot, so I am created a ticket here).

The issue is that within PINN, adding hdmi_ignore_cec_init=1 to the RECOVERY partition's config.txt stops the TV being turned on as it should, but it also disables all CEC controls if the TV is turned on manually..

The author of PINN is inquiring if the same issue is present in BerryBoot.

Really appreciate your help!

[maxnet]

The author of PINN is inquiring if the same issue is present in BerryBoot.

So did you install Berryboot to test that?

[edrikk]

Maybe @procount can comment to this. Myself, no. I have one setup which is otherwise working, and can't blow it up I'm afraid.

[procount]

I just tried it with BerryBoot and I get the same behaviour: hdmi_ignore_cec_init=1 causes CEC to become totally disabled, rather than just preventing the TV being switched to. Any ideas how to overcome this @maxnet?

[maxnet]

No idea. We outsource all CEC stuff to the closed source firmware. Don't know what it does and does not if that option is set.

[edrikk]

Ok, so two questions if you don't mind:

1. How up to date is the Raspberry Firmware that BerryBoot is compiling/calling against? I ask because I see there are several CEC fixes upstream since January 1st... E.g. https://github.com/raspberrypi/firmware/commit/3c3ff70bf9f8c0c8e4bc3fd7b5d08df53233ad4d

2. In your expertise, what difference would exist between BerryBoot and other applications (e.g. LibreElec, Rasplex, Embeded PlexMediaPlayer, Retropie, etc), whereby in those scenarios hdmi_ignore_cec_init is correctly actioned?

Really appreciate your support!

[maxnet]

1) Berryboot uses the latest firmware at the time it is compiled... 2) they use libcec instead of the firmware's internal CEC handling We cannot use libcec since it requires commercial licensing when used in non-GPL applications.

[maxnet]

BTW you also may want to ask Samsung about the status of the firmware update they promised.

https://www.theverge.com/circuitbreaker/2017/5/24/15684902/samsung-tv-hdmi-switching-forums-complaints-statement

[macmpi]

Indeed the issue came-up with latest 4.9.x-based Berryboot: HDMI in OS selection UI is lost when hdmi_ignore_cec_init=1 is added Previous 4.4.x versions did not suffer from this. Indeed 4.9.x came with several changes on HDMI side...

[maxnet]

Indeed the issue came-up with latest 4.9.x-based Berryboot: HDMI in OS selection UI is lost when hdmi_ignore_cec_init=1 is added

Doubt it worked before with that option.

The only 4.9 specific thing was that it reported a different architecture with 4.9 (BCM2835 instead of BCM2709) Causing the code that detects whether Berryboot is being run on a Raspberry or different ARM board to fail. This was fixed in 20170527

The actual CEC code lives in the firmware, not in the kernel. So shouldn't matter whether kernel is 4.4 or 4.9

[macmpi]

I confirm it did work in several "pre-4.9" Berryboot releases. Newer BB release does include new firmware files which bundle some changes related to HDMI.

[maxnet]

I confirm it did work in several "pre-4.9" Berryboot releases. Newer BB release does include new firmware files which bundle some changes related to HDMI.

Then I suggest you figure out which firmware commit exactly, and open an issue in raspberry/firmware

I use a normal computer monitor as display for my Raspberries, so don't really test CEC.

[macmpi]

Probably similar issue to this https://github.com/maxnet/berryboot/issues/402 probably

My working release was berryboot-20160209-pi0-pi1.zip for sure.

[macmpi]

Maybe @popcornmix has some insights on firmware-related CEC changes which may cause this regression in BB and PINN? Any suggested specific firmware file change to help characterize the critical commit # ?

[popcornmix]

There was some work done on firmware CEC that started Dec 30 2016. There were issues reported and on March 1st 2017 the changes were reverted. So current firmware CEC behaviour should match behaviour prior to Dec 30.

hdmi_ignore_cec_init=1 is only designed for use with libcec. Note if libcec licensing is a problem, there is kernel CEC support coming in the future: https://www.phoronix.com/scan.php?page=news_item&px=HDMI-CEC-2017-State

[maxnet]

Note if libcec licensing is a problem, there is kernel CEC support coming in the future: https://www.phoronix.com/scan.php?page=news_item&px=HDMI-CEC-2017-State

Yes, that might be the best long term solution.

My understanding is that the driver for the new CEC framework hooks into the vc4 video driver though. And while the effort done on vc4 video driver is promising, I am not sure if that is currently in a usable state yet. Had problems getting vc4 to work when statically compiled into the kernel last time I tried. Which is kinda a requirement for Berryboot, as its GUI is displayed before the data partition that contains the kernel modules is mounted. Prefer not to delay showing GUI until data paritition is mounted, as that could be on a slow to spin up USB hard drive, and having a blank screen for 10+ seconds is not so user-friendly...

Also the Linux distributions started by Berryboot (under same kernel) aren't quite vc4 ready yet. Even had issues with Raspbian. With that the main desktop did appear, but the start menu (lxpanel) at the top did not, when the vc4-kms-v3d overlay is active. Perhaps related to audio, as syslog showed that pulseaudio was having issues as well, and the panel does have a volume control tray icon thingy on it. But haven't had time yet to properly look into that, and fill a bug report.

[ghost]

Hey,

Updated to last version and CEC works. But only if I turn on my TV and then turn on the raspberry. If I reboot from rasbpian to Berryboot menu everything works fine.

Maybe the force hotplug doesn't work for me?

[macmpi]

Running berryboot-20170527, and CEC still deactivated if hdmi_ignore_cec_init=1 is set, unlike in the previous version I used (berryboot-20160209).

(BerryBoot not listed as HDMI peripheral on TV screen if hdmi_ignore_cec_init=1 is set)

[popcornmix]

@No3ight For CEC to work the Pi must read the physical address of display from edid. On some displays it cannot do that when display is in standby. hdmi_force_hotplug is not sufficient for this - you need to store edid to a file: http://kodi.wiki/view/Raspberry_Pi_FAQ#TV_is_not_detected_unless_powered_on_first

[maxnet]

hdmi_ignore_cec_init=1 is only designed for use with libcec.

Am I creating any big issues if I try to initialize it myself like this?

    uint16_t physaddr;
    CEC_AllDevices_T logaddr;
    vc_cec_get_logical_address(&logaddr);

    if (logaddr == 0xF)
    {
        /* Not initialized yet */
        vc_cec_set_passive(false);
        vc_cec_alloc_logical_address();
        QThread::sleep(1);
        vc_cec_get_physical_address(&physaddr);
        vc_cec_send_ReportPhysicalAddress(physaddr, CEC_DeviceType_Rec, false);
    }

Seems sufficient for my TV.

[popcornmix]

Seems sufficient for my TV.

Maybe... Almost no manufacturers claim to support CEC, they just claim to support their own proprietary brand of CEC (AnyNet+, Bravia Link, SimpLink, VIERA Link etc) with no promises of interoperability.

libcec provides the huge list of quirks that makes cec largely work with a range of manufacturers. Without it I suspect what you are doing will work for some...

[edrikk]

I would just like to point out the technically obvious. If/given @popcornmix note that

hdmi_ignore_cec_init=1 is only designed for use with libcec.

What is interesting is why the firmware is even reading in and reacting to the "unknown to it" parameter. i.e. if it's doing a strcmp, then there is clearly logic that is disabling CEC functionality. If it's doing a strncmp (and therefore ignoring the _init), then I would argue they have a bug in their parameter parsing.

Of course it's closed source, so who knows.

@procount I think given that you have made it clear that PINN's CEC implementation has only been tested on Samsung, the fact that the above approach works is in my opinion sufficient. If there are issues, it will bubble up. Even then, if it's possible to wrap that in an "if" based on the _init parameter, the normal flow wouldn't be impacted.

Just my 2 cents.

[ghost]

@popcornmix

Thanks for your advice. I've tried your solution but that didn't work for me.

My TV takes too long to power up so that it won't recognize an active source at boot.

But now I get this work like following:

First boot up TV into Standby mode, then power up PI. Voila CEC is now working.

Greetings from Germany

[macmpi]

@popcornmix

So current firmware CEC behaviour should match behaviour prior to Dec 30. hdmi_ignore_cec_init=1 is only designed for use with libcec.

There must still be few CEC-related changes in, as with berryboot-20160209 (unsure about actual firmware version) hdmi_ignore_cec_init=1 was working as expected, and now is not anymore... How can this be investigated further? Thanks!