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
