[waffle] [PATCH v3 4/4] wayland: resolve wayland-client symbols at runtime (via libdl)

[Chad Versace]

Quoting Emil Velikov (2015-03-18 13:03:08)
> On 17 March 2015 at 19:54, Chad Versace <chad.versace at intel.com> wrote:
> > Hey Emil,
> >
> > The patches look good to me, though I haven't tested them yet.
> > I'm going to run the patches through a Piglit run and, if I
> > find no regressions, I'll push them.
> Great thanks.
> 
> Looking at the next times on the top of my waffle todo:
>  - Rework the waffle test - fold the test init and teardown within the
> waffle test hooks.
> Will allow us to use the waffle_init() waffle_teardown(), effectively
> "reloading" waffle for each test. We can even intentionally randomise
> the tests across threads, to ensure that the going from platfrom_foo
> to platform_bar does not cause problems.
> 
> It will be quite some work so if I'd like your opinion on it before I
> crack on it.

Do you mean calling waffle_init() and waffle_teardown() before and after
tests/functional/gl_basic.c:gl_basic_draw(), or something similar to
that? If so, that sounds like a good idea, especially the optional
randomization of tests across threads. That should provide some good
test coverage of Waffle handling (serially, though not concurrently)
multiple platforms in one process.

>  - Remove the xcb + libX11 link time dependency (rework the platforms
> to use libX11 alone).
> I'm leaning towards the latter, as it would simplify things. Although
> I'm a but uncertain if you chose the mixed design due to some
> technical reason ?

Technical reasons did drive my decision.

Originally, I tried to write Waffle's X11 code using only Xlib. After
trying for several days (I am no X expert) I gave up and moved to xcb,
which I got working after just a few hours. (I attribute my failure not
only to Xlib having an awful API but also to my lack of familiarity with
it).

I was unable to go purely with xcb, though, because the native_display
parameter of eglGetDisplay must be an Xlib Display.  Ironically, Mesa's
EGL makes exactly one Xlib call, XGetXCBConnection, and uses only xcb
afterwards.

I think we have some strong precedent for avoiding Xlib:
    - Mesa's EGL decided to use only xcb and not Xlib.
    - Mesa's GLX DRI2 implementation is implemented with a mixture of
      Xlib calls and rolling X protocol by hand. When keithp later wrote
      Mesa's GLX DRI3 code, he decided to do it in pure xcb.
    - If we have any questions or problems with xcb, the library's
      source code is very readable.

In summary, my technical reasons were:
    - XCB's API is easier to understand (for me, at least).
    - The XCB API is actively extended to support new X11 protocol. Xlib
      is not, as far as I can tell.
    - XCB's source is easy to understand.
    - Other projects avoid Xlib too for similar reasons.