Skip to content

dri: revert INVALID modifier special-casing

Simon Ser requested to merge emersion/mesa:drop-invalid-mod-special-case into main

What does this MR do and why?

dri: revert INVALID modifier special-casing

Commit 361f3622587e ("dri: Unify createImage and createImageWithModifiers")
has introduced new behavior for drivers which don't support explicit
format modifiers. Before this commit, INVALID was not special-cased
and any call to dri_create_image() with one or more modifiers returned
NULL. After this commit, INVALID gained a special meaning: it indicates
that the implicit modifier is accepted by the caller. This is surprising
and is an API break.

This causes further API breaks: for instance, before this commit a BO
created via gbm_bo_create_with_modifiers() was guaranteed to always
return a non-INVALID modifier in gbm_bo_get_modifier().

This is inconsistent with gbm_dri_surface_create(): that function
treats INVALID as a bad entry in the modifier list, and fails if
it's the only acceptable modifier.

Additionally, drivers don't special-case INVALID and just ignore it
if they see it in a modifier list. This causes more inconsistencies.
For instance, let's say that a library user passes the modifier list
{ INVALID, FOO } to GBM. If a driver supports explicit modifiers and
doesn't support FOO for scanout, it'll return NULL. If a driver
doesn't support explicit modifiers, the current logic would return
a non-NULL BO with an INVALID modifier. This discrepency makes it
harder to reason about the system: half of the API ignores INVALID,
while the other half assumes INVALID indicates an implicit modifier.

To fix these issues, revert to the behavior before the commit, and
require use of the dedicated API without supplying any modifier for
implicit modifiers.

Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 361f3622587e ("dri: Unify createImage and createImageWithModifiers")

cc @daniels

Merge request reports