Skip to content
  • Simon Ser's avatar
    8f6ea27b
    drm: two planes with the same zpos have undefined ordering · 8f6ea27b
    Simon Ser authored
    
    
    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: default avatarSimon Ser <contact@emersion.fr>
    Reviewed-by: default avatarPekka Paalanen <ppaalanen@gmail.com>
    Cc: Marius Vlad <marius.vlad@collabora.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: James Qian Wang <james.qian.wang@arm.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr
    8f6ea27b
    drm: two planes with the same zpos have undefined ordering
    Simon Ser authored
    
    
    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: default avatarSimon Ser <contact@emersion.fr>
    Reviewed-by: default avatarPekka Paalanen <ppaalanen@gmail.com>
    Cc: Marius Vlad <marius.vlad@collabora.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: James Qian Wang <james.qian.wang@arm.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr
Loading