[PATCH] linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID

Pekka Paalanen ppaalanen at gmail.com
Wed Apr 17 07:14:44 UTC 2019


On Tue, 16 Apr 2019 10:04:18 -0700
Chia-I Wu <olvaffe at gmail.com> wrote:

> On Tue, Apr 16, 2019 at 2:52 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > On Fri, 12 Apr 2019 10:50:49 -0700
> > Chia-I Wu <olvaffe at gmail.com> wrote:
> >  
> > > Moving the discussion to this patch...
> > >
> > > This patch clarifies how implicit modifier can be supported, modelling
> > > after Weston's behavior.  I can see three options
> > >
> > >  1. DRM_FORMAT_MOD_INVALID means implicit modifier, and is always allowed
> > > in buffer creation
> > >  2. DRM_FORMAT_MOD_INVALID means implicit modifier, and a modifier event of
> > > the value must be sent to indicate buffer creation with implicit modifier
> > > is allowed
> > >  3. DRM_FORMAT_MOD_INVALID is invalid and there is no implicit modifier
> > > support
> > >
> > > This patch picks option 1.
> > >
> > > Option 3 makes legacy support impossible, and in turn makes wl_drm
> > > deprecation take longer.
> > >
> > > I've been thinking about moving away from implicit modifier as well so
> > > option 2 might be a good compromise.  The protocol is also more consistent
> > > in that one can create a buffer with a format/modifier pair only when the
> > > pair is advertised via the modifier event.  
> >
> > Hi,
> >
> > yes, allowing to use only combinations of format and modifier that were
> > advertised would be nice. We should probably do that when we break the
> > protocol ABI the next time if that was not already the case. Until
> > then, if compositors have possibly accepted DRM_FORMAT_MOD_INVALID
> > without explicitly advertising it, we probably cannot make that illegal
> > at the protocol level. This would need a TODO note in the protocol spec
> > so we remember to do it during stabilization the latest.  
> Mutter does not advertise DRM_FORMAT_MOD_INVALID.  When a client
> creates a buffer with DRM_FORMAT_MOD_INVALID, Mutter passes the
> modifier to EGL and let EGL fail the buffer creation.
> 
> Weston always accepts DRM_FORMAT_MOD_INVALID however.  It strips the
> modifier out so that the drivers do not see the modifier.
> 
> Neither Mesa nor XWayland creates buffers with DRM_FORMAT_MOD_INVALID.
> They both fall back to wl_drm when the modifier is
> DRM_FORMAT_MOD_INVALID.  I guess not a lot of clients, if any, rely on
> weston's behavior.

Ok, that sounds reasonable. Even more so considering that an implicit
modifier only makes sense for self-import on a GPU device, and I have
hard time imagining such exports outside of Mesa.

Weston might have some test programs, but I wouldn't consider those
blockers. If necessary, they can be fixed at the same time Weston is.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190417/05cf93b9/attachment-0001.sig>


More information about the wayland-devel mailing list