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 Paalanen wrote:
>>> On Wed, 25 Oct 2023 15:16:08 -0500 (CDT)
>>> Alex Goins wrote:
>>>
Despite being programmable, the LUTs are updated in a manner that is less
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 Paalanen wrote:
> >>> On Wed, 25 Oct 2023 15:16:08 -0500 (CDT)
> >>> Alex Goins wrote:
> >>>
> >
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
On Fri, 27 Oct 2023 12:01:32 +0200
Sebastian Wick wrote:
> 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 Paalanen wrote:
> > >>>
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
Reviewed-by: Simon Ser
Have you seen the comment on top?
* Atomic drivers should never call this function directly, the core will read
* out property values through the various ->atomic_get_property callbacks.
It seems like atomic drivers shouldn't call drm_object_property_get_value()
at all?
On Thursday, October 19th, 2023 at 23:21, Harry Wentland
wrote:
> +++ b/drivers/gpu/drm/vkms/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0+
It seems like the original Kconfig uses GPL-2.0-only. I think it'd be
safer to just re-use the exact same license here?
With that fixed
Add pixel source to the atomic plane state dump
Reviewed-by: Dmitry Baryshkov
Acked-by: Harry Wentland
Acked-by: Sebastian Wick
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/drm_atomic.c| 1 +
drivers/gpu/drm/drm_blend.c | 1 +
drivers/gpu/drm/drm_crtc_internal.h | 1 +
3 f
Add solid_fill and pixel_source properties to DPU plane
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_p
Since solid fill planes allow for a NULL framebuffer in a valid commit,
add NULL framebuffer checks to atomic commit calls within DPU.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.
Some drivers support hardware that have optimizations for solid fill
planes. This series aims to expose these capabilities to userspace as
some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
hardware composer HAL) that can be set by apps like the Android Gears
test app.
In orde
Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
determine if the plane is solid fill. In addition drop the DPU plane
color_fill field as we can now use drm_plane_state.solid_fill instead,
and pass in drm_plane_state.alpha to _dpu_plane_color_fill_pipe() to
allow userspace to
Add solid_fill property data to the atomic plane state dump.
Reviewed-by: Dmitry Baryshkov
Acked-by: Harry Wentland
Acked-by: Sebastian Wick
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/drm_atomic.c | 4
drivers/gpu/drm/drm_plane.c | 8
include/drm/drm_plane.h | 3 +++
Add "SOLID_FILL" as a valid pixel source. If the pixel_source property is
set to "SOLID_FILL", it will display data from the drm_plane "solid_fill"
blob property.
Reviewed-by: Dmitry Baryshkov
Acked-by: Pekka Paalanen
Acked-by: Harry Wentland
Acked-by: Sebastian Wick
Signed-off-by: Jessica Zha
Loosen the requirements for atomic and legacy commit so that, in cases
where pixel_source != FB, the commit can still go through.
This includes adding framebuffer NULL checks in other areas to account for
FB being NULL when non-FB pixel sources are enabled.
To disable a plane, the pixel_source mu
Add support for pixel_source property to drm_plane and related
documentation. In addition, force pixel_source to
DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
legacy userspace.
This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources
Document and add support for solid_fill property to drm_plane. In
addition, add support for setting and getting the values for solid_fill.
To enable solid fill planes, userspace must assign a property blob to
the "solid_fill" plane property containing the following information:
struct drm_mode_so
Currently framebuffer checks happen directly in
drm_atomic_plane_check(). Move these checks into their own helper
method.
Reviewed-by: Dmitry Baryshkov
Acked-by: Harry Wentland
Acked-by: Sebastian Wick
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/drm_atomic.c | 130 +++
19 matches
Mail list logo
