D10747: Implement zwp_linux_dmabuf_v1

[Fredrik Höglund]

fredrik added inline comments.
Restricted Application edited projects, added Plasma; removed Plasma on Wayland.

INLINE COMMENTS

> linuxdmabuf_v1_interface.h:39
> +
> +namespace LinuxDmabuf
> +{

Do we want these nested namespaces? We could have LinuxDmabufFlags, LinuxDmabufBuffer etc. instead.

> linuxdmabuf_v1_interface.h:65
> +     */
> +    class Buffer {
> +    public:

Should the Buffer class use a d-pointer?

> linuxdmabuf_v1_interface.h:107
> +     */
> +    class Bridge {
> +    public:

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.

REPOSITORY
  R127 KWayland

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

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