Re: [PATCH 0/2] Add support for Panel Power Savings property

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

Re: [PATCH 0/2] Add support for Panel Power Savings property

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

Re: [PATCH] drm/amd: Drop abm_level property

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

Re: [PATCH] drm/amd: Drop abm_level property

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

Re: [PATCH v2 2/2] drm/amdgpu: Implement check_async_props for planes

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

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

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.

Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

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

Re: [PATCH] drm/amd/display: Fix sending VSC (+ colorimetry) packets for DP/eDP displays without PSR

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

Re: [PATCH] drm/amd/display: fix cursor-plane-only atomic commits not triggering pageflips

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 userspac

[PATCH] drm/amd/display: fix cursor-plane-only atomic commits not triggering pageflips

://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