Posts by jernej

Yes.

I found issue with CEC driver - arbitration lost event was not handled. Not sure how big an issue this is, but it surely is.

Here is my branch: https://github.com/jernejsk/LibreELEC.tv/commits/fixes

Note that there is still issue with ffmpeg6 transition: https://github.com/xbmc/xbmc/pull/23709

But that doesn't solve it. Video stream is corrupted. Not sure if it's possible to find a way to normally decode frames. Still, Kodi should deal with corrupted frames better...

Quote from frakkin64

I have never seen such an option with DRMPRIME. I think that is available with VA API? If it's possible would like to hear any tips about how to do that, didn't see anything in Player or System and I am at expert level, it would be a useful feature as Amlogic mainline also has MPEG2 HW decoding problems.

Sorry, I mixed up with other methods.

Quote from frakkin64

one I did to disable MPEG2_DEC capability in cedrus on h6

This one shouldn't be needed. Can't you specifically disable MPEG2 HW accel in settings (maybe expert view is needed)?

Quote from frakkin64

So far, after 22 hours of uptime there has been no freezing

what kind of changes do you have?

Any of you have serial console? I plan to build LE11 update with a lot of kernel debug functionality enabled. However, in order to be useful, it must output issues on serial in real time, so hopefully data is received before lock up.

Quote from jordixPI3

shoud i expect any feedback message after sending it?, do i need to re-enable CEC in settings?

No and no

Quote from frakkin64

[ 42.389083] cec-dw_hdmi: polling for LA 1 failed with tx_status=0x0030

[ 42.392601] cec-dw_hdmi: polling for LA 2 failed with tx_status=0x0030

[ 42.403417] cec-dw_hdmi: polling for LA 9 failed with tx_status=0x0030

Are you testing this on CEC capable device?

When you get frame processing timed out!, system shouldn't freeze/crash. That's why there is iommu, to prevent accessing non-allocated memory and thus corrupting memory. But then again, Cedrus might block one or more memory buses, which freezes the system regardless.

Disabling CEC doesn't solve issue #3 for you?

Is there a playback freeze or system crash? In any case, MPEG2 is easy to decode, so you can disable MPEG2 HW decoding. If you have a sample, I can take a look, but no promises. I found some workarounds for corrupted H264 streams, but not yet for MPEG2.

It's just with this patch: http://ix.io/4FbV I will send it for inclusion in upstream regardless since it makes code aligned with user manual. Regarding CEC, I was never too sure about https://github.com/LibreELEC/Libr…-on-error.patch Can you try to build without it? It gives those CEC warnings in dmesg.

LE11 test update in the same place.

Read https://wiki.libreelec.tv/support/update

Anyway, I'll prepare LE11 image since that ordering is current issue in LE12 development.

Please test update from http://jernej.libreelec.tv/test/h6-cedrus/

Note that this is development version of LE12, so there might be other bugs. If it doesn't work, I can still build LE11 update.

There is just one clock/reset fix, so Cedrus driver actually follow proper order now. It might or might not be the issue experienced here.

Quote from gadget_guy

just to clarify though, does changing that timing register with devmem take effect immediately? Or do i need to disable/re-enable the CEC option or something?

Yes, it directly writes to HW clock register. It switches CEC clock source from periph0(2x) clock to external 32.768 kHz crystal, but sadly not all boards have it. Still, there is no logic why it would help. In any case, I have also other ideas, for which I will make test images.

But does CEC work? Please test that. There is a reason why that register is set differently. In any case, devmem command could only be workaround, but not a solution. It needs to be solved on kernel level. However, I always had troubles even with original OrangePi 3, so there might be connection, HW wise. It's interesting that I never had any troubles with Tanix TX6. Unfortunately there is no schematic nor kernel source to compare what they done differently.

Well, documentation is scattered around. You need board schematic, which can be found on orangepi.org. Then you will probably want to see Allwinner H6 user manual, which can be found on linux-sunxi.org. Last but not least, you'll want to see CEC registers description. Unfortunately, you have to get creative here and find leaked DW HDMI documentation.

In any case, none of that will tell you anything about Pulse Eight adapter. You have to approach that one from Kodi perspective. Pulse Eight libcec library was first attempt at trying to make standard CEC library which can be used by applications. At that time, there were absolutely no standard kernel interface for CEC, so every device and SoC manufacturer did something hackish and incompatible with other solutions, even if same underlying HW was used. As you can imagine, Kodi used that to have any hope of supporting CEC on multiple devices. Later on, when Linux kernel finally got common CEC interface, Pulse Eight libcec library was extended to support this interface. Since Allwinner SoCs expose CEC functionality over this common kernel CEC interface, Pulse Eight library naturally also supports Allwinner SoCs (when using mainline kernel).

There is idea to get rid of Pulse Eight libcec dependency and use Linux CEC interface directly, but it's a lot of work that currently nobody wants to do.