D10747: Implement zwp_linux_dmabuf_v1
Fredrik Höglund
noreply at phabricator.kde.org
Thu Feb 22 15:07:53 UTC 2018
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/kde-frameworks-devel/attachments/20180222/98e89116/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list