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. INLINE COMMENTS > 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 > proceed. 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. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D10747 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
