fredrik added a comment.
In D10747#237235 <https://phabricator.kde.org/D10747#237235>, @romangg wrote:
> 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.
I don't know if it's available on all platforms we support, and copying it
was the path of least resistance.
> Should LinuxDmabufParams subclass Resource?
I considered doing that, but Resource is designed in such a way that it
requires the use of a d-pointer, and LinuxDmabufParams is a private class.
> romangg wrote in linuxdmabuf_v1_interface.h:107
> 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
I considered that, but it seems ugly to have the compositor call back into
KWayland from the slot. It would also be necessary to pass a pointer to the
LinuxDmabufParams object in a signal parameter, just so the compositor can pass
it back to KWayland.
A slightly less ugly option would to make the LinuxDmabufParams class public,
and emit the signal from the params object. But that would require the
compositor to track the creation of those objects so it can connect the signal
to a slot.
To: fredrik, #kwin, #plasma, graesslin, davidedmundson, mart
Cc: romangg, plasma-devel, #frameworks, ragreen, Pitel, schernikov, michaelh,
ZrenBot, ngraham, bruns, alexeymin, lesliezhai, ali-mohamed, jensreuterberg,
abetts, eliasp, sebas, apol, mart, hein