Hi Pekka, On Mon, 9 Jul 2018 at 10:39, Pekka Paalanen <[email protected]> wrote: > On Thu, 5 Jul 2018 18:16:40 +0100 > Daniel Stone <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
