[Mesa-dev] [PATCH] egl/wayland: Set __DRI_IMAGE_USE_SCANOUT for shared buffers

Daniel Vetter daniel at ffwll.ch
Wed May 4 06:28:59 UTC 2016

On Tue, May 03, 2016 at 05:24:02PM +0100, Daniel Stone wrote:
> On 3 May 2016 at 14:52, Daniel Vetter <daniel at ffwll.ch> wrote:
> > Having read the thread I think fixing up the validation part on the
> > compositor side would be the correct fix short term for this. That will
> > keep all options open for the future to optimize this however we want,
> > without the need for flag days across all mesa drivers.
> >
> > And yes, adding required additional metadata to the wayland drm proto will
> > be a bit of work, since to make it all work we'd also need to add import
> > support for that to gbm.
> Right, the GBM API needs to expose modifiers for this to be useful.
> And whilst doing that, really you want to be adding multi-plane
> support at the same time. Once you've got that far, it's presumably an
> extra DRIimage usage flag, to declare that the client is aware of
> modifiers. Something I've not yet had time for, sadly.

Quick correction, since I learned a few things from Kristian and Daniel
yesterday about wayland:
- for wayland we wouldn't need gbm import support at all, since the buffer
  sharing is implemented purely within libEGL - it registers/uses private
  wl protocol extensions. Therefore we wouldn't need to add any new public
  interfaces anywhere when we add fb_modifiers to the wl_drm proto.

  We would need to add a new interface on the gbm -> drm_fb path though,
  but one suggestion from Kristian was that gbm simply creates the drm_fb
  directly. That would take out one needless step every time we add more

- For DRI3 I think we'd still need gbm import support, since there the
  protocol is partially handled outside of the ddx (and hence no way to
  just let glamor/libEGL handle it all). Which also means we need to rev
  to DRI3.1, hooray. DRI2 is probably similar, but meh.

Cheers, Daniel
Daniel Vetter
Software Engineer, Intel Corporation

More information about the mesa-dev mailing list