Hi, > -----Original Message----- > From: Daniel Stone [mailto:[email protected]] > Sent: vendredi 30 octobre 2015 09:31 > To: Bryce Harrington > Cc: Fabien DESSENNE; Giulio Camuffo; Vincent ABRIOU; Benjamin Gaignard; > [email protected] > Subject: Re: [PATCH] dmabuf: get supported dmabuf formats from > compositor backend > > Hi, > > On 30 October 2015 at 00:27, Bryce Harrington <[email protected]> > wrote: > > On Tue, Oct 20, 2015 at 08:45:50AM -0700, Bryce Harrington wrote: > >> On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote: > >> > Add the possibility for the compositor backend to provide with the > >> > list of supported pixel formats for dmabuf-based buffers. > >> > This information is used by linux_dmabuf to inform clients when > binding. > >> > > >> > Signed-off-by: Fabien Dessenne <[email protected]> > >> > >> Reviewed-by <[email protected]> > >> > >> There's not a way to verify the list is getting sent across to the > >> client is there? > > > > Also, patch no longer applies since e3c0d8af. > > > > I'd like to better understand what this is going to be used for, > > before landing it. Another R-b on this would be nice as well; Giulio > > perhaps you could give this patch a review? > > Hm, to be honest I'd prefer this not land just now, or like this. > > dmabuf usage in compositor-drm is just an optimisation, where the fallback > path is through gl-renderer. Anything gl-renderer doesn't support, we > essentially can't display.
Maybe this is not always true : I use a forked version of compositor-drm (I plan to upstream some patches later) where the dmabuf buffers are displayed by the DRM planes: these buffers are not used by gl-renderer. This is a typical optimization use case: video playback frames being sent as dmabuf buffer to the compositor, and rendered without any copy through a DRM plane. Now, back to the proposed patch: in my proposal building the list of dmabuf formats is delegated to the backend, not built by the compositor itself. Not a big change and it does not solve the "EGL dmabuf formats" issue but there are two improvements: 1/ IMHO the supported formats are backend-dependent, so this patch makes some sense here. 2/ Depending on the backend implementation, the list of formats may be successfully built: this is the case with the compositor I use as it does not use gl-renderer for dmabuf buffers. > Those formats are what we need to send to the > compositor (possibly with the intersection between gl-renderer and > compositor-drm marked as preferred), but right now, as the comment notes, > we lack a way to query this through EGL. This is being worked on though. Good news! Do you know if there is any schedule for this? By the way, I think that my proposed patch and this EGL future patch are not incompatible: as explained, EGL is not the only dmabuf consumer: DRM plane is another consumer. At the end the format list shall be built by the backend, not by the compositor. Please, let me know your feedback. Fabien > > Cheers, > Daniel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
