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

drm: Introduce plane and CRTC scaling filter properties

2020-10-21T09:19:54+00:00

Introduce per-plane and per-CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.

Drivers can set up this property for a plane by calling
drm_plane_create_scaling_filter() and for a CRTC by calling
drm_crtc_create_scaling_filter().

NN filter works by filling in the missing color values in the upscaled
image with that of the coordinate-mapped nearest source pixel value.

NN filter for integer multiple scaling can be particularly useful for
for pixel art games that rely on sharp, blocky images to deliver their
distinctive look.

changes since: v6:
* Move property doc to existing "Standard CRTC Properties" and
  "Plane Composition Properties" doc comments (Simon)
changes since v3:
* Refactor code, add new function for common code (Ville)
changes since v2:
* Create per-plane and per-CRTC scaling filter property (Ville)
changes since v1:
* None
changes since RFC:
* Add separate properties for plane and CRTC (Ville)

Link: https://github.com/xbmc/xbmc/pull/18194
Link: https://github.com/xbmc/xbmc/pull/18567
Reviewed-by: Ville Syrjälä 
Reviewed-by: Uma Shankar 
Acked-by: Simon Ser 
Acked-by: Daniel Vetter 
Signed-off-by: Pankaj Bharadiya 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-2-pankaj.laxminarayan.bharadiya@intel.com

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