A Push Towards Firmware-less Video Decoding By Linux Kernel Media Drivers

[phoronix]

Phoronix: A Push Towards Firmware-less Video Decoding By Linux Kernel Media Drivers

Veteran Linux multimedia developer Paul Kocialkowski summed up the current situation this week of many hardware platforms having a general purpose micro-controller running a non-free firmware blob for coordinating the video decoding work. It makes it easier to program with this firmware-based approach but makes the driver less free and now with recent Linux infrastructure improvements could better support dealing with the video hardware itself...

http://www.phoronix.com/scan.php?page=news_item&px=Firmware-Video-Decoding-Concern

[R41N3R]

I would love to see more of the firmware blobs getting replaced with proper kernel support. After all the security flaws especially from Intel I really distrust these blobs. Not to mention the UEFI blob we are all forced to use and trust.

[c117152]

Previous attempts failed over DRM... Not sure what's different now.

[SystemCrasher]

Unfortunately same problem happens in other places as well, e.g. GPUs. Somehow it partially negates opensource efforts, since at the end of day firmwares grow rather large, full of bugs, do not play well with Linux and there is no realistic way to fix it. I guess that's what kept Libv unhappy about AMD way of doing things...

World of hardware needs a decent kick, a reboot, to become more opensource friendly. HW like this is opensource-unfriendly to say the least, if not backdoored in worst case, as seen with ME/PSP/etc.

[LoveRPi]

Opening encoding and decoding firmware will land a lot of companies in the middle of a patent minefield. The current way is done out of necessity, not convenience.

[zoomblab]

I am not a kernel developer. I understand that this proposal wants to put functionalities in the kernel that are already offered from the hardware and are abstracted through the firmware? That will make kernel source code more complex and harder to maintain. But what worries me most is the break of abstraction from an architectual POV. That functionality offered by the hardware has a reason to be there. It serves abstraction over various OSes and we want to bypass that.

This reminds me of the diference between radeonhd and radeon. RadeonHD went the direct programming way which had the disadvantages I mentioned above. It is obvious that AMD didn't like that approach and I wouldn't too.

[Adarion]

And I was already thinking we had a FOSS solution for UVD, VCE and the likes. Ah well, but some kind of framework/infrastructure is already a start.
It might be easier in the beginning to use FW approaches to get a driver set up quickly, but on long term a FOSS implementation will be better. History has shown numerous times that blobs will also have issues, security leaks, even backdoors and the likes and some tend to get updated... never. So a fully free operation would mean (possibly) better security, more trust and less bugs.
Of course, initial efforts to write drivers would be elevated.