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

[Pekka Paalanen]

On Wed, 10 Apr 2019 14:00:12 -0700
Chia-I Wu <olvaffe at gmail.com> wrote:

> On Wed, Apr 10, 2019 at 12:40 PM Simon Ser <contact at emersion.fr> wrote:
> 
> > On Wednesday, April 10, 2019 9:25 PM, Chia-I Wu <olvaffe at gmail.com> wrote:  
> > > Both implementations support formats that have no explicit modifiers.
> > > But when it comes to buffer creation, modifier_hi/lo is required
> > > again.  It is unclear how to create a buffer for such formats.
> > >
> > > This patch tries to clarify these issues, leaning toward mutter's
> > > behavior.  
> >
> > Is there a reason to standardize Mutter's behavior instead of Weston's
> > and wlroots'? (Don't know about others)
> >  
> Frankly, there was no clear, strong argument to prefer one over the other
> to me.  Things I can think of are
> 
>  - it is more intuitive to have format events for formats and modifier
> events for modifiers
>  - having both events makes the protocol more similar to EGL's
> equeglQueryDmaBufFormatsEXT
> / eglQueryDmaBufModifiersEXT
> 
> I should bring this up that standardizing on Mutter's behavior means Weston
> and others require fixes, to send format events at least.  But
> standardizing on Weston's behavior means Mutter still works to some degree:
> it only loses formats that have no explicit modifiers because format events
> will be ignored.  But that degree of compatibility is not enough if the
> goal is to replace wl_drm ultimately.

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.

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'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

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.

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.

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?


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/20190411/bc37da30/attachment-0001.sig>