> +#define DRM_MODE_ATOMIC_FAILURE_REASON \
> + FAILURE_REASON(DRM_MODE_ATOMIC_CAP_NOT_ENABLED, "DRM_ATOMIC
> capability not enabled") \
> + FAILURE_REASON(DRM_MODE_ATOMIC_INVALID_FLAG, "invalid flag") \
> + FAILURE_REASON(DRM_MODE_ATOMIC_PAGE_FLIP_ASYNC, "Legacy
> DRM_MODE_PAGE
y run atomic_async_check
if the plane would actually be changed by the atomic commit.
Fixes: fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async
flip")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263
Signed-off-by: Xaver Hugl
Reviewed-by: André Almeida
---
y run atomic_async_check
if the plane would actually be changed by the atomic commit.
Fixes: fd40a63c63a1 ("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_ato
> As I commented earlier in the gitlab issue [1], any change of property,
> including disabling a plane is not allowed in the async commit.
> We must disable a plane (e.g. HW cursor) during the first (synchronized)
> flip, and allowing later flips to proceed asynchronously.
> This change should b
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
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
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
Hello,
This patch is Acked-by: Xaver Hugl
- Xaver
I reviewed the KWin implementation for this
(https://invent.kde.org/plasma/kwin/-/merge_requests/7689), and the
uAPI looks good to me.
- 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
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
> Can I have your Acked-by: for this series?
Yes, consider it
Acked-by: Xaver Hugl
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
> +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
Hi,
On Dienstag, 9. Juli 2024 09:46:56 MESZ Arun R Murthy wrote:
> Each plane has its own capability or interoperability based on the
> harware restrictions. If this is exposed to the user, then user can read
> it once on boot and store this. Later can be used as a lookup table to
> check a corres
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
19 matches
Mail list logo
