|
|
Subscribe / Log in / New account

Giving Rust a chance for in-kernel codecs

Giving Rust a chance for in-kernel codecs

Posted Apr 29, 2024 16:20 UTC (Mon) by flussence (guest, #85566)
In reply to: Giving Rust a chance for in-kernel codecs by leromarinvit
Parent article: Giving Rust a chance for in-kernel codecs

I see what you're proposing, though that'd be an enormous amount of work. It'd be doing mostly the same thing as the DRM KMS/GBM/TTM/DRI3/etc transition, and although that has delivered solid improvements it's also been an ongoing effort for 20 years now.

With modern media hardware the main obstacle is becoming middle managers desperately trying to put ever more useless buzzword-chasing junk in the devices. Webcam utility plateaus at "looks okay in standard room illumination, provides the functionality of a point and click camera from 2005, does not eat cpu like a winmodem" and anything added past that is fluff and an extra point of failure the driver has to account for, even if nothing in userspace will ever take advantage of it. Sound cards went through the same blight at the turn of the century.


to post comments

Giving Rust a chance for in-kernel codecs

Posted Apr 29, 2024 16:42 UTC (Mon) by farnz (subscriber, #17727) [Link]

I think it's also worth calling out the DMA-BUF UAPI as a prerequisite for change. Without DMA-BUF, the only ways to move data between hardware blocks involve either copies into userspace memory, or having a subsystem-specific mechanism like the V4L2 media controller API to move data around in kernelspace within a single subsystem.

DMA-BUF enables you to export a handle to data to userspace, which can then pass it to a different kernel subsystem. This allows you to elide the copies, and export data from V4L2 to DRM, or from DRM to V4L2.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds