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