[RFC wayland 1/9] wayland-egl: import libwayland-egl.so frontend library from Mesa

Emil Velikov emil.l.velikov at gmail.com
Tue Sep 19 10:54:47 UTC 2017

On 19 September 2017 at 06:24, Duncan Roe <duncan_roe at optusnet.com.au> wrote:
> Hi Emil,
> On Mon, Sep 18, 2017 at 02:18:42PM +0100, Emil Velikov wrote:
>> Hi Duncan,
>> On 17 September 2017 at 09:04, Duncan Roe <duncan_roe at optusnet.com.au> wrote:
>> > On Fri, Sep 15, 2017 at 11:29:19AM +0100, Emil Velikov wrote:
>> >> From: Emil Velikov <emil.velikov at collabora.com>
> ...
>> > From checking header files it does seem to me that the layout of struct
>> > wl_egl_window is indeed opaque to the outside world, but all the same wouldn't
>> > it be better to be able to see what version of the library one had installed?
>> >
>> Why? Can you please elaborate.
> I searched /usr/include for includes of wayland-egl-priv.h. There weren't any
> (as one would hope, since Mesa doesn't expose it).
> I then searched /usr/include for declarations of struct wl_surface:
> qt5/QtWaylandCompositor/5.7.1/QtWaylandCompositor/private/wayland-wayland-server-protocol.h
>     90 struct wl_subsurface;
>     91 struct wl_surface;
>     92 struct wl_touch;
> It's declared but not defined. Code can only work with pointers to the struct
> and not its elements, which is what I meant by saying it was "opaque".
True, wl_egl_window is opaque. Then again, I'm not sure why would you
bump the version "just in case".
Note that bumping ABI/DSO version without a genuine reason is not a good idea.

As mentioned in the previous email - the struct is internal backend
information. One that can be detected by the backend at runtime.


More information about the wayland-devel mailing list