Posts by heitbaum

    Hi chewitt - dd’ed the vim3 2020-Dec-19 13:16 image to the SD card and booted it.

    Not exactly sure on what is not working, after the boot kernel message, we get some orange on the screen then loose hdmi signal, and led light goes off.

    From the rescue SD, was able to install a coreelec.kresq image

    Also a little unsure on the required update to the u-boot to SPI/emmc from your repo. I’m running 2020.4 (November) on the unit at the moment. With “kbi bootmode w spi”.

    A pointer would be great.

    Checking with ffmpeg it definitely decodes, but I can’t tell if it is using the hwaccel? And why/what the profile it has mapped the .ISO (mpeg2video) to.

    Code
    ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -i a.iso -pix_fmt yuv420p a.yuv

    HWAccelIntro – FFmpeg

    #6668 (MPEG2 decoding failed with FFMPEG-VAAPI) – FFmpeg

    Based on the above post - moeg2video HW decoding was suppose to be fixed in Jan 2020 and in the following ffmpeg branches - master n4.4-dev n4.3.1 n4.3

    I have been chasing the errors in my kodi.log for a while now. As you would know I think I have made all Intel Generic current or head in the build tree.

    Code
    2020-12-06 21:48:28.754 T:5314    ERROR <general>: VAAPI output: Postproc preinit failed
    2020-12-06 21:48:28.787 T:5314    ERROR <general>: VAAPI/vpp vaCreateConfig error: the requested VAProfile is not supported (12)

    This occurs when playing ISOs (DVD) or mpeg2video as the video stream in a MKV.

    I have believe that the that Intel chip is suppose to suppose this decoding. As per the details at VAProfile is not supported (12) With MPEG2 playback · Issue #477 · intel/libva · GitHub VAProfileMPEG2Main is supported.

    The media details itself are:

    Code
    Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, progressive), 720x576 [SAR 16:15 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc

    The full ffprobe output of the ISO is at - http://ix.io/2GQe

    I added vadumpcaps to my build tree - vadumpcaps: add vadumpcaps to show all capabilities of a VAAPI device… · heitbaum/LibreELEC.tv@821ea50 · GitHub and from that it seems like Kodi/.... is incorrectly mapping the media type to 12 (which is JPEG.) - full output at http://ix.io/2GQl

    So by my reading of vadumpcaps - VAProfile should be 1 for this media? Is this right / or am I chasing the wrong thing?

    Code
            {
                "profile": 1,
                "name": "MPEG2Main",
                "description": "MPEG-2 Main Profile",
    ....
            {
                "profile": 12,
                "name": "JPEGBaseline",
                "description": "JPEG",

    Took delivery of my N2+ Yesterday (Sunday) - DHL working all days at the moment....

    after a bit of stuffing around and a pointer from tobetter. My notes to install Ubuntu 20.10 with 5.10rc and panfrost on the device - http://ix.io/2G19

    In reading your chewitt logs in the mainline, it seems this N2+ is really only just now being supported in mainline without the ARM mali binaries.

    start [linux-meson]

    Looking forward to running up LE on this.need to get back to coding.

    I would like to suggest increasing the default log_buf_len to 128K or 256K (not the 16M that I have on my dev unit)

    The later 5.x kernels boot logs are no longer complete using the default ring buffer size.

    # grep log /flash/syslinux.cfg

    APPEND boot=LABEL=System disk=LABEL=Storage log_buf_len=16M quiet

    # dmesg | wc

    961 8316 65437

    # uname -a

    Linux LibreELEC 5.9.11 #1 SMP Thu Nov 26 12:54:34 UTC 2020 x86_64 GNU/Linux

    Happy to raise a PR either as syslinux or CONFIG_LOG_BUF_SHIFT if this makes sense.

    Hi Team,

    Suggesting we move to Version 2017.3.23AR.x as has been done in some mainline distributions.

    E.g. Linked packages : ntfs-3g

    Details are available at: NTFS-3G: Changelog for the Advanced Versions

    Also noting some changes to behaviours of the caching in the driver (read the change log - NTFS-3G Safe Read/Write NTFS Driver Activity )

    Specific patches are:

    NTFS-3G Safe Read/Write NTFS Driver / ntfs-3g / Commit [39384c]

    NTFS-3G Safe Read/Write NTFS Driver / ntfs-3g / Commit [5d6fd5]

    If this is an suitable direction to move in, I’ll create a branch and put together a draft pull request.

    Hi All,

    As FYI only.(I'm rebuilding back to 5.9.6) against GitHub - heitbaum/LibreELEC.tv: Just enough OS for KODI and will advise. How it goes.

    I just rebase lined GitHub - heitbaum/LibreELEC.tv at build_rudi + Kernel 5.9.7 against GitHub - heitbaum/LibreELEC.tv: Just enough OS for KODI

    The compiled 5.9.7 with the rebase lined LibreELEC/Master "82a92d8d21762f2dc442b7794a6e02e3c5b74316" on the NUC6i5SYB is having kernel issues with: Workqueue: events azx_probe_work [snd_hda_intel]

    Logs are at: http://ix.io/2DJH

    Linux edbf6b369537 5.9.7 #1 SMP Tue Nov 10 13:49:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

    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.

    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

    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

    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.