From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Tomasz Figa <tfiga@chromium.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
Daniel Almeida <daniel.almeida@collabora.com>,
Hidenori Kobayashi <hidenorik@chromium.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Sean Young <sean@mess.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Sebastian Fricke <sebastian.fricke@collabora.com>,
Ricardo Ribalda <ribalda@chromium.org>,
Nicolas Dufresne <nicolas.dufresne@collabora.com>
Subject: Re: [ANN] Request for Topics and registration for a Media Summit September 16th
Date: Wed, 12 Jun 2024 23:52:49 +0300 [thread overview]
Message-ID: <20240612205249.GB11102@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20240612224406.41dd88fc@coco.lan>
Hi Mauro,
On Wed, Jun 12, 2024 at 10:44:06PM +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 Jun 2024 11:34:30 +0300 Laurent Pinchart escreveu:
>
> > Focussing on this topic, if we're brainstorming memory management for
> > media devices, I'd like to throw in a controversial idea. In addition to
> > being clearer on the fact that USERPTR is deprecated, I would like to
> > deprecate MMAP too and only focus on DMABUF. I believe Linux needs a
> > centralized buffer allocator, instead of having multiple allocation APIs
> > scattered in different places. There are design ideas in gralloc that we
> > could benefit from.
>
> Deprecating USERPTR is doable, as not many apps use it, and they're
> mostly focused on complex camera/ARM scenario. Now, deprecating MMAP at
> V4L2 core is a different history: lots of different userspace programs,
> including browsers and proprietary apps like zoom, etc. rely on MMAP
> support. We can only consider deprecating MMAP once applications switch
> to DMABUF.
Deprecating doesn't mean dropping it right away, it means telling
application developers that DMABUF is the recommended way. We will still
have to support MMAP for a long time, including fixing bugs in it, as
that will be a long transition. And it first requires solving the
problem of centralizing allocation for DMABUF. It won't happen
overnight, but I'm trying to gather support for the idea, and get people
to collaborate on solving the technical problems that are currently
blocking this long term evolution. If the media subsystem endorsed the
effort, basically saying publicly that we are fine deprecating MMAP in
principle once a good replacement will be available, it may help. I
don't expect the deprecation to happen before at least two years, and
the removal from the kernel would probably take another 10 to 15 years
:-)
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-06-12 20:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 11:33 [ANN] Request for Topics and registration for a Media Summit September 16th Hans Verkuil
2024-05-06 11:40 ` Ricardo Ribalda
2024-05-06 12:31 ` Laurent Pinchart
2024-05-06 13:32 ` Sean Young
2024-05-07 6:40 ` Tommaso Merciai
2024-05-08 7:16 ` Hans Verkuil
2024-05-08 12:19 ` Tommaso Merciai
2024-05-14 16:16 ` Daniel Almeida
2024-06-12 4:12 ` Tomasz Figa
2024-06-12 6:46 ` Hans Verkuil
2024-06-12 7:10 ` Steve Cho
2024-06-12 7:54 ` Mauro Carvalho Chehab
2024-06-12 8:22 ` Tomasz Figa
2024-06-12 8:34 ` Laurent Pinchart
2024-06-12 9:01 ` Tomasz Figa
2024-06-12 9:20 ` Laurent Pinchart
2024-06-12 9:33 ` Tomasz Figa
2024-06-12 9:40 ` Laurent Pinchart
2024-06-12 20:09 ` Nicolas Dufresne
2024-06-12 20:19 ` Laurent Pinchart
2024-06-13 7:17 ` Chen-Yu Tsai
2024-06-12 20:44 ` Mauro Carvalho Chehab
2024-06-12 20:52 ` Laurent Pinchart [this message]
2024-06-13 7:08 ` Hans Verkuil
2024-06-13 9:12 ` Laurent Pinchart
2024-06-13 9:38 ` Hans Verkuil
2024-06-13 9:59 ` Laurent Pinchart
2024-06-12 20:35 ` Mauro Carvalho Chehab
2024-06-13 7:38 ` Hans Verkuil
2024-06-13 8:14 ` Tomasz Figa
2024-06-13 8:35 ` Hans Verkuil
2024-06-13 10:08 ` Laurent Pinchart
2024-06-12 8:06 ` Tomasz Figa
2024-06-12 7:46 ` Laurent Pinchart
2024-05-15 9:32 ` Hans Verkuil
2024-06-04 21:48 ` Steve Cho
2024-06-17 12:43 ` Hans Verkuil
2024-06-19 9:28 ` Tomasz Figa
2024-06-28 11:59 ` Sakari Ailus
2024-07-16 13:11 ` Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240612205249.GB11102@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=daniel.almeida@collabora.com \
--cc=hidenorik@chromium.org \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=ribalda@chromium.org \
--cc=sakari.ailus@linux.intel.com \
--cc=sean@mess.org \
--cc=sebastian.fricke@collabora.com \
--cc=tfiga@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox