cription
>
> v2:
> - Rebased on drm-misc-next
> - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer
> - Incorporate feedback in color_pipeline.rst doc
> - Add support for sRGB inverse EOTF
> - Add 2nd enumerated TF colorop to VKMS
> - Fix LUTs and
Hi Harry,
I applied this patch and the two issues I mentioned before are gone.
I noticed a new problem though: Changes in the COLOR_PIPELINE value
aren't always applied immediately. For testing I played an HDR video
on an SDR screen with the work/zamundaaa/drm-colorop KWin branch, and
made it full
Am Mi., 6. März 2024 um 18:19 Uhr schrieb Mario Limonciello
:
> So the idea being if the compositor isn't using it we let
> power-profiles-daemon (or any other software) take control via sysfs and
> if the compositor does want to control it then it then it writes a DRM
> cap and we destroy the sysf
Like already mentioned in the power profiles daemon repository, I don't think
this makes sense. This is a display setting, which compositors have interest
in controlling, for example to:
- disable it in a bright environment, because afaiu it reduces the maximum
screen brightness
- disable it whe
Am Mi., 19. Juni 2024 um 06:08 Uhr schrieb Mario Limonciello
> Thanks! I don't have permissions, so can you (or someone else) please
> apply to drm-misc-next for me?
>
> After it's merged I'll rebase and work on the feedback for the new IGT
> tests.
Merging can only happen once a real world user
Am Do., 20. Juni 2024 um 22:22 Uhr schrieb Xaver Hugl :
> Merging can only happen once a real world userspace application has
> implemented support for it. I'll try to do that sometime next week in
> KWin
Here's the promised implementation:
https://invent.kde.org/plasma/kwin/-/
Am Mo., 1. Juli 2024 um 21:02 Uhr schrieb Mario Limonciello
:
> Hmm I'm a bit surprised the IGT tests I did didn't catch this.
>
> Are you working on a system with two GPUs by chance (like a Framework
> 16)? If so; can you try the "other GPU"?
No, I tested on a Framework 13.
> As it seems your P
Am Do., 1. Aug. 2024 um 14:34 Uhr schrieb Jani Nikula
:
>
> On Mon, 01 Jul 2024, Xaver Hugl wrote:
> > Am Do., 20. Juni 2024 um 22:22 Uhr schrieb Xaver Hugl
> > :
> >> Merging can only happen once a real world userspace application has
> >> implemented
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
>
> On 5/21/2024 08:43, Simon Ser wrote:
> > 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 t
Am Di., 21. Mai 2024 um 19:28 Uhr schrieb Leo Li :
>
>
>
> On 2024-05-21 12:21, Mario Limonciello wrote:
> > On 5/21/2024 11:14, Xaver Hugl wrote:
> >> Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
> >> :
> >>>
> >>> On 5/2
://gitlab.freedesktop.org/drm/amd/-/issues/3034
Cc: sta...@vger.kernel.org
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display
Sorry, it looks like I sent this too soon. I tested the patch on a
second PC and it doesn't fix the issue there.
Am Do., 7. Dez. 2023 um 19:25 Uhr schrieb Xaver Hugl :
>
> With VRR, every atomic commit affecting a given display must trigger
> a new scanout cycle, so that usersp
Hi,
I tested the patch and it fixes the issue for me too. Consider it
Tested-By Xaver Hugl
- Xaver
Am Mo., 1. Jan. 2024 um 22:37 Uhr schrieb Joshua Ashton :
> From the issue:
>
> ```
> Thank you for for fixing this!
> I built a custom kernel with this patch on the fedora
My plan is to require support for IN_FENCE_FD at least. If the driver
doesn't
allow tearing with that, then tearing just doesn't happen.
For overlay planes though, it depends on how the compositor prioritizes
things.
If the compositor prioritizes overlay planes and would like to do tearing
if poss
Am Mi., 17. Jan. 2024 um 09:55 Uhr schrieb Pekka Paalanen :
> Is it important enough to be special-cased, e.g. to be always allowed
> with async commits?
I thought so, and sent a patch to dri-devel to make it happen, but
there are some
concerns about untested driver paths.
https://lists.freedeskto
Am Mo., 22. Jan. 2024 um 16:50 Uhr schrieb Harry Wentland
:
>
>
>
> On 2024-01-19 13:25, Ville Syrjälä wrote:
> > On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
> >> AMD GPUs can do async flips with changes on more properties than just
> >> the FB ID, so implement a custom check_asy
>
> - Pixel Encoding (RGB vs ycbcr444 vs ycbcr420).
> - Colorspace (YCBCR709 vs BT.2020 etc).
> - Full vs Limited.
>
> However not all options are compatible with everything.
That's not a problem, incompatible options can just be rejected in atomic tests.
> I suspect doing
Am Di., 5. Nov. 2024 um 16:16 Uhr schrieb Matias N. Goldberg
:
>
> > That's not a problem, incompatible options can just be rejected in atomic
> > tests.
>
> I was thinking from a user perspective. It'd be easier for user-space config
> apps to present only the valid options, rather than offering
> It's not the intention of this patch to disable async updates on cursor
> planes... but I don't think it's happening here? Async plane updates and
> async page flips are different things.
Right, these are different code paths. Nevermind then, it's just a bit
confusing.
> Any function that used t
Am Mo., 27. Jan. 2025 um 21:00 Uhr schrieb André Almeida
:
>
> amdgpu can handle async flips on overlay planes, so allow it for atomic
> async checks.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 10 ++
> 1 file changed, 6 insertions(+
> +It is the responsibility of the consumer to make sure that the device or
> +its resources are not in use by any process before attempting recovery.
I'm not convinced this is actually doable in practice, outside of
killing all apps that aren't the one trying to recover the GPU.
Is this just about
Hi,
I experimented with using this in KWin, and
https://invent.kde.org/plasma/kwin/-/merge_requests/7027/diffs?commit_id=6da40f1b9e2bc94615a436de4778880cee16f940
makes it fall back to a software renderer when a rebind is required to
recover the GPU.
Making it also survive the rebind properly is mo
Am Di., 1. Apr. 2025 um 02:29 Uhr schrieb Alex Hung :
>
>
>
> On 3/31/25 12:53, Xaver Hugl wrote:
> >> Cursor plane has no color pipeline and thus it has no colorop either. It
> >> inherits color processing from its parent plane.
> >
> > Just to be
> Cursor plane has no color pipeline and thus it has no colorop either. It
> inherits color processing from its parent plane.
Just to be sure: That means amdgpu will reject atomic commits that try
to set a color pipeline on the primary plane while showing the cursor
plane on top of it? Just like w
> > The 3x4 CTM colorop is not yet explicit on whether it clamps its inputs
> > or outputs. Should all colorops be explicit about it?
> >
>
> Do we expect all HW/drivers to be able to support the same behavior?
> Is this critical to using the colorop?
It doesn't need to be the same on all hardware,
Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
:
>
>
>
> On 5/15/25 15:39, Daniel Stone wrote:
> > Hi,
> >
> > On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> >> On 2025-05-15 13:19, Daniel Stone wrote:
> >>> Yeah, the Weston patches are marching on. We've still been doing a
> >>>
> 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
property - it can just limit the possible values to what it supports,
and
Am Do., 27. März 2025 um 00:58 Uhr schrieb Alex Hung :
>
> It is to be used to enable HDR by allowing userpace to create and pass
> 3D LUTs to kernel and hardware.
>
> new drm_colorop_type: DRM_COLOROP_3D_LUT.
>
> Signed-off-by: Alex Hung
> ---
> v8:
> - Fix typo in subject (Simon Ser)
> - Updat
I have some more concerns / different direction I'd like to go with
this stuff, let's please hold on it for now and talk about it at the
display next hackfest again.
- Xaver
Am Sa., 21. Juni 2025 um 17:27 Uhr schrieb Mario Limonciello
:
>
> From: Mario Limonciello
>
> During the Display Next hac
Looks like a reasonable approach to me. Thanks for following up on it!
I'll look into a KWin implementation soon.
- Xaver
ecide which planes to async flip
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/drm_atomic_uapi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gp
ould break the
> UAPI semantics for those.
>
> Suggested-by: Xaver Hugl
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3034
> Signed-off-by: Michel Dänzer
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 9 +
> 1 file changed, 9 ins
With a timeout of only 1 second, my rx 5700XT fails to initialize,
so this increases the timeout to 2s.
Closes https://gitlab.freedesktop.org/drm/amd/-/issues/3697
Signed-off-by: Xaver Hugl
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 4 ++--
1 file changed, 2
f the plane was and still is not visible.
Fixes: fd40a63c drm/atomic (Let drivers decide which planes to async flip)
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/drm_atomic_uapi.c | 51 +++--
drivers/gp
f the plane was and still is not visible.
Fixes: fd40a63c drm/atomic (Let drivers decide which planes to async flip)
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/drm_atomic_uapi.c | 51 +--
1 file change
> As said in my earlier comment, this new_state->visible is not yet
> populated. It will be viable to have these after atomic_check where
> state->visible gets updated.
> Instead fb can be checked to see if its changed to NULL then it means
> disable the plane and instead of rejecting the change, c
Am Mo., 4. Aug. 2025 um 11:54 Uhr schrieb Murthy, Arun R
:
>
> On 01-08-2025 18:40, Xaver Hugl wrote:
> > It's entirely valid and correct for compositors to include disabled
> > planes in the atomic commit, and doing that should not prevent async
> > flips from work
> It would become mutable only for hardware that supports switching the
> interpolation. It would remain immutable otherwise.
Please let's avoid making (more) properties *sometimes* immutable, it
just makes it easier to use KMS wrong, with no benefits to it.
If a compositor is written against a dri
38 matches
Mail list logo
