[PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

[Simon Ser]

On Thursday, November 14, 2019 4:13 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> yes. The main use for 'direct-display' flag is dmabufs that are
> "poisonous". Touching their content in any way might kill the
> compositor, or so I hear. Obviously no normal desktop system would ever
> have those, since they would be a trivial DoS attack vector.
>
> The hints extension will be useful for the users of 'direct-display',
> but indeed it is missing the bit to say which format+modifier would be
> scanout-able, so it's not sufficient as is.
>
> Possibly the closest use case on normal desktops would be XR without
> DRM leasing. You want the XR buffers to always go straight to display
> without compositing, but if they cannot, it is better to show e.g. black
> than a nauseating animation. Of course, such a use case would need
> other extensions as well, so you can rightly say that the other
> extensions should take care of this instead.

I think this use-case would be better handled via the presentation-time
protocol. presentation-time provides timing information and also has a
bit for direct scan-out.

Clients can read the presentation data and decide what to do: if direct
scan-out isn't used, and if latency is too high, render a simpler or a
black screen.

This would be better because the "placeholder" wouldn't be rendered by
the compositor, clients would render it themselves. Also clients can
decide to give up based on actual latency (and not just "is direct
scan-out used?": compositing might be fast enough on a system but too
slow on another).

Typically in the VR case, Steam games will render a very simple 3D grid
when they can't keep up.

> > I'm also worried about compositors that are capable of taking
> > screenshots. This flag implies that it's "dangerous" to ever touch the
> > buffer for any purpose. But then it sounds like you're encouraging video
> > players to use this, which is only going to break basic functionality. I
> > suspect than the only sensible thing for a screenshot-capable compositor
> > to do is to simply reject all uses of this flag, making it useless
> > outside of highly-integrated environments.
>
> Yes, screenshooting would only show the placeholder graphics, so you
> can argue that screenshooting would be broken.
>
> Quite the contrary, I'd recommend no-one to use this flag unless they
> know they really have to and have no other choice.
>
> A compositor implementation that outright always rejects this flag
> would be completely conformant. I'd probably recommend that to desktop
> compositors even, just like they already reject all flags they do not
> recognise. Hence a minimal implementation of this revision of
> zwp_linux_dmabuf would be trivial.
>
> (Did anyone actually do anything meaningful with the interlaced flag?)
>
> > dmabuf-hints seems like a much better way to achieve the same effect of
> > efficiency, instead of the client trying to dictate what the compositor
> > should do. If this flag is added, I would want a stern warning to not
> > carelessly use it unless the compositor literally can't access the
> > buffer from the GPU.
>
> It's a different problem.
>
> I can well understand if this flag gets rejected from zwp_linux_dmabuf.
> Maybe we should make this a separate extension instead, it would be
> quite simple too.

The fact that it's not a hint and that compositors need to render a
placeholder makes me think this would be better.

> Thanks,
> pq
>
> > Scott
> >
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel