[PATCH v16 13/23] compositor-drm: Add modifiers to GBM dmabuf import
daniel at fooishbar.org
Mon Jul 9 12:21:09 UTC 2018
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.
More information about the wayland-devel