Giving Rust a chance for in-kernel codecs

DRM/KMS drivers is clearly another option and an option that I keep an eye on for the future. For me, V4L2 uAPI choice was made before my time and it does work well enough. But in DRM/KMS subsystem, the notion of scheduling work from various user process onto a certain set of fixed function cores is already solved. And this is exactly what modern stateless codecs are becoming. Rasperry Pi HEVC decoders process two task concurrently (entropy decoding and reconstruction). Mediatek VCODEC do that same, but with two independent cores. Rockchip 3588 have quad core jpeg decoders, but also dual core HEVC decoders were you can use both independently or bind the cores to process 8K frames. This in V4L2 framework is a true challenge and huge gap for which DRM/KMS do have solution for.

Of course, the validation is still mandatory, but we can easily design a common command bitstream for this type of hardware, and then internally validate and reconstruct a validated command that is simply the register layout in RAM that can be used by the scheduler to applied. Might be a steep dive, but what I'm saying is that DRM/KMS is a very viable solution for future CODEC and may help fixing all the legacy and short coming of V4L2 uAPI and hopefully support Vulkan Video on this type of hardware.