linux-toradex.git/include/drm/drm_plane.h, branch v5.10-rc2

drm/plane: Clarify our expectations for src/dst rectangles

2019-10-10T13:49:34+00:00

The rectangles are usually clipped, but it can be useful to have
them unclipped, for example for cursor planes.

Signed-off-by: Maarten Lankhorst 
[mlankhorst: Change cursor plane to hardware performing clipping. (Ville)
             Fix dst description that went missing.]
Reviewed-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20191010112918.15724-1-maarten.lankhorst@linux.intel.com

drm: two planes with the same zpos have undefined ordering

2019-10-09T18:04:55+00:00

Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.

The unspoken, legacy rule used in the past was to make user-space figure
out the zpos from object IDs. However some drivers break this rule,
that's why the ordering is documented as unspecified in case the zpos
property is missing. User-space should rely on the zpos property only.

There are some cases in which user-space might read identical zpos
values for different planes.

For instance, in case the property is mutable, user-space might set two
planes' zpos to the same value. This is necessary to support user-space
using the legacy DRM API where atomic commits are not possible:
user-space needs to update the planes' zpos one by one.

Because of this, user-space should handle multiple planes with the same
zpos.

While at it, remove the assumption that zpos is only for overlay planes.

Additionally, update the drm_plane_state.zpos docs to clarify that zpos
disambiguation via plane object IDs is a recommendation for drivers, not
something user-space can rely on. In other words, when user-space sets
the same zpos on two planes, drivers should rely on the plane object ID.

v2: clarify drm_plane_state.zpos docs (Daniel)

v3: zpos is for all planes (Marius, Daniel)

v4: completely reword the drm_plane_state.zpos docs to make it clear the
recommendation to use plane IDs is for drivers in case user-space uses
duplicate zpos values (Pekka)

v5: reword commit message (Pekka, James)

v6: remove mention of Arm GPUs having planes which can't overlap,
because this isn't uAPI yet (Daniel)

Signed-off-by: Simon Ser 
Reviewed-by: Pekka Paalanen 
Cc: Marius Vlad 
Cc: Daniel Vetter 
Cc: James Qian Wang 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr

drm/docs: More links for implicit/explicit fencing.

2019-06-03T15:11:33+00:00

drm_atomic_set_fence_for_plane() contains the main discussion from a
driver pov, link to that from more places.

Cc: Pekka Paalanen 
Reviewed-by: Pekka Paalanen 
Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20190603142848.26487-1-daniel.vetter@ffwll.ch

drm: Add helper iterator functions for plane fb_damage_clips blob

2018-12-05T09:00:36+00:00

With fb_damage_clips blob property in drm_plane_state, this patch adds
helper iterator to traverse the damage clips that lie inside plane src.
Iterator will return full plane src as damage in case need full plane
update or damage is not specified.

v2:
- Plane src clipping correction
- Handle no plane update case in iter_next

Signed-off-by: Deepak Rawat 
Reviewed-by: Daniel Vetter 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Thomas Hellstrom

drm: Add a new plane property to send damage during plane update

2018-12-05T09:00:35+00:00

FB_DAMAGE_CLIPS is an optional plane property to mark damaged regions
on the plane in framebuffer coordinates of the framebuffer attached to
the plane.

The layout of blob data is simply an array of "struct drm_mode_rect".
Unlike plane src coordinates, damage clips are not in 16.16 fixed point.
As plane src in framebuffer cannot be negative so are damage clips. In
damage clip, x1/y1 are inclusive and x2/y2 are exclusive.

This patch also exports the kernel internal drm_rect to userspace as
drm_mode_rect. This is because "struct drm_clip_rect" is not sufficient
to represent damage for current plane size.

Driver which are interested in enabling FB_DAMAGE_CLIPS property for a
plane should enable this property using drm_plane_enable_damage_clips.

v2:
- Input validation on damage clips against framebuffer size.
- Doc update, other minor changes.

Signed-off-by: Lukasz Spintzyk 
Signed-off-by: Deepak Rawat 
Reviewed-by: Daniel Vetter 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Thomas Hellstrom

drm: Add drm_any_plane_has_format()

2018-11-06T19:34:22+00:00

Add a function to check whether there is at least one plane that
supports a specific format and modifier combination. Drivers can
use this to reject unsupported formats/modifiers in .fb_create().

v2: Accept anyformat if the driver doesn't do planes (Eric)
    s/planes_have_format/any_plane_has_format/ (Eric)
    Check the modifier as well since we already have a function
    that does both
v3: Don't do the check in the core since we may not know the
    modifier yet, instead export the function and let drivers
    call it themselves

Cc: Eric Anholt 
Cc: Dhinakaran Pandiyan 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Dhinakaran Pandiyan 
Link: https://patchwork.freedesktop.org/patch/msgid/20181029183453.28541-1-ville.syrjala@linux.intel.com

drm: drop drmP.h include from drm_plane.c

2018-09-09T12:19:17+00:00

Just a bit of missing includes and pre declarations.

v2: Compiles now, with drm/drm_util.h extracted.

v3: Rebase

v3: Fix up commit message (Sam Ravnborg)

Reviewed-by: Sean Paul 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20180905135711.28370-3-daniel.vetter@ffwll.ch

drm: Add drm/drm_util.h header file

2018-09-09T12:18:11+00:00

We have a bunch of neat little macros all over the place which should
move to kernel.h. But some of them died in bikesheds on lkml, and we
need a decent home for them.

Start out by moving the for_each_if macro there.

v2: Rename to drm_util.h instead (Dave&Sean)

Cc: Sean Paul 
Acked-by: Sean Paul 
Cc: Dave Airlie 
Acked-by: Dave Airlie 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20180905135711.28370-1-daniel.vetter@ffwll.ch

drm: Describe pixel_blend_mode in drm_plane_state

2018-08-31T15:37:39+00:00

Adds docs for pixel_blend_mode in drm_plane_state. Fixes the warning
found by kbuild test robot:

htmldocs: include/drm/drm_plane.h:189: warning: Function parameter or member 'pixel_blend_mode' not described in 'drm_plane_state'

Cc: Daniel Vetter 
Cc: Lowry Li 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20180831150934.202332-1-sean@poorly.run

drm: Add per-plane pixel blend mode property

2018-08-24T16:31:37+00:00

Pixel blend modes represent the alpha blending equation
selection, describing how the pixels from the current
plane are composited with the background.

Adds a pixel_blend_mode to drm_plane_state and a
blend_mode_property to drm_plane, and related support
functions.

Defines three blend modes in drm_blend.h.

Changes since v1:
 - Moves the blending equation into the DOC comment
 - Refines the comments of drm_plane_create_blend_mode_property to not
   enumerate the #defines, but instead the string values
 - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
Changes since v2:
 - Refines the comments of drm_plane_create_blend_mode_property:
      1) Puts the descriptions (after the ":") on a new line
      2) Adds explaining why @supported_modes need PREMUL as default
Changes since v3:
 - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
   can calculate the index itself just fine, so no point in having the
   caller pass it in.
 - Since the current DRM assumption is that alpha is premultiplied
   as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
 - Refines some comments.
Changes since v4:
 - Adds comments in drm_blend.h.
 - Removes setting default value in drm_plane_create_blend_mode_property()
   as it is already in __drm_atomic_helper_plane_reset().
 - Fixes to use state->pixel_blend_mode instead of using
   plane->state->pixel_blend_mode in reset function.
 - Rebases on drm-misc-next.

Reviewed-by: Liviu Dudau 
Signed-off-by: Lowry Li 
Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/245734/