cec-ctl on Generic

  • I was following th thread on CEC-client on RPI. And note that the direction suggested was CEC-CTL.


    On the generic nightly matrix image it is not there. Is there a reason for that? It would be good to have cec-ctl available on the Intel NUC.

    I was reading this reference. I have some issues with the way that my CEC environment behaves, and being able to pass though commands to the CEC devices would probably give me a good workaround.

    CEC-HDMI - UDOO X86 Docs

  • Thanks HiassofT . Just fixed my build environment. Was about to send @jernej a note on updating the wiki to add the following (not sure which on fixed the build)

    apt install --reinstall python3-pkg-resources python3-setuptools

    apt install --reinstall python-pkg-resources python-setuptools

    pkg_resources was missing for the build of zstd:host

    Compile [LibreELEC.wiki]

  • First impressions:-

    - the cec-ctl binary is there

    - the seco_CEC kernel module is there

    - the module doesn’t work with the Pulse8 (compiling that module now)

    ——-

    LibreELEC (community): pr4627 (Generic.x86_64)

    LibreELEC:~ # dmesg | grep -i cec

    [ 3.037539] input: Pulse-Eight CEC Adapter as /devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.2/0003:2548:1002.0001/input/input4

    [ 3.037614] hid-generic 0003:2548:1002.0001: input,hidraw0: USB HID v1.10 Mouse [Pulse-Eight CEC Adapter] on usb-0000:00:14.0-6/input2

    LibreELEC:/ # modprobe -v seco-cec

    insmod /lib/modules/5.9.0/kernel/drivers/media/cec/platform/seco/seco-cec.ko

    LibreELEC:~ # lsmod | grep -i cec

    seco_cec 20480 0

    LibreELEC:~ # cec <tab>

    cec-client cec-client-4.0.7 cec-ctl cecc-client cecc-client-4.0.7

    LibreELEC:~ # cec-ctl

    Failed to open /dev/cec0: No such file or directory

    LibreELEC:/dev # find . | grep -i cec

    ./serial/by-id/usb-Pulse-Eight_CEC_Adapter_v8-if00

    ./input/by-id/usb-Pulse-Eight_CEC_Adapter_v8-if02-event-mouse

    ./input/by-id/usb-Pulse-Eight_CEC_Adapter_v8-if02-mouse

    ** I think the required driver for the NUC is the “CONFIG_USB_PULSE8_CEC=m” — I have updated the linux.x86_64.conf file and started a recompile. I’ll check in a bit later.

  • Hi HiassofT I believe I have worked our the required pieces.

    Added this to the configuration. “CONFIG_USB_PULSE8_CEC=m”

    Full diff against master is - http://ix.io/2CxB (I made all of the serial stuff modules)

    It only used the following though

    LibreELEC:~ # lsmod

    Module Size Used by

    serport 16384 1

    pulse8_cec 24576 1

    ##

    modprobe -v pulse8_cec debug=2

    inputattach --pulse8-cec /dev/ttyACM0 --daemon

    dmesg....

    [35462.886070] serio: Serial port ttyACM0

    [35462.886282] pulse8-cec serio0: transmit FIRMWARE_VERSION: 15

    [35462.888117] pulse8-cec serio0: received FIRMWARE_VERSION: 15 00 08

    [35462.888133] pulse8-cec serio0: Firmware version 0008

    [35462.888137] pulse8-cec serio0: transmit GET_BUILDDATE: 17

    [35462.890240] pulse8-cec serio0: received GET_BUILDDATE: 17 59 71 c4 88

    [35462.890259] pulse8-cec serio0: Firmware build date 2017-07-21T09:08:24

    [35462.890265] pulse8-cec serio0: transmit GET_AUTO_ENABLED: 19

    [35462.891982] pulse8-cec serio0: received COMMAND_REJECTED: 09 19

    [35462.892000] pulse8-cec serio0: transmit SET_CONTROLLED: 18 01

    [35462.893792] pulse8-cec serio0: received COMMAND_ACCEPTED: 08 18

    [35462.893886] pulse8-cec serio0: transmit GET_AUTO_ENABLED: 19

    [35462.895597] pulse8-cec serio0: received GET_AUTO_ENABLED: 19 01

    [35462.895692] pulse8-cec serio0: transmit GET_DEVICE_TYPE: 21

    [35462.897352] pulse8-cec serio0: received GET_DEVICE_TYPE: 21 04

    [35462.897371] pulse8-cec serio0: transmit GET_LOGICAL_ADDRESS_MASK: 1d

    [35462.899106] pulse8-cec serio0: received GET_LOGICAL_ADDRESS_MASK: 1d 09 10

    [35462.899127] pulse8-cec serio0: transmit GET_PHYSICAL_ADDRESS: 1f

    [35462.900878] pulse8-cec serio0: received GET_PHYSICAL_ADDRESS: 1f 13 00

    [35462.900896] pulse8-cec serio0: transmit GET_HDMI_VERSION: 23

    [35462.902562] pulse8-cec serio0: received GET_HDMI_VERSION: 23 05

    [35462.902578] pulse8-cec serio0: transmit GET_OSD_NAME: 25

    [35462.904458] pulse8-cec serio0: received GET_OSD_NAME: 25 4b 6f 64 69

    [35467.648788] cec cec0: transmit SET_CONTROLLED: 18 01

    [35467.650511] cec cec0: received COMMAND_ACCEPTED: 08 18

    # ls -lt /dev/char/250\:0 /dev/cec0

    crw-rw---- 1 root video 250, 0 Oct 31 11:37 /dev/cec0

    lrwxrwxrwx 1 root root 7 Oct 31 11:37 /dev/char/250:0 -> ../cec0

    # cec-ctl

    Driver Info:

    Driver Name : pulse8-cec

    Adapter Name : serio0

    Capabilities : 0x0000002f

    Physical Address

    Logical Addresses

    Transmit

    Passthrough

    Monitor All

    Driver version : 5.9.0

    Available Logical Addresses: 1

    Connector Info : None

    Physical Address : f.f.f.f

    Logical Address Mask : 0x0000

    CEC Version : 1.4

    Vendor ID : 0x001582 (Pulse-Eight)

    OSD Name : ''

    Logical Addresses : 1 (Allow Fallback to Unregistered)

    Logical Address : Not Allocated

    Primary Device Type : Record

    Logical Address Type : Record

  • Will recompile and retest.

    Code
    -CONFIG_SERIO_SERPORT=y
    +CONFIG_SERIO_SERPORT=m
    
    -CONFIG_CEC_CORE=y
    +CONFIG_CEC_CORE=m
    
    +CONFIG_CEC_NOTIFIER=y
    +CONFIG_MEDIA_CEC_SUPPORT=y
    
    +CONFIG_USB_PULSE8_CEC=m
  • heitbaum now the big question is: does cec-ctl work better than cec-client?

    We deliberately use libcec for the pulse 8 adapter (and not the kernel driver) as that's the software developed by pulse 8.

    So if there are issues with the pulse 8 adapter or libcec it's up to pulse 8 to solve them.

    so long,

    Hias

  • Hi Hias,

    100% agree with the get the supported approach, for which is the official libcec. As I understand it libcec is now supporting the Linux kernel framework (in passthrough) since April 2020 - RFC: Linux CEC framework adapter by Kwiboo · Pull Request #380 · Pulse-Eight/libcec · GitHub With the kernel driver (5. CEC Kernel Support — The Linux Kernel documentation) integrated with libcec now and allowing Kodi to continuing to exclusively use the libcec api. My proposed patch for which I note that Milhouse had eluded to in a recent Generic image #0717 - LibreELEC Testbuilds for x86_64 (Kodi 19.0) and in the below GIT branch.

    The Milhouse branch where the CEC changes are for Generic is: Comparing LibreELEC:master...MilhouseVH:le10_libcec_next-drop-framework · LibreELEC/LibreELEC.tv · GitHub

    The patch I'm proposing is:

    Comparing LibreELEC:master...heitbaum:master · LibreELEC/LibreELEC.tv · GitHub

    pulse8-cec: enable via Linux Framework · LibreELEC/LibreELEC.tv@79fb25d · GitHub

    The patch includes all udev and systemd changes to make it work. I have included a binary compile in my patch just for the time being - but would propose incorporating linuxconsoletools-1.7.0.tar.bz2 and compiling the utils/inputattach

    This still maintains the normal libcec operation within Kodi - but also integrates the remote control passthrough feature into the kernel’s remote control framework.

    Hope this answers all the questions and that it can be incorporated in the mainstream Generic support.

    Thanks

    Rudi

  • You still haven't answered the main question: does that improve something?

    We discussed that internally a while ago and decided against switching pulse 8 CEC to the kernel API and enabling CEC RC support for various reasons:

    In passthrough mode core CEC will still be handled by libcec so the kernel driver only acts as a rather simple transport device. If pulse 8 decides to change something in their internal device communication protocol we can't simply update libcec but will have to wait for kernel patches to appear - which can be a real PITA, especially as we have to also care about older kernels during stable releases and testing bleeding edge kernels during development. It's best to avoid adding unneeded dependencies.

    Upstream kodi and libcec are mainly tested and used with userspace pulse 8 integration. Again, there'd need to be really strong reasons (which I don't see ATM) to deviate from that.

    So, to sum it up, the pulse 8 kernel driver is great if you don't want to use libcec, but as we / kodi already use that there's little point in doing a switch.

    so long,

    Hias

  • Hi HiassofT

    Some background on why I'm interested in following this through probably in order.

    Note: I did laugh at the comment "CEC is pretty much voodoo to me...!" - so true.

    I have the following AV equipment:

    - Panasonic Viera TH-50PX600A

    - Sony STR-DN1040

    - Intel® NUC Kit NUC6i5SYH with "Intel NUC HDMI-CEC Adapter" (LibreElec Matrix)

    - Apple TV 4K

    - Cisco Webex Room Kit (experimenting / WfH)

    - BrightSign CV-UHD2 / CV-HD2 (experimenting)

    - Elgato 4K60 S+ / HD60 S (experimenting)

    - Xbox 360 S (no CEC support)

    I have the following home automation: Apple HomeKit, Apple HomePods, Hue Lighting, Homebridge (experimenting with openHAB).

    The lighting works well - the rest ..., leave that unsaid.

    I have had a love hate affair with the CEC in Kodi and AppleTV.

    I was excited to purchase the HDMI-CEC adapter in 2018 (but that was short lived... - as below)

    - The AppleTV sends a power on (but the Panasonic ignores it - CEC bug / non standard) - so the TV is always on. The Sony AMP changes itself to the AppleTV HDMI input.

    - The Kodi generally misbehaves.

    a) (Given my "Panasonic BUG" - that I would like to teach Kodi to send the following codes 80:44:40,80:45) as it already is successful in "power off" the Panasonic - thus I need to find the Panasonic Remote Control .

    b) Kodi loves to own the CEC network and when the Sony AMP decides to power off - due to no Audio. Kodi will decide to Turn the AMP back on.

    c) On swapping to AppleTV - Kodi does not honour the CEC commands always and switches back to Kodi. We then go and power Kodi off :(

    d) When the remote control menu item <play> is pressed on the iPhone remote - the AMP does not switch on/nor does the input on the AMP change. The Apple TV using the Remote contol does power on the AMP and change the input (think Kodi should too.)

    I had a look at: GitHub - joshjowen/script.json-cec: cec control for xbmc/kodi (to put some scripted workarounds in), but it does not allow arbitary CEC codes to be pushed. As Kodi owns the the CEC device entirely, I can't write a script to fix/workaround my issues. If I tell kodi to not enable CEC, then I can use cec-client to fix some of my issues.

    The Sony AMP doesn't really automate very well either, though the codebase - GitHub - balert/Sony-STR-DN840-Remote-Python: Control your STR-DN840 receiver via the network interface. does work.

    I have worked on a state machine diagram of what I want to happen so that this can be configured in to the home automation. But without the ability to issue CEC commands - I have reached the "unhappy - it does not work state."

    Options as I see it:

    1 - Use the kernel framework (same as #1 - but with no required code change)

    2 - Have passthru access through Kodi to CEC (Changes to Kodi/script.json-cec/libcec)

    3 - Disable Kodi CEC and hack with cec-client

    4 - Develop functionality (addon) in Kodi - haven't really investigated - relies on #1 in some way

    5 - Buy a dedicated CEC device

    6 - Buy a new TV (and hope it works right - hi risk - what is works right)

    7 - Give up --> :( - as I actually like my "pet project"

    The actual Panasonic BUG - Power On does not work:

    Panasonic Viera TH-50PX600A - Power On does not work · Issue #511 · Pulse-Eight/libcec · GitHub (not fixed in libcec - I don't see it being fixed by pulse8 anytime in the near future)

    Need to send the following to make it work:

    In my case: (Playback 2 —> TV)

    80:44:40

    80:45

    In my enterprise office work environment we toy / flirt with "AV Control Systems" - and most of the time they are broken in their own special way. We have been successful with end-user devices like Cisco Webex hardware mostly with wireless screen sharing. But continue with the usual issues using HDMI extenders and the like. Recently been looking at Wyrestorm, rticorp.com, Cisco Video to simplify AV in the office and standards based AV/IP. I guess - what does this have to do with the /dev/cec0 discussion - I'm looking to have a working Home Automation system and the Kodi CEC configuration as-is doesn't allow for that. Overtime and if I can get my state-machine automation fully correct and working well - it might be that #4 could be done on either the built in CEC or as a addon.

    Hope the above helps my case.

    I do understand the support issue that you have mentioned though and would not at all propose to move from the userspace integration - it is good to have pulse8 looking after that codebase. My question to this - is that we are already supporting the Kernel interface for the other hardware (note: I don't disagree that linux-console is an additional product though.)

    Regardless of the core teams decision to change the way for everyone, I would like to continue down the route of using cec-ctl for the moment, even if I have to maintain a separate branch/autstrat.sh commands. I would appreciate you pointing me in the right direction to add the build of linux-console into my branch though (so that it was buil;t properly.)

    **Note: Without implementing my proposed systemd/udev changes - Kodi Generic would continue to use the /dev/ttyACM0 mechanism. The Kernel Framework is only ever activate if the modprobe and inputattach are run.

    Thanks for your consideration.

  • I really think this should be solved in libcec, or alternatively in kodi, by eg providing some quirks options to workaround the issues with your TV. TBH that issue doesn't really sound like it would be specific to LibreELEC, probably libcec/kodi on Windows would have the same problems - solving the problem at the core would benefit more users.

    so long,

    Hias