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
