mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hsia-Jun Li <Randy.Li@synaptics.com>
To: Simon Ser <contact@emersion.fr>
Cc: dri-devel@lists.freedesktop.org, ayaka@soulik.info,
	linux-kernel@vger.kernel.org, nicolas@ndufresne.ca,
	hverkuil@xs4all.nl, tzimmermann@suse.de, tfiga@chromium.org,
	linux-media@vger.kernel.org
Subject: Re: [RFC] drm/fourcc: Add a modifier for contiguous memory
Date: Tue, 29 Nov 2022 18:46:03 +0800	[thread overview]
Message-ID: <77cee477-6b72-3eb1-487b-33e12d7418ac@synaptics.com> (raw)
In-Reply-To: <sHR1F4GVsLkT7F5iPXtRNZMZ1R_vSHulae_ZqcpUXP6_u3t85f_JnERnKg5Pombd1gDlNi24rBVbeDGK6XddDTzyRPbipWsmRt78DDDl4o0=@emersion.fr>



On 11/29/22 18:18, Simon Ser wrote:
> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Format modifiers are for the buffer layout only, not for the allocation
> parameters, placement, etc. See the doc comment at the top of
> drm_fourcc.h.
In the v4l2 mail list, we have such proposal that dropping the pixel 
formats(not the codec formats) from v4l2 header completely, as the 
growing of tile pixel formats.
But we can't get rid of those variants about non-contiguous(the same 
value FOURCC in v4l2 are all for the contiguous memory).

Before I solve this problem, I believe the support for tile formats in 
v4l2 would never be stable.

The most common way here is to hack the pixel format modifier, then 
userspace library could be aware this in allocation and get properties 
of the drm_planes.

Or another way, we could add a common plane property, indicated that 
whether the driver requests contiguous memory plane for a format?
-- 
Hsia-Jun(Randy) Li

  reply	other threads:[~2022-11-29 10:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-29 10:10 Hsia-Jun Li
2022-11-29 10:18 ` Simon Ser
2022-11-29 10:46   ` Hsia-Jun Li [this message]
2022-11-29 10:42 ` Daniel Stone
2022-11-29 10:57   ` Hsia-Jun Li
2022-11-29 10:48 ` Pekka Paalanen

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=77cee477-6b72-3eb1-487b-33e12d7418ac@synaptics.com \
    --to=randy.li@synaptics.com \
    --cc=ayaka@soulik.info \
    --cc=contact@emersion.fr \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=tfiga@chromium.org \
    --cc=tzimmermann@suse.de \
    /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

all inboxes | Powered by JetHome®