<table><tr><td style="">fredrik added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D10747">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D10747#237235" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">D10747#237235</a>, <a href="https://phabricator.kde.org/p/romangg/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@romangg</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><p>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.</p></div>
</blockquote>
<p>I don't know if it's available on all platforms we support, and copying it was the path of least resistance.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Should LinuxDmabufParams subclass Resource?</p></blockquote>
<p>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.</p></div></div><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D10747#inline-58947">View Inline</a><span style="color: #4b4d51; font-weight: bold;">romangg</span> wrote in <span style="color: #4b4d51; font-weight: bold;">linuxdmabuf_v1_interface.h:107</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">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.</p>
<p style="padding: 0; margin: 8px;">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.</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">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.</p>
<p style="padding: 0; margin: 8px;">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.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R127 KWayland</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D10747">https://phabricator.kde.org/D10747</a></div></div><br /><div><strong>To: </strong>fredrik, KWin, Plasma, graesslin, davidedmundson, mart<br /><strong>Cc: </strong>romangg, plasma-devel, Frameworks, ragreen, Pitel, schernikov, michaelh, ZrenBot, ngraham, bruns, alexeymin, lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, mart, hein<br /></div>