I can't say anything about the other commits in this series, but
"Document in which order the CTM matrix elements are stored" is
Reviewed-by: Xaver Hugl
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
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., 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
quest them, no matter what -
and if that is not possible or desirable, uAPI has to be changed, for
example by introducing the mentioned "pageflip failed" event.
Looking forward to some answers,
Xaver Hugl
Am Fr., 27. Okt. 2023 um 12:01 Uhr schrieb Sebastian Wick <
sebastian.w...@redhat.com>:
> On Fri, Oct 27, 2023 at 10:59:25AM +0200, Michel Dänzer wrote:
> > On 10/26/23 21:25, Alex Goins wrote:
> > > On Thu, 26 Oct 2023, Sebastian Wick wrote:
> > >> On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka
I'm afraid that would not be very useful. It indeed depends on the refresh
rate, but also on how close to vblank the compositor does its commits / on
what the latency requirements for the currently shown content are.
When the compositor presents a fullscreen video with frames that are queued
up in
Hi,
The patch makes sense to me, and with this fix, my implementation for
tearing in KWin can be a lot simpler. Consider it Tested-by: Xaver
Hugl
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
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/drm_connector.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b0516505f7ae..01e13984629b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm
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
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
Hi,
KWin does use DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT. Tying the check to
DRM_CLIENT_CAP_ATOMIC instead would IMO make more sense though (even if it's
still weird) and would work with older versions of KWin and other compositors.
Greetings,
Xaver Hugl
Am Mi., 10. Jan. 2024 um 01:28 Uhr schrieb Zack Rusin <
zack.ru...@broadcom.com>:
> On Tue, Jan 9, 2024 at 11:06 AM Xaver Hugl wrote:
> >
> > Hi,
> >
> > KWin does use DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT.
>
> Can you point me to the code that implements
Like with FB_ID, the driver never has to do bandwidth validation to use
these properties, so there's no reason not to allow them.
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gp
Am Do., 11. Jan. 2024 um 18:13 Uhr schrieb Simon Ser :
> Are we sure that all drivers handle these two props properly with async
> page-flips? This is a new codepath not taken by the legacy uAPI.
>
I've only tested on amdgpu so far. Afacs the other drivers that would need
testing / that support at
Great, thank you!
Am Do., 11. Jan. 2024 um 19:05 Uhr schrieb André Almeida <
andrealm...@igalia.com>:
> Em 11/01/2024 14:59, Xaver Hugl escreveu:
> > Am Do., 11. Jan. 2024 um 18:13 Uhr schrieb Simon Ser
> > mailto:cont...@emersion.fr>>:
> >
> > Are we
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
://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 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 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(+
Am Do., 21. Nov. 2024 um 18:22 Uhr schrieb Antheas Kapenekakis
:
>
> The following series moves the _DSM 3,4,7,8 firmware notifications outside
> the suspend sequence, and makes them part of a transition function, where
> the system can transition freely between them when it is not suspended.
> Thi
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
> +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
There's no way to signal failure to userspace, so if the ioctl requesting
the event succeeds, the kernel must *always* send the event, or userspace
will be stuck, forever waiting for the event that never comes.
Signed-off-by: Xaver Hugl
---
include/uapi/drm/drm_mode.h | 6 ++
1 file ch
> 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
> Can I have your Acked-by: for this series?
Yes, consider it
Acked-by: Xaver Hugl
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
> > 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,
> 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
Am Fr., 28. März 2025 um 16:56 Uhr schrieb Arun R Murthy
:
>
> All of the formats/modifiers supported by the plane during synchronous
> flips are nor supported by asynchronous flips. The formats/modifiers
> exposed to user by IN_FORMATS exposes all formats/modifiers supported by
> plane and this li
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
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
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
Am Do., 10. Juli 2025 um 22:21 Uhr schrieb Ville Syrjälä
:
>
> On Mon, Jul 07, 2025 at 03:41:20PM +, Naveen Kumar wrote:
> > Allow asynchronous page flips on planes that either lack a framebuffer or
> > retain the same framebuffer, as long as no plane properties are modified.
> >
> > This avoid
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
I reviewed the KWin implementation for this
(https://invent.kde.org/plasma/kwin/-/merge_requests/7689), and the
uAPI looks good to me.
- Xaver
Hello,
This patch is Acked-by: Xaver Hugl
- Xaver
> 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
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
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
Am Mi., 30. Juli 2025 um 12:36 Uhr schrieb Arun R Murthy
:
>
> There can be multiple reasons for a failure in atomic_ioctl. Most often
> in these error conditions -EINVAL is returned. User/Compositor would
> have to blindly take a call on failure of this ioctl so as to use
> ALLOW_MODESET or any. I
50 matches
Mail list logo
