D10747: Implement zwp_linux_dmabuf_v1

[David Edmundson]

davidedmundson added inline comments.

INLINE COMMENTS

> linuxdmabuf_v1_interface.cpp:364
> +
> +    static void unbind(wl_client *client, wl_resource *resource);
> +    static void createParamsCallback(wl_client *client, wl_resource *resource, uint32_t id);

is this defined? I can't find it

I'd expect it be used on line 408.

> linuxdmabuf_v1_interface.h:65
> +     */
> +    class Buffer {
> +    public:

doesn't this need exporting?

> linuxdmabuf_v1_interface.h:99
> + */
> +class KWAYLANDSERVER_EXPORT LinuxDmabufUnstableV1Interface : public Global
> +{

One of kwayland's functions is to act as an abstraction layer

Generally all exported class names aren't called with UnstableV1 or whatever.
This would be LinuxDmabufInterface and then we'd handle the V1 stuff in the private implementation.

(Personally, I think it's far more effort than it's worth to abstract something that isn't guaranteed to be compatiable, and would be ok for you argue that it's deliberate)

> 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 don't think I fully understand the issue.

I assume the problem we're solving is that we need to provide supportedFormats on client bind, and as per the spec we need to do that immediately but we don't have that information before the scene is created which comes after we create the global?

Looking at the current kwin patch we'd just return wrong values / even crash if we were called before the scene was created. Given that's currently the case, why can't we just have the compositor call  a normal setSupportedFormats(...) when the scene is first set up.

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, bruns, alexeymin, lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, mart, hein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180430/3a75f1a6/attachment.html>