Re: [ANN] Media Summit on May 26th in Nice, France

[Paul Kocialkowski <paulk@sys-base.io>]

[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]

Hi,

On Mon 02 Mar 26, 15:01, Laurent Pinchart wrote:
> On Mon, Mar 02, 2026 at 08:55:05AM -0500, Nicolas Dufresne wrote:
> > Le dimanche 01 mars 2026 à 16:02 +0100, Laurent Pinchart a écrit :
> > > I would also like to revive efforts to properly support dmabuf import
> > > for multi-planar formats with configurable plane offsets (a.k.a. data
> > > offsets), but I think this requires a champion to resume the work more
> > > than a discussion at the media summit.
> > 
> > I haven't sent my RFC yet about that subject, that will probably be after
> > Embedded World. But I think it can serve as example of "possible" way forward.
> > And I believe the ChromeOS request should be cited. I think we need more then a
> > champion to resume the work, since I personally don't believe in the ancient
> > proposal from Collabora. I'd say plan for a little more time on this subject.
> 
> Maybe it could then make sense to brainstorm the topic during the media
> summit.

I'm also interested in the topic and had a first go at it a few months back,
with code at: https://git.paulk.fr/projects/linux.git/log/?h=media/dmabuf-offset

This is based on our discussions on IRC, with the main concern that hardware
units may have specific alignment constraints that apply, so not all offsets
are valid and drivers need to provide their alignment constraints. So the
feature is disabled by default and drivers that want to support it need to
provide their alignment constraint. It is then reported to userspace via
create_buffers and a new flag is added to indicate that the driver supports
the feature.

Then it comes down to adding the offset down to videobuf2, which is
straightforward in some cases (that I implemented) and less so in others, like
sg tables (which I didn't implement).

So it feels like more work would be needed to get the vb2 side right.

Nicolas, did you have another approach in mind or is your RFC based on the same
ideas?

> > If possible, I would like to add to the agenda a short update related to Vulkan
> > Video side of CODECs, what are the viable options for Linux Media and what is in
> > preparation outside of our subsystem. The second aspect is informative as these
> > discussion don't seem to lean toward our subsystem as the foundation. But I
> > think its rather useful for everyone to understand why and what is included.
> 
> I'd be interested in hearing about that.

Yes me too. I guess this more or less boils down to the long-time debate of
generic uAPI with complexity in the kernel vs driver-specific uAPI with
complexity in userspace. I still think a generic uAPI for codecs makes good
sense, but I understand the appeal of something more similar to drm accel.

All the best,

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]