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
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
> +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
> 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
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
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
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
> 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
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
15 matches
Mail list logo
