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

[Emil Velikov]

On 26 March 2015 at 16:20, Chad Versace <chad.versace at intel.com> wrote:
> 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.
>
This is precisely what I was thinking/talking about.

>>  - 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.
>
Before anything else, just want to say that I'm not against xcb in any
way, but I was hoping to get a clear (either Xlib or xcb only)
implementation for waffle. Considering we need Xlib to interact with
libEGL (as pointed above) was hoping that we can go with it, and opt
for a xcb only solution when possible. Seems like that won't be the
case :-'(

My main concern is that despite xcb's introduction quite some years
ago, there are still places where it lacks functionality wrt Xlib.
Mainly around interacting with glx. On the topic of that it's easier
to understand the following reply from Keith [1] left me with the
opposite impression. Yet It could be that the Xlib code is even
harder/messier. And a final nail in the coffin (sort of speak) seems
that the Valve guys have noticed some issues with the xcb-fication of
glx/dri2 and are carrying patches that revert it.

All that moaning done, I will shut up on the topic, and take a closer
look into reworking the dependencies. Hopefully it will end up cleaner
than expected.


Cheers,
Emil

[1] "The problem is that reviewing this patch is *really hard*. The
last time, I think I spent a solid couple of days thinking about this
and making sure I'd caught all of the cases..."

http://lists.x.org/archives/xorg-devel/2014-September/044063.html