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


> 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 

  m_linuxDmabuf = m_display->createLinuxDmabufInterface(m_display);
  m_linuxDmabuf->setQuerySupportedFormats([]{ return 
Compositor::self()->scene()->supportedDrmFormats(); });

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.

  R127 KWayland


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

Reply via email to