--4938a0883dd7497a9a692a7a584d2d80 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ascii" Mime-Version: 1.0 romangg added a comment. 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. Should LinuxDmabufParams subclass Resource? INLINE COMMENTS > fredrik wrote in linuxdmabuf_v1_interface.h:39 > Do we want these nested namespaces? We could have LinuxDmabufFlags, LinuxDmabufBuffer etc. instead. Since there are not yet any namespaces in KWayland below the client/server level, I would prefer it without the namespace. > fredrik wrote in linuxdmabuf_v1_interface.h:65 > Should the Buffer class use a d-pointer? I think yes. Together with a Private class implemented in the cpp file. > fredrik wrote in linuxdmabuf_v1_interface.h:107 > 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. 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. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D10747 To: fredrik, #kwin, #plasma, graesslin, davidedmundson, mart Cc: romangg, plasma-devel, #frameworks, ragreen, schernikov, michaelh, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, mart, hein --4938a0883dd7497a9a692a7a584d2d80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ascii" Mime-Version: 1.0 View Revision
romangg added a comment.

Regarding the "drm_fourcc.h" file: do we want to co= py 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.

Should LinuxDmabufParams subclass Resource?


INLINE COMMENTS
View Inlinefr= edrik wrote in li= nuxdmabuf_v1_interface.h:39

Do we want these nested namespaces? We could have= LinuxDmabufFlags, LinuxDmabufBuffer etc. instead.

Since there are not yet any namespaces in KWayland below the clie= nt/server level, I would prefer it without the namespace.

View Inlinefredrik wrote in linuxdmabuf_v1_interface.h:65

Should the Buffer class use a d-pointer?

I think yes. Together with a Private class implemented in the cpp= file.


View Inlinefredrik wrote in linuxdmabuf_v1_interface.h:107

Is this the solution we want for interfacing with= the compositor?

My preference would be to use std::fu= nction callbacks, with setters in LinuxDmabufUnstableV1Interface. Setting u= p the interface could then look like this:

m_linuxDmabuf =3D m_display->createLinuxDmabufInterface(m_disp=
lay);
m_linuxDmabuf->setQuerySupportedFormats([]{ return Compositor::self()-&g=
t;scene()->supportedDrmFormats(); });
...
m_linuxDmabuf->create();

This can also be extended without bre= aking binary compatibility. But I don't think we can use std::function= in frameworks. There are also BIC issues when mixing different STL impleme= ntations, which we may or may not care about.

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 fie= ld 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.


REPOSITORY
R127 KWayland
=
REVISION DETAIL
https://phabricator.kde.org/D10747

To: fredrik, KWin, Plasma, graesslin, davidedmundson= , mart
Cc: romangg, plasma-devel, Frameworks, ragreen= , schernikov, michaelh, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohame= d, jensreuterberg, abetts, eliasp, sebas, apol, mart, hein
--4938a0883dd7497a9a692a7a584d2d80--