On Friday, August 1st, 2025 at 00:12, Nícolas "F. R. A. Prado"
wrote:
> This function implies it only cleans up the colorops in the color
> pipeline of a specific plane, but it actually cleans up all colorops in
> the drm_mode_config of a device.
Good catch! Would make more sense to take a drm_
On Saturday, August 2nd, 2025 at 03:49, Alex Hung wrote:
> It may be better to change it now if we know it needs changing in the
> future.
It would become mutable only for hardware that supports switching the
interpolation. It would remain immutable otherwise.
Immutable is an indication that us
On Tuesday, June 17th, 2025 at 06:27, Alex Hung wrote:
> - 1D LUT is no longer immutable (Xaver Hugl)
I think we should keep it immutable for now, and we can make it mutable
in the future when we want to extend the uAPI to make it switchable by
user-space.
On Tuesday, June 17th, 2025 at 06:26, Alex Hung wrote:
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 651bdf48b766..21bd96f437e0 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -872,6 +872,16 @@ struct drm_color_lut {
> _
On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
wrote:
> > > What we should
> > > do is reject YCbCr-type buffers with the color pipeline until we
> > > implement support for COLOR_ENCODING and COLOR_RANGE as a new
> > > CSC colorop.
> >
> > Rejecting is fine, but is implementing COLOR_ENC
On Wednesday, May 21st, 2025 at 21:18, Harry Wentland
wrote:
> On 2025-05-20 16:13, Harry Wentland wrote:
>
> > On 2025-05-19 19:43, Simon Ser wrote:
> >
> > > On Sunday, May 18th, 2025 at 00:32, Xaver Hugl xaver.h...@gmail.com wrote:
> > >
> > >
On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote:
> > We can always make the property mutable on drivers that support it in
>
> > the future, much like the zpos property. I think we should keep it
> > immutable for now.
>
> Sure, but I don't see any reason for immutability with an enum
> pr
On Saturday, May 17th, 2025 at 03:23, Xaver Hugl wrote:
> Do we ever expect this to be something with multiple options that
> userspace could select? I think it would be good to keep our options
> open and make this property not immutable (properties that are
> sometimes but not always immutable
On Thursday, May 15th, 2025 at 16:11, Harry Wentland
wrote:
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver had a prototype in kwin.
Cool!
> Ideally we'd have gamescope adopt it and switch off
I've reviewed all of the core DRM patches :)
Have there been updates from user-space implementations?
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
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
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
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 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
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
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
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
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
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
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
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
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 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.
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.
Looks good to me as well, thank you!
Reviewed-by: Simon Ser
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
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, 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
> Do we really need this much flexibility, especially for the first driver
> adding the first few additional properties?
AFAIU we'd like to allow more props as well, e.g. cursor position…
Thanks! This iteration of the first 3 patches LGTM, I've pushed them to
drm-misc-next. I've made two adjustments to make checkpatch.pl happy:
- s/uint64_t/u64/
- Fix indentation for a drm_dbg_atomic()
It seems like commits were re-ordered at some point. I think we need "drm:
introduce drm_mode_config.atomic_async_page_flip_not_supported" to come before
"drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits" because the latter
uses atomic_async_page_flip_not_supported. Similarly, "drm: Refuse to
On Monday, November 13th, 2023 at 11:15, Pekka Paalanen
wrote:
>
>
> On Mon, 13 Nov 2023 09:44:15 +0000
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, November 13th, 2023 at 10:38, Pekka Paalanen ppaala...@gmail.com
> > wrote:
> >
> &g
On Monday, November 13th, 2023 at 10:41, Michel Dänzer
wrote:
> On 11/13/23 10:18, Simon Ser wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > > > > > > > +An atomic commit with the
On Monday, November 13th, 2023 at 10:38, Pekka Paalanen
wrote:
> On Mon, 13 Nov 2023 09:18:39 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
> >
> > > > > > >
On Monday, October 23rd, 2023 at 10:25, Simon Ser wrote:
> > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is
> > > > > > > > > > allowed to
> > > > > > > > > > +effective
On Monday, October 23rd, 2023 at 10:42, Michel Dänzer
wrote:
> On 10/23/23 10:27, Simon Ser wrote:
>
> > On Sunday, October 22nd, 2023 at 12:12, Michel Dänzer
> > michel.daen...@mailbox.org wrote:
> >
> > > On 10/17/23 14:16, Simon Ser wrote:
> > &g
On Sunday, October 22nd, 2023 at 12:12, Michel Dänzer
wrote:
> On 10/17/23 14:16, Simon Ser wrote:
>
> > After discussing with André it seems like we missed a plane type check
> > here. We need to make sure FB_ID changes are only allowed on primary
> > planes.
>
>
On Tuesday, October 17th, 2023 at 14:10, Ville Syrjälä
wrote:
> On Mon, Oct 16, 2023 at 10:00:51PM +0000, Simon Ser wrote:
>
> > On Monday, October 16th, 2023 at 17:10, Ville Syrjälä
> > ville.syrj...@linux.intel.com wrote:
> >
> > > On Mon, Oct 16, 2023 at
After discussing with André it seems like we missed a plane type check
here. We need to make sure FB_ID changes are only allowed on primary
planes.
Reviewed-by: Simon Ser
On Monday, October 16th, 2023 at 17:10, Ville Syrjälä
wrote:
> On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote:
>
> > On Mon, 16 Oct 2023 15:42:16 +0200
> > André Almeida andrealm...@igalia.com wrote:
> >
> > > Hi Pekka,
> > >
> > > On 10/16/23 14:18, Pekka Paalanen wrote:
> >
On Tuesday, August 15th, 2023 at 20:57, André Almeida
wrote:
> Given that prop changes may lead to modesetting, which would defeat the
> fast path of the async flip, refuse any atomic prop change for async
> flips in atomic API. The only exceptions are the framebuffer ID to flip
> to and the mod
On Thursday, August 17th, 2023 at 21:33, Dmitry Baryshkov
wrote:
> We have been looking for a way to document that the corresponding DP
> port is represented by the USB connector on the device.
>
> Consequently, I believe the best way to document it, would be to use
> DisplayPort / USB, when th
On Thursday, August 17th, 2023 at 15:46, Harry Wentland
wrote:
> On 2023-08-17 09:44, Harry Wentland wrote:
>
> > On 2023-08-17 06:53, Simon Ser wrote:
> >
> > > The commit 1347385fe187 ("drm/amd/display: don't expose rotation
> > > prop for cu
Allow user-space to use the cursor plane with a rotated underlying
plane under the condition that both planes have the same rotation.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Michel Dänzer
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
We don't want a semi-transparent overlay to make the cursor plane
semi-transparent as well. Same for the pixel blend mode.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Michel Dänzer
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
if the primary plane is rotated, then the cursor plane
will incorrectly be rotated as well even though it doesn't have a
rotation property.
To fix this, check that the underlying plane isn't rotated.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazl
supported.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Cc: Michel Dänzer
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/g
Changes in v3: rebase, split cursor rotation patch into 2.
Simon Ser (4):
amd/display: add cursor check for YUV underlying pipe
amd/display: add cursor alpha and blend mode checks
amd/display: add cursor rotation check
amd/display: re-introduce cursor plane rotation prop
.../gpu/drm/amd
On Thursday, August 3rd, 2023 at 22:44, Laurent Pinchart
wrote:
> On Thu, Aug 03, 2023 at 03:31:16PM +0000, Simon Ser wrote:
>
> > On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr wrote:
> >
> > > The KMS docs describe "subconnector&qu
On Thursday, August 3rd, 2023 at 17:36, Dmitry Baryshkov
wrote:
> On Thu, 3 Aug 2023 at 18:31, Simon Ser cont...@emersion.fr wrote:
>
> > On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr wrote:
> >
> > > The KMS docs describe "subconnect
1 - 100 of 303 matches
Mail list logo
