[PATCH] linux-dmabuf: un-deprecate format events

[Simon Ser]

On Thursday, April 11, 2019 11:48 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> Hi,
>
> at first hand, I would keep Weston's behaviour, because that is what
> the current protocol specification says exactly. The specification text
> is very clear on the intent: the old format event is not to be used, if
> both the client and server support the version with the modifier event.
> When the protocol will be stabilized (which is always an ABI break),
> the format event without a modifier will be removed.
>
> The difference to EGL API does not seem to be making anything more
> difficult either.
>
> Technically there is little difference between using two events with
> and without a modifier, and one event with a special no-modifier value.
> A technical reason to favour two different events would be bandwidth
> saving, since then one doesn't need to send the dummy modifier. Can we
> make that argument? If yes, that would be a good justification to make
> the change you propose.

Do we have a lot of these? My machines don't have any (i915 driver).

But anyway, I thought that DRM_FORMAT_MOD_INVALID was being phased out?

> At first read of your commit message, I got the feeling you want
> formats to be advertised by both events: format event to declare a
> format at all, plus modifier events to list any modifiers. That is also
> what your proposed spec text reads, so I'd recommend clarifying that
> implementations need to send only one of the two events per format. Or
> both if the same format can be used with and without a modifier?
>
> If we have two events, one without and one with a modifier, should we
> also then have two (well, four actually, for the immed variant)
> requests to create a buffer: one without and one with a modifier? I
> think it would be nice to have these consistent unless there is a
> reason not to.
>
> I can find justification both ways, and whether we need to fix Weston
> or Mutter is not that important to me. I might want to avoid the four
> create requests case though.

I agree that either way, some compositors will need to be fixed, and that we
shouldn't decide based on current implementations.

> I'm not sure the versioning fully works out, if we have:
> - version 1 and 2 have only 'format' event
> - version 3 has 'modifier' event, with 'format' event not to be used
> - version 4 wants to use both 'modifier' and 'format' events

Yeah, that would be a little bit annoying.

> Implementation would need to adhere to these, so Mutter would still
> need fixing for clients that bind version 3. I don't think we should
> retro-actively change the semantics of an existing version.

If the protocol isn't ambiguous, it would be dangerous to change semantics
indeed.

> I notice that currently the modifier is in
> zwp_linux_buffer_params_v1.add request which makes the modifier
> per-plane, but I seem to recall that in practise modifiers are nowadays
> used only per-buffer, not per-plane, so the modifier argument should
> move to the create and create_immed requests.

You're right, modifiers are now per-buffer and not per-plane.

> We also need to consider https://patchwork.freedesktop.org/patch/263061/ .
>
> I would propose the following roadmap:
>
> 1. Do not un-deprecate format events; instead clarify the modifier on
>    create and fix Mutter's behaviour.
>
> 2. Get https://patchwork.freedesktop.org/patch/263061/ merged.
>
> 3. Stop using wl_drm completely when both server and client support the
>    latest zwp_linux_dmabuf.
>
> 4. Do ABI-breaking cleanups, and bump the major or if we are sure
>    enough then declare the extension stable.
>
> The reason why I would throw the 'format' event away as it is is that
> then it will be consistent with the create requests: use
> DRM_FORMAT_MOD_INVALID for "no modifier" in both events and requests. I
> would assume that the bandwidth savings would not be significant,
> considering everything is aiming to have explicit modifiers.
>
> How would that sound?

This makes a lot of sense to me. +1.