kernel/linux.git/include/drm/drm_plane.h, branch v5.15.215

drm/plane: Move drm_plane_enable_fb_damage_clips into core

2021-07-27T10:21:22+00:00

We're trying to have a fairly strict split between core functionality that defines the uapi, including the docs, and the helper functions to implement it. Move drm_plane_enable_fb_damage_clips and associated kerneldoc into drm_plane from drm_damage_helper.c to fix this. Reviewed-by: José Roberto de Souza Cc: Ville Syrjälä Cc: Gwan-gyeong Mun Cc: José Roberto de Souza Cc: Hans de Goede Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-3-daniel.vetter@ffwll.ch

drm/plane: check that fb_damage is set up when used

2021-07-27T10:21:22+00:00

There's two stages of manual upload/invalidate displays: - just handling dirtyfb and uploading the entire fb all the time - looking at damage clips In the latter case we support it through fbdev emulation (with fb_defio), atomic property, and with the dirtfy clip rects. Make sure at least the atomic property is set up as the main official interface for this. Ideally we'd also check that drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up, but that's quite a bit harder to do. Ideas very much welcome. From a cursor audit drivers seem to be getting this right mostly, but better to make sure. At least no one is bypassing the accessor function. v2: - use drm_warn_once with a meaningful warning string (José) - don't splat in the atomic check code for everyone (intel-gfx-ci) Reviewed-by: José Roberto de Souza (v1) Cc: Ville Syrjälä Cc: Gwan-gyeong Mun Cc: José Roberto de Souza Cc: Hans de Goede Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-2-daniel.vetter@ffwll.ch

drm/plane: remove drm_helper_get_plane_damage_clips

2021-07-27T10:21:22+00:00

It's not used. Drivers should instead use the helpers anyway. Currently both vbox and i915 hand-roll this and it's not the greatest. vbox looks buggy, and i915 does a bit much that helpers would take care of I think. Also improve the kerneldocs while we're at it. Reviewed-by: José Roberto de Souza Cc: Ville Syrjälä Cc: Gwan-gyeong Mun Cc: José Roberto de Souza Cc: Hans de Goede Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-1-daniel.vetter@ffwll.ch

drm/gem: Move drm_gem_fb_prepare_fb() to GEM atomic helpers

2021-02-23T07:54:22+00:00

The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting, but currently located next to framebuffer helpers. Move it to GEM atomic helpers, rename it slightly and adopt the drivers. Same for the rsp simple-pipe helper. Compile-tested with x86-64, aarch64 and arm. The patch is fairly large, but there are no functional changes. v3: * remove out-comented line in drm_gem_framebuffer_helper.h (Maxime) v2: * rename to drm_gem_plane_helper_prepare_fb() (Daniel) * add tutorial-style documentation Signed-off-by: Thomas Zimmermann Acked-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210222141756.7864-1-tzimmermann@suse.de

drm/doc: fix drm_plane_type docs

2021-01-24T09:36:31+00:00

The docs for enum drm_plane_type mention legacy IOCTLs, however the plane type is not tied to legacy IOCTLs, the drm_cursor.primary and cursor fields are. Add a small paragraph to reference these. Instead, document expectations for primary and cursor planes for non-legacy userspace. Note that these docs are for driver developers, not userspace developers, so internal kernel APIs are mentionned. Signed-off-by: Simon Ser Reviewed-by: Daniel Vetter Acked-by: Pekka Paalanen Link: https://patchwork.freedesktop.org/patch/msgid/20210115110626.12233-1-contact@emersion.fr

drm/plane: add drmm_universal_plane_alloc()

2021-01-04T11:59:33+00:00

Add an alternative to drm_universal_plane_init() that allocates and initializes a plane and registers drm_plane_cleanup() with drmm_add_action_or_reset(). Signed-off-by: Philipp Zabel Reviewed-by: Laurent Pinchart Reviewed-by: Daniel Vetter

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