D10747: Implement zwp_linux_dmabuf_v1

[Roman Gilg]

romangg added a comment.


  Regarding the "drm_fourcc.h" file: do we want to copy it in KWayland's code base or could we use the system one? It's only available on Linux? In this case could we include it as a dummy only on non-Linunx systems? This way we could use the system one on Linux.
  
  Should LinuxDmabufParams subclass Resource?

INLINE COMMENTS

> fredrik wrote in linuxdmabuf_v1_interface.h:39
> Do we want these nested namespaces? We could have LinuxDmabufFlags, LinuxDmabufBuffer etc. instead.

Since there are not yet any namespaces in KWayland below the client/server level, I would prefer it without the namespace.

> fredrik wrote in linuxdmabuf_v1_interface.h:65
> Should the Buffer class use a d-pointer?

I think yes. Together with a Private class implemented in the cpp file.

> fredrik wrote in linuxdmabuf_v1_interface.h:107
> Is this the solution we want for interfacing with the compositor?
> 
> My preference would be to use std::function callbacks, with setters in LinuxDmabufUnstableV1Interface. Setting up the interface could then look like this:
> 
>   m_linuxDmabuf = m_display->createLinuxDmabufInterface(m_display);
>   m_linuxDmabuf->setQuerySupportedFormats([]{ return Compositor::self()->scene()->supportedDrmFormats(); });
>   ...
>   m_linuxDmabuf->create();
> 
> This can also be extended without breaking binary compatibility. But I don't think we can use std::function in frameworks. There are also BIC issues when mixing different STL implementations, which we may or may not care about.

I'm not sure what's the canonical way in KWayland to do this. I assume the supported formats and modifiers could be saved in a field of the interface's Private class on creation.

The buffer could be imported through a signal to the compositor and a function in the interface to be called by the compositor afterwards to proceed.

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D10747

To: fredrik, #kwin, #plasma, graesslin, davidedmundson, mart
Cc: romangg, plasma-devel, #frameworks, ragreen, schernikov, michaelh, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, mart, hein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180330/0789d961/attachment.html>