[PATCH] linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID

[Pekka Paalanen]

On Fri, 12 Apr 2019 10:50:49 -0700
Chia-I Wu <olvaffe at gmail.com> wrote:

> Moving the discussion to this patch...
> 
> This patch clarifies how implicit modifier can be supported, modelling
> after Weston's behavior.  I can see three options
> 
>  1. DRM_FORMAT_MOD_INVALID means implicit modifier, and is always allowed
> in buffer creation
>  2. DRM_FORMAT_MOD_INVALID means implicit modifier, and a modifier event of
> the value must be sent to indicate buffer creation with implicit modifier
> is allowed
>  3. DRM_FORMAT_MOD_INVALID is invalid and there is no implicit modifier
> support
> 
> This patch picks option 1.
> 
> Option 3 makes legacy support impossible, and in turn makes wl_drm
> deprecation take longer.
> 
> I've been thinking about moving away from implicit modifier as well so
> option 2 might be a good compromise.  The protocol is also more consistent
> in that one can create a buffer with a format/modifier pair only when the
> pair is advertised via the modifier event.

Hi,

yes, allowing to use only combinations of format and modifier that were
advertised would be nice. We should probably do that when we break the
protocol ABI the next time if that was not already the case. Until
then, if compositors have possibly accepted DRM_FORMAT_MOD_INVALID
without explicitly advertising it, we probably cannot make that illegal
at the protocol level. This would need a TODO note in the protocol spec
so we remember to do it during stabilization the latest.

A compositor can also refuse a dmabuf creation for any reason by
sending the "failed" event instead of "created". If we did allow
DRM_FORMAT_MOD_INVALID in the protocol temporarily, but drivers/GBM/EGL
don't allow the implicit modifier, no problem from protocol
perspective. The "create_immed" request is specifically outside of
validity considerations, we do not have to care about breaking that.

Option 1 we can certainly do right now. Option 2 I'd have to do some
research to see if it makes current practices illegal. Option 3 is
possible with a protocol ABI break, if all drivers and Mesa agree it
can be done. All of these options are fine with me with these
conditions.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190416/0134d1e1/attachment.sig>