[PATCH v16 13/23] compositor-drm: Add modifiers to GBM dmabuf import

[Daniel Stone]

Hi Pekka,
On Mon, 9 Jul 2018 at 10:39, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Thu,  5 Jul 2018 18:16:40 +0100
> Daniel Stone <daniels at collabora.com> wrote:
> > +        /* XXX: TODO:
> > +         *
> > +         * Currently the buffer is rejected if any dmabuf attribute
> > +         * flag is set.  This keeps us from passing an inverted /
> > +         * interlaced / bottom-first buffer (or any other type that may
> > +         * be added in the future) through to an overlay.  Ultimately,
> > +         * these types of buffers should be handled through buffer
> > +         * transforms and not as spot-checks requiring specific
> > +         * knowledge. */
>
> Bad whitespace in the above indentation.
>
> I'm also not sure I agree with how things should be done instead. It's
> possible the dmabuf wl_buffer is created by a library (libEGL, media,
> etc.) which may not communicate these details outside, may not give a
> possibility to add state to the wl_surface.commit, or may not actually
> drive wl_surface itself. There could be many client-side designs where
> this detail is not combinable with wl_surface state in the client.
>
> Also, only y-inverted would be possible to deal with buffer transform.
> The other flags probably do require specific knowledge if they were to
> be implemented properly.
>
> Hmm, it's an interesting question how buffer_damage should be
> interpreted in case of e.g. y-inverted dmabuf.

Micah wrote the above comment, which I'm just transporting from one
place to another. My interpretation of what he wrote is _not_ that the
client should use protocol calls to add a transformation, but that
setting the flag should result in a transformation in Weston core,
rather than being checked and accounted for directly in the end users
of that buffer. I probably read it like that because I agree with it.
;)

Cheers,
Daniel