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

Reply via email to