jernej

It has, all H family has 2 mixers. Addresses are hidden in DE BSP source code, but not as absolute address, only as relative. In any case, you don't need second mixer if you won't use any other display output. Note that there is no documentation for DE3.3. There is documentation for DE3 on linux-sunxi.org, which is older, but nevertheless similar core. Still, BSP source code will give you best info, even if it's sometimes hard to understand. In any case, you seem to be on right track to get it working. I strongly suggest that you dump register values of all components involved in pipeline from working BSP solution (most likely Android image) and compare to them to register values dump from your mainline based system. This includes TVE, TCON top and also very importantly, clocks and resets. One extremely useful trick for diagnostics is to use TCON test patterns. Those patterns are directly generated in TCON and then piped to encoder, TVE in this case. It allows you to test TVE without worrying about mixer and if it's properly routed through TCON top. Those test patterns can be enabled by setting TCON register 0x40 to, for example, 1, which will get you well know color check pattern. Note that your solution with TV TOP included in same driver as TVE will work here, but it's not appropriate solution for upstream. TV TOP should be standalone driver like TCON TOP...

If you want Kodi and smooth video playback, you can always check LibreELEC. OPi3-LTS has some bugs, so best build is here, but you can wait for next point release which will be done in about a week. Video playback needs some work in progress software if you want smooth experience, which afaik is not present (yet) in Armbian.

I don't have neither of these boards, but I can help answering any question regarding state of the art drivers in mainline kernel.

Note that crust is very board specific. If it doesn't have IR by default, you have to enable it in config. Apart from that, you have also select correct IR protocol and key code. On some boards you also have to select proper clock for IR.

I don't know this board, but it seems button is directly wired to reset pin, so reset is expected response. This board isn't the best choice for testing this. Maybe you can try with RTC wakeup. Or maybe even HDMI-CEC wakeup, but you need to change config for this one.

Which board do you use for testing?

Crust is successfully integrated on A64, H3, H5 and H6 in LibreELEC. R40 and H616 don't have co-processor, so they can't have it. I don't know A83T state. H3 needs additional U-Boot patches which are in conflict with other SoCs (including R40), so it's best to have them separated. Easiest test is to use board with power button. Put board in sleep with "systemctl suspend" or power it down via command line (poweroff, shutdown now, etc.). Once it's in sleep or in stand by mode, press power button. If everything works as it should, board should come to life. Serial console is highly recommended during testing and a must for debugging any kind of issues.

No, that part is correct, but I must admit that since I have no system with patched ffmpeg at hand currently, I misremember how request api is expressed in ffmpeg decoders list. In any case, request api is covered by drm hwaccel and use drmprime pixel formats. Anyway, it seems you succeeded in reaching your goal.

Not sure what are current defaults, but that's generally on the low side. LE uses CMA size of 384 MiB, mainly due to 4k. They fix one buffer management issue which may cause incorrect decoding but most importantly, they massively lower amount of memory that's used during decoding. Those fixes are included in 6.2 and newer kernels. Use following command for testing: ffmpeg -loglevel debug -hwaccel drm -hwaccel_output_format drm_prime -i video.mkv -f null - It will be pretty obvious from debug log if request api is used or not. Not sure which version of mpv you're using, but very latest (not sure if it's in released version or in development branch) should allow using request api ffmpeg also when window manager is running. EDIT: make sure that this ffmpeg patch is included: https://github.com/jernejsk/FFmpeg/commit/5057eb96b2adbff022a1abd8d5b06f369f908d51

*_v4l2m2m codecs are for v4l2 stateful drivers, not request api. Actually, you have to grep for "request" word. Check that you have 6.1 kernel headers installed. IIRC last important kernel patches went into 6.2, so ideally you would run that. Last but not least, to know which codecs are supported, you have to use v4l2-ctl command. Easiest way is to use --all parameter and check for supported formats on cedrus device.

Encoding is not supported by mainline driver. There are some hacks posted on this forum how to make it work using vendor driver, but you need to patch kernel and ffmpeg and you can only have encoding or decoding working, not both.

v4l2 request is already supported by gstreamer natively. Only question is if it's enabled in distributed binary.

CEC on H6 works just fine, as I used it many times, although not with Armbian. I can think of following reasons why CEC doesn't work: 1. make sure it's enabled in TV settings. I had to enable it on LG TV and old plasma TV. BEWARE: Setting is usually hidden under commercial name like simplink, easylink, etc. 2. make sure your libcec is new enough, at least 4.0.5 3. make sure driver is loaded (check for /dev/cec0) 4. it could be cable issue, although that's unlikely

GPU drivers are one of the most complex drivers possible. Basically, you have to write compiler in mesa and task scheduler in kernel. So no.

Times are changing, read this, this and this. Far from being able to use it out of the box, but it's possible.