age (Pekka)
Signed-off-by: Simon Ser
Cc: Simona Vetter
Cc: Ville Syrjälä
Cc: Pekka Paalanen
Cc: David Turner
Cc: Daniel Stone
---
include/uapi/drm/drm_mode.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index c0
Note, I just noticed I wrote an earlier (less precise) version of this
patch here, which I completely forgot about:
https://patchwork.freedesktop.org/patch/546972/
Ah, sorry, I missed this message.
On Monday, April 14th, 2025 at 15:28, Ville Syrjälä
wrote:
> Should probably add a caveat that this needs to be a sync commit/flip.
> The way the async flip was specified for atomic explicitly requires the
> driver to ignore the plane when the fb doesn't change
Pushed, thanks!
On Monday, April 14th, 2025 at 13:06, Pekka Paalanen
wrote:
> Looking good, but given the new wording is 100% mine, not sure I can
> give reviewed-by?
>
> Co-authored-by maybe?
Since it's 100% yours, probably you should be the commit author? Would
you mind giving a S-o-b as well?
But I wonder
On Tuesday, April 15th, 2025 at 13:12, Borah, Chaitanya Kumar
wrote:
> On 4/8/2025 10:10 PM, Daniel Stone wrote:
>
> > As it stands, I've gone through the implementation pretty thoroughly,
> > as well as our use of it in Weston. I'm happy with how it looks for
> > pre-blend, and I'm even happie
On Tuesday, April 15th, 2025 at 17:05, Harry Wentland
wrote:
> > > > We want to have just one change in the way we expose the hardware
> > > > capabilities else all looks good in general.
> > >
> > > I would really recommend leaving this as a follow-up extension. It's a
> > > complicated
> > >
On Tuesday, April 15th, 2025 at 08:09, Shankar, Uma
wrote:
> We want to have just one change in the way we expose the hardware
> capabilities else
> all looks good in general.
I would really recommend leaving this as a follow-up extension. It's a
complicated addition that requires more discuss
Explain how to perform front-buffer rendering.
v2: apply Pekka's rewrite
Signed-off-by: Simon Ser
Cc: Pekka Paalanen
Cc: Simona Vetter
---
drivers/gpu/drm/drm_blend.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
On Thursday, July 13th, 2023 at 10:23, Pekka Paalanen
wrote:
> > + * To perform front-buffer rendering, user-space should set FB_ID to the
> > + * previous framebuffer in atomic commits.
> > * CRTC_ID:
> > * Mode object ID of the &drm_crtc this plane should be connected to.
> > *
>
> It's uncle
On Friday, January 17th, 2025 at 12:15, Pekka Paalanen
wrote:
> On Thu, 16 Jan 2025 16:25:35 +
> Simon Ser cont...@emersion.fr wrote:
>
> > It's not obvious off-hand which CRTCs will get a page-flip event
> > when using this flag in an atomic commit, because it&#x
On Tuesday, April 1st, 2025 at 04:42, Alex Hung wrote:
> On 3/29/25 09:48, Simon Ser wrote:
>
> > I would prefer these functions to be introduced together with the
> > patches adding functions to create objects and adding the new fields.
> > That way it's easier to
On Tuesday, April 8th, 2025 at 18:40, Daniel Stone wrote:
> > > 5. For a given colorop property, is it an invariant that the colorop
> > > will only appear in one color pipeline at a time? (I believe so, but
> > > this probably needs documenting and/or igt.)
> >
> > I don't really understand why
um, but
(1) who knows what/how distros might end up cherry-picking (2) future
patches might take inspiration from this one.
With that fixed:
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
On Tuesday, April 1st, 2025 at 17:14, Daniel Stone wrote:
>
>
> Hi Alex,
>
> On Wed, 26 Mar 2025 at 23:50, Alex Hung alex.h...@amd.com wrote:
>
> > +static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
> > *colorop,
> > + struct drm_plane *plane, enum drm_colorop_type
On Tuesday, April 1st, 2025 at 02:10, Alex Hung wrote:
> On 3/29/25 09:26, Simon Ser wrote:
>
> > I would also highlight that we need to seamlessly switch between HW
> > fixed-function blocks and shaders/CPU with no visible difference. Depending
> > on
> > the co
I would prefer these functions to be introduced together with the
patches adding functions to create objects and adding the new fields.
That way it's easier to check the symmetry and at no point in the
series there are memory leaks.
Additionally, I would avoid using the name "cleanup", which seems
Reviewed-by: Simon Ser
Thanks a lot for sending the updated series, Alex! I've looked at all
of the core DRM patches and they all look pretty close to being R-b'ed.
I don't think I'd have time to look at vkms or amdgpu patches. Let me
know if I missed anything!
Simon
I'm personally not a fan of such boolean function arguments, especially
when caller and callee are far apart. From the caller side, the meaning
of the boolean argument is not immediately clear.
I would prefer a "flags" argument, which can take a e.g.
DRM_COLOROP_FLAG_ALLOW_BYPASS value.
But I'm n
Reviewed-by: Simon Ser
Thanks a lot for these docs, very well written. I especially like the
"Driver Implementer's Guide" section.
A few minor comments below, regardless:
Reviewed-by: Simon Ser
> +What problem are we solving?
> +
> +
> +We would like to supp
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Two nits below, regardless:
Reviewed-by: Simon Ser
> + } else if (property == plane->color_pipeline_property) {
> + /* find DRM colorop object */
> + struct drm_colorop *colorop = NULL;
> +
> + colorop = drm_colorop_find(d
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
On Tuesday, February 25th, 2025 at 15:43, Harry Wentland
wrote:
> > > We need to be a bit careful when merging patches from the same series
> > > via multiple trees. Maybe we'll merge the colorop stuff via the amd
> > > tree? I don't remember the rules around trees, and I don't know if it
> > >
On Tuesday, February 25th, 2025 at 10:37, Louis Chauvet
wrote:
> Can I extract this patch from the series and apply it on drm-misc-next?
That sounds completely fine by me, and TBH it sounds like it could even
be drm-misc-fixes material?
We need to be a bit careful when merging patches from the
On Friday, February 21st, 2025 at 19:41, Harry Wentland
wrote:
> > Other people have argued that strings make it easier for user-space to
> > start using a new KMS property without deploying new kernel uAPI headers.
>
> I don't understand this argument. You would either need to define the
> str
On Friday, February 21st, 2025 at 17:18, Harry Wentland
wrote:
> I did a brief survey of other enum properties and noticed
> that this isn't well documented for others, such as the Content
> Protection connector property, or the COLOR_RANGE and COLOR_ENCODING
> plane properties.
Isn't the Conte
On Monday, February 10th, 2025 at 23:03, Harry Wentland
wrote:
> > > + * DOC: overview
> > > + *
> > > + * A colorop represents a single color operation. Colorops are chained
> > > + * via the NEXT property and make up color pipelines. Color pipelines
> > > + * are advertised and selected via th
On Thursday, January 23rd, 2025 at 21:06, Harry Wentland
wrote:
> On 2025-01-15 03:00, Simon Ser wrote:
>
> > Is this 125 magic number something we can expect other hardware to
> > implement as well?
>
> It's based on MS's CCCS interpretation of 80 nits as 1.
On Wednesday, January 22nd, 2025 at 22:05, Harry Wentland
wrote:
> On 2025-01-15 02:56, Simon Ser wrote:
>
> > Is this "ignore" something we could do at the core DRM level, instead
> > of doing it in all drivers? e.g. by silently ignoring user-space requests
>
On Wednesday, January 22nd, 2025 at 20:48, Harry Wentland
wrote:
> On 2025-01-13 13:23, Simon Ser wrote:
>
> > > v4:
> > > - Don't block setting of COLOR_RANGE and COLOR_ENCODING
> > > when client cap is set
> >
> > Can you remind me why the
Some minor comments below, apart from that looks good!
Typo in the commit title: s/supports/support/
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5ef87cb5b242..316c643e0dea 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -913
Reviewed-by: Simon Ser
On Friday, January 17th, 2025 at 00:33, Alex Hung wrote:
> On 1/15/25 01:14, Simon Ser wrote:
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index a3e1fcad47ad..4744c12e429d 100644
> >> --- a/drivers/gpu/d
On Friday, January 17th, 2025 at 12:32, Ville Syrjälä
wrote:
> > + * When used with atomic uAPI, one event will be delivered per CRTC
> > included in
> > + * the atomic commit. A CRTC is included in an atomic commit if one of its
> > + * properties is set, or if a property is set on a connector
ight after
drm_atomic_set_property() calls, page-flip events are not delivered
for CRTCs pulled in later by DRM core (e.g. on modeset by
drm_atomic_helper_check_modeset()) or the driver (e.g. other CRTCs
sharing a DP-MST connector).
Signed-off-by: Simon Ser
Cc: Simona Vetter
Cc: Ville Syrjälä
Cc: Pekka Pa
Reviewed-by: Simon Ser
> + prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "SIZE",
Ah, I forgot something: I think this needs to be DRM_MODE_PROP_ATOMIC?
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a3e1fcad47ad..4744c12e429d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -701,6 +701,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_col
> The BT.709 and BT.2020 OETFs are the same, the only difference
> being that the BT.2020 variant is defined with more precision
> for 10 and 12-bit per color encodings.
Just to make sure, the spec defines this precision, correct? It's
not an AMD-specific thing?
> Both are used as encoding functi
Is this 125 magic number something we can expect other hardware to
implement as well?
Could AMD use the HDR multiplier or another block to behave as if
the multiplier didn't exist?
Note, I am no HDR expert. Maybe others have a better idea whether this
makes sense or not.
Is this "ignore" something we could do at the core DRM level, instead
of doing it in all drivers? e.g. by silently ignoring user-space requests
to set the property?
It sounds like this codepath still resets the colorspace to sRGB, which
is later overwritten by colorops pulled in the atomic state a
Reviewed-by: Simon Ser
> v4:
> - Don't block setting of COLOR_RANGE and COLOR_ENCODING
>when client cap is set
Can you remind me why these should not be blocked?
We should also add doc comments in the color_range and color_encoding fields,
to document that drivers should ignore these fields when the cap is set.
Two nits below, regardless:
Reviewed-by: Simon Ser
> +static int drm_colorop_create_data_prop(struct drm_device *dev, struct
> drm_colorop *colorop)
> +{
> + struct drm_property *prop;
> +
> + /* data */
> + prop = drm_property_create(dev,
> +int
> +drm_atomic_add_affected_colorops(struct drm_atomic_state *state,
> + struct drm_plane *plane)
> +{
> + struct drm_colorop *colorop;
> + struct drm_colorop_state *colorop_state;
> +
> + WARN_ON(!drm_atomic_get_new_plane_state(state, plane));
> +
> +
> +static void drm_atomic_colorop_print_state(struct drm_printer *p,
> + const struct drm_colorop_state *state)
> +{
> + struct drm_colorop *colorop = state->colorop;
> +
> + drm_printf(p, "colorop[%u]:\n", colorop->base.id);
> + drm_printf(p, "\ttype=%s\n", drm_get_colorop_
> +void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
> drm_colorop *next)
> +{
> + if (!colorop->next_property)
> + return;
Why is this early return necessary? Shouldn't this field be always
populated?
Even if that's not the case, I don't think silently ignor
Reviewed-by: Simon Ser
This patch should probably come after all patches introducing the
properties referenced in the docs, e.g. NEXT and COLOR_PIPELINE.
Probably after "[13/45] drm/colorop: Introduce
DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE"?
> +/**
> + * DOC: overview
> + *
> + * A colorop represents a single color operati
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Acked-by: Simon Ser
On Tuesday, August 20th, 2024 at 22:27, Simon Ser wrote:
> Sorry for the huge delay. Generally this looks good but maybe we
> could explain a bit more what "bottom up" means exactly since it
> may not be super obvious.
>
> Maybe something among these lines?
>
>
On Tuesday, October 15th, 2024 at 12:47, Michel Dänzer
wrote:
> On 2024-10-13 15:34, Simon Ser wrote:
>
> > This is a flag to opt-out of the automagic buffer migration to
> > system memory when importing a DMA-BUF.
> >
> > In multi-GPU scenarii, a Waylan
On Thursday, October 3rd, 2024 at 22:01, Harry Wentland
wrote:
> From: Alex Hung
>
> It is to be used to enable HDR by allowing userpace to create and pass
> 3D LUTs to kernel and hardware.
>
> 1. new drm_colorop_type: DRM_COLOROP_3D_LUT.
> 2. 3D LUT modes define hardware capabilities to user
On Sunday, October 13th, 2024 at 17:19, Simon Ser wrote:
> Would be nice to have user-space uAPI docs for the colorop properties.
> Just like we have for other KMS object types:
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
Ah, I suppose s
Would be nice to have user-space uAPI docs for the colorop properties.
Just like we have for other KMS object types:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
Internal kernel docs aren't great for user-space developers, because
user-space developers have n
I think this can be folded into "drm/colorop: Add atomic state print for
drm_colorop".
Shouldn't this patch come before the others, otherwise we're exposing
unconditionally color OP uAPI to user-space in-between the first patch
and this one?
Usually we try to not have a broken kernel in intermediate commits. It's
important for bisecting.
API addition make sense to you? If so, do you
see a better way to plumb it in the DMA-BUF framework?
Signed-off-by: Simon Ser
Cc: Sumit Semwal
Cc: Christian König
Cc: Daniel Stone
Cc: Victoria Brekenfeld
Cc: Michel Dänzer
Cc: Xaver Hugl
Cc: Simona Vetter
Cc: Austin Shafer
Oh well, if AMD modifiers are documented via "read Mesa source code",
then I'll just leave everything as-is and libdrm/drm_info/drmdb will
just print "who knows" instead of something actually useful when hitting
such modifiers. Sorry, I have no more free time to donate here.
Sorry for the huge delay. Generally this looks good but maybe we
could explain a bit more what "bottom up" means exactly since it
may not be super obvious.
Maybe something among these lines?
Bottom up means that the first CRTCs in the array should be used
first. For instance, if the drive
y for FB_ID on the
primary plane (instead of skipping for FB_ID on any plane).
Fixes: 0e26cc72c71c ("drm: Refuse to async flip with atomic prop changes")
Signed-off-by: Simon Ser
Reviewed-by: André Almeida
Tested-by: Xaver Hugl
Cc: Alex Deucher
Cc: Christian König
Cc: Michel Dänzer
Cc
I've pushed both patches to drm-misc-fixes, thanks!
I've added a Fixes trailer accordingly.
I'll rebase my patch on top of these two.
the gfx12 modifiers that Mesa exposes.
The modifier u64 bit layout is not supposed to be "Mesa-specific".
It's shared by multiple userspace components. It needs to be defined
properly in drm_fourcc.h.
Please, can you read my questions and answer them?
> From: Simon Ser
> Sent
Looks good to me as well, thank you!
Reviewed-by: Simon Ser
and easy to get wrong.
> From: Alex Deucher
> Sent: July 1, 2024 13:09
> To: Simon Ser ; Olsak, Marek
> Cc: Pillai, Aurabindo ; DRI Development
> ; Siqueira, Rodrigo
> ; Deucher, Alexander ;
> Bas Nieuwenhuizen
> Subject: Re: AMD GFX12 modifiers
>
> + Marek
&
Hi all!
In 7ceb94e87bff ("drm/amd: Add gfx12 swizzle mode defs"), some
definitions were added for GFX12 modifiers. However I'm not quite sure
I understand how these work.
Tile values seem to not be in the same namespace as GFX9 through GFX11,
is that correct? In other words, can GFX9 ~ GFX11 modi
BTW, should we allow OUT_FENCE_PTR as well? Would that work as expected
with async flips?
you mind sending a patch for FB_DAMAGE_CLIPS as well?
Reviewed-by: Simon Ser
y for FB_ID on the
primary plane (instead of skipping for FB_ID on any plane).
Fixes: 0e26cc72c71c ("drm: Refuse to async flip with atomic prop changes")
Signed-off-by: Simon Ser
Cc: André Almeida
Cc: Alex Deucher
Cc: Christian König
Cc: Michel Dänzer
Cc: Ville Syrjälä
---
.
ci: upgrade debian container to bookworm
ci: upgrade FreeBSD VM to 14.1
Nicolas Caramelli (1):
Remove libm in libdrm dependencies
Simon Ser (2):
Sync headers with drm-next
build: bump version to 2.4.122
git tag: libdrm-2.4.122
https://dri.freedesktop.org/libdrm/libdrm
On Thursday, February 29th, 2024 at 11:52, Daniel Vetter
wrote:
> I think some weston (or whatever compositor you like) config file support
> to set a bunch of "really only way to configure is by hand" output
> properties would clear the bar here for me. Because that is a feature I
> already men
On Wednesday, May 22nd, 2024 at 15:36, Mario Limonciello
wrote:
> > To be perfectly honest with you, I haven't given that much though. I
> > used the 'bpc' and 'colorspace' property in debugfs, since I could not
> > find that information anywhere else. And since I also needed to verify
> > the p
On Tuesday, May 21st, 2024 at 19:27, Leo Li wrote:
> I wonder if flags would work better than enums? A compositor can set something
> like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example.
(FWIW, the KMS uAPI has first-class support for bitfields.)
This makes sense to me in general. I like the fact that it's simple and
vendor-neutral.
Do we want to hardcode "panel" in the name? Are we sure that this will
ever only apply to panels?
Do we want to use a name which reflects the intent, rather than the
mechanism? In other words, something like "
On Tuesday, May 14th, 2024 at 22:42, Laurent Pinchart
wrote:
> My experience on Arm platforms is that the KMS drivers offer allocation
> for scanout buffers, not render buffers, and mostly using the dumb
> allocator API. If the KMS device can scan out YUV natively, YUV buffer
> allocation should
On Wednesday, May 8th, 2024 at 17:49, Daniel Vetter wrote:
> On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
>
> > On Wed, 8 May 2024 at 09:33, Daniel Vetter dan...@ffwll.ch wrote:
> >
> > > On Wed, May 08, 2024 at 06:46:53AM +0100, Daniel Stone wrote:
> > >
> > > > That would ha
Sounds good to me.
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
>
> Stop printing the driver date at init, and start returning the empty
> string "" as driver date through the DRM_IOCTL_VERSION ioctl.
Sounds good to me.
Acked-by: Simon Ser
BTW, I wonder if the driver version number (major/minor/patch) is useful?
Do drivers update it?
On Monday, April 22nd, 2024 at 10:58, Ville Syrjala
wrote:
> drm_color_ctm_3x4 is some undocumented amgdpu private
> uapi and thus has no business being in drm_mode.h.
> At least move it to some amdgpu specific header, albeit
> with the wrong namespace as maybe something somewhere
> is using thi
On Thursday, March 28th, 2024 at 19:47, Rob Clark wrote:
> any chance I could talk you into pushing to drm-misc-fixes?
Oh sorry, I thought you had access… Pushed with a minor edit to remove
unnecessary parentheses to make checkpatch happy!
Makes sense to me!
Reviewed-by: Simon Ser
Note, the kernel already sends synthetic page-flip events when a CRTC goes
from on → off. I think it would make sense to do the same for all pending
page-flips before the device is destroyed in the kernel.
On Tuesday, March 12th, 2024 at 16:02, Pekka Paalanen
wrote:
> This list here is the list of all values the enum could take, right?
> Should it not be just the one value it's going to have? It'll never
> change, and it can never be changed.
Listing all possible values is how other properties be
On Monday, March 4th, 2024 at 15:04, Garg, Nemesa wrote:
> This is generic as sharpness effect is applied post blending. Depending
> on the color gamut, pixel format and other inputs the image gets
> blended and once we get blended output it can be sharpened based on
> strength value provided by
Reviewed-by: Simon Ser
On Wednesday, February 28th, 2024 at 17:14, Maxime Ripard
wrote:
> > I don't know what the rules were 8 years ago, but the current uAPI rules
> > are what they are, and a new enum entry is new uAPI.
>
> TBF, and even if the wayland compositors support is missing, this
> property is perfectly us
ical hardware (Pekka)
> v4: Update the docs to indicate the list is "in order of preference"
> Add a a link to the mutter MR
>
> Cc: Simon Ser
> Cc: Jonas Ådahl
> Cc: Daniel Stone
> Cc: Sameer Lattannavar
> Cc: Sebastian Wick
> Acked-by: Harry Wen
On Monday, February 26th, 2024 at 18:23, Dave Stevenson
wrote:
> You want the commit text for a patch adding a new enum to state that
> the whole property isn't expected to be used through the UAPI? OK, I
> can roll a v2 if that is your desire.
By definition, anything new exposed by the kernel
Reviewed-by: Simon Ser
Pushed to drm-misc-fixes with two minor edits to make scripts/checkpatch.pl
happy (commit reference cut off a final dot, and comment needs "*/" on its own
line).
1 - 100 of 988 matches
Mail list logo
