usual user

Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302 
 
Although I not sure about what DWC3 driver limitation he is talking about. (HDMI+hub combo working fine for me on ROCKPro64 with legacy kernel.)

You referenced the raw device by "/dev/mmcblk1" where MBR , u-boot and partitions reside.
You need to reference a partition by "/dev/mmcblk1pX" where a suitable filesystem resides.
Replace "X" with the number of the partition you want to check.

ftdoverlay is a convenient way to apply an overlay staticly to a base dtb. You spare the DTC decompile - manually edit - DTC compile dance. Usually you write overlays with label refernces, but to be able to apply such an overlay, the base dtb has to be compiled with the @-option. This has significant impact on the size and distributions usually don't do this. When you write the overlay with full paths, it contains all the information to be applied to a base dtb that was not created with the @-option. The mainline ftdoverlay need the patch to be able to apply it.
 
Edit the pwms property to any value you like as shown in the provided rk3399-rockpro64-tz.dts (50000 default changed to 10000).

Out of curiosity I built the armsoc driver for my rk3399. I can confirm your observation of the faster display output. Of course, there is no 3D acceleration because the driver has no way to delegate 3D requests to the 3D render node. The armada driver (you want the unstable-devel branch) I use for my imx6 has such an ability and surpasses the rk3399 with modesetting despite the lower specification for now.
IMHO armsoc is a dead end until it gets a similar ability. And using glamor with its unnecessary scanout indirection via 3d is also a bad idea. We are all in the same boot, no xorg driver to glue all IPs in an efficient manner together available.
xorg-rockchip-modesetting.logxorg-rockchip-armsoc.logxorg-imx-armada.log

Error prone HW design with floating IO.
Proper design with fixed IO states:
VCC --------> Pullup Resistor ---| GND --------> Push Button -------+------> PA19 The pullup is already in place.
Pressing the button will flip the IO from 1 to 0.

For my NanoPC-T4, I want to be able to install multiple kernel versions at the same time and boot a specific one by default. In addition, I would like to be able to select which kernel to start if necessary:
Armbian_20.07_Arm-64_focal_dev Boot Options. 1: linux-default 2: 5.8.0-rc4-arm-64 3: 5.8.0-rc3-arm-64 4: 5.8.0-rc2-arm-64 5: 5.8.0-rc1-arm-64 6: linux-test To present my solution, I have used "Armbian_20.07_Arm-64_focal_dev_5.8.0-rc4.img.xz" and "u-boot-rk3399-nanopc-t4.img 07/10/2020 8:50am" on a microSD:
With this scheme in place I am able to pull in a new kernel without the need to port over my local image configuration to a new image. If the new kernel is not working as expected all previous available ones are just a reboot away. If the new kernel version is suitable for boot on demand just a new boot stanza in extlinux.conf is nessesary.
The mainline uboot for NanoPC-T4 has not yet enabled USB keyboard support. Therefor the on demand selection of a boot option will only work via the serial console keyboard.
The build of uboot with the same options in nanopc-t4-rk3399_defconfig as it was done for Pinebook Pro and rockpro64, should probably enable it in a similar way. This means that only HDMI display and USB keyboard are required.

An USB video sink is a standard USB host port consuming the video via UVC function. I.e. you plug in a USB webcam in your USB port and you get a /dev/videoX device.
This will not work quite well due to the bandwidth requirement for the raw video. Using native Ethernet would already be a challenge.
The proper way is to use hardware encoders at the host and forward the processed stream. With zero copy (dma_buf) video pipeline this puts little strain on the CPU.

I don't see anything in the links you have provided that this would be a solution to your problem.  Are you sure that you have the that chip on your board?  (i.e. have you opened the case and inspected?).  In order to get things working, you need to have your dtb, driver and hardware all in sync.  The dtb is the mapping between the hardware and the kernel, I would expect that this is the real source of your problems that your dtb is referencing different hardware than what you have installed on your board.  The problem with armbian for android tv boxes is that while there are only a few different reference dtbs available, but there are hundreds of different boards with different components from all the manufacturers.  So most of the boards will not work in some way because of the mismatch between their hardware and the dtbs that are available (sometimes you get lucky and everything you need works, but rarely does everything work).  As I have said in other threads, no one should approach armbian for these tv boxes expecting that everything will work (especially wifi and bluetooth - none of my boxes have working wifi or bluetooth) because that is not a reasonable expectation, unless the board manufacturer is supporting their boards by getting code into the mainline kernel.
 
Having said all of that, it wouldn't hurt to try what you reference in the links above, and I suspect it is likely that the 5.6.1 based code would still work on a 5.7 kernel.
 
You should also consider the long term support issues even if you do finally get something working.  You will likely find yourself in the position that at some future point in time when a new kernel update with important security fixes gets pushed out that it is no longer compatible with your custom built driver and then you will need to choose between security of your system or breaking your wifi support.  If you need wifi, I would recommend getting a cheap usb wifi adapter that has mainline kernel support as over the long run that will be best.
 
However if your goal in all of this is to get your solution into future armbian builds (which really means getting it into mainline kernel) then keep hacking away.  But I would suspect that because you have already found a git repository that contains driver code that isn't in the mainline kernel (I am assuming this, but haven't verified), that that path has already been tried by others and rejected (lack of support of the code, poor code quality, or any number of other reasons).

A devicetree is basically a standardized representation of the schematic of a board design. It provides parameters about the components used that drivers need to operate, or tell the kernel which driver to use in the first place. You can only recycle a DT if your device is a exact clone of an original device. Otherwise non matching components won't function properly.
This is not the right way to proceed. This is as if you are using a disassembly of a binary program to rewrite the entire program. When compiling the original sources, information has been lost that cannot be reproduced during disassembly.
The proper way is:
You are the board designer with access to the reference documentation of all used components.
You learn the syntax of DTS files.
You write a board specific DTS with mainline binding documentation as reference.
If your board design is based on e.g. a reference design from an SOC provider, you may be able to use his DTS as a template where you have only to adopt your modifications.
When this is done, contribute it to mainline and it will work for all your customers out of the box. Of course, the kernel build must have enabled all required drivers.
                             
But I guess you are not in this situation So you have to do reverse engineering:
Collect as many board details as possible.
Learn the syntax of DTS files.
Write a board specific DTS with mainline binding documentation as reference.
You can use the original sources of meson-gxl-s905x-khadas-vim.dtb as a template and customize the differences (board model, compatible, Wi-Fi bindings, ...).
Android DTs can only be used for hints, the bindings used are most likely proprietary and do not match those of the mainline kernel. Copying them over will not magically insert code into the kernel drivers to make use them.
When this is done, contribute it to mainline and it will work for all. Armbian will probably pull it for early adoption if you provide a PR, as bringing it to mainline may take some time.

If I interpret the schematics correctly, all LEDs are hardwired to power rails or SATA controller.
So there is no way to change the functionality via software.
The only way to get your desired functionality is to add an additional LED via GPIO pin and apply proper DT configuration.

OK, now that you described your network topology in more detail it is obvious what is going on.
Your router does not connect the WiFi and Ethernet segment in bridged mode but handles them as two separate segments where routing takes place and firewall rules get applied. Ports for service discovery (mdns) and LPR (printer) seem to be enabled already but for ipp-everywere or aiprint (ipp) are not.
With all properly setup and cups-browsed from the cups-filters package running there should be no user intervention be required to add the printer. cups-browsed will discover it, setup a suitable queue and in applications it will show up as printer to use.

If I looked this up correctly from the i.MX 6Solo/6DualLite Applications Processor Reference Manual the VPU has this specs:
HW Decoder: H.264 Profile: BP/CBP/MP/HP Resolution: 1080 i/p, 30 fps Bitrate: 50 Mbps
HW Encoder: H.264 Profile: BP/CBP       Resolution: 1080p, 30 fps    Bitrate: 14 Mbps
As the VPU is a dedicated IP the number of CPU cores does not matter for the codec performance and 1gb should suffice to provide the required buffer allocations for the intermediate frames.
 
Just composed my first transcode pipeline, see transcode-pipeline.pdf for reference. I do not really know what I am doing (google was my friend) and there are so much knobs for configuration and fine tuning so YMMV.
transcode-pipeline.pdf

On imx6q SoC there is:
v4l2-ctl --device=/dev/video0 --all
 v4l2-ctl --device=/dev/video1 --all
v4l2-ctl --device=/dev/video10 --all
/dev/video10 requires at least kernel 5.4.0-rc1 to work out of the box.
                  
gst-inspect-1.0 exposes:
So hardware accelerated video pipelines can be composed in all flavors.