I'm rather new to the this so apologies if I mistaken things:

Note that there are two things disguised here: data sharing between different processes types and when exactly can we retrieve the wl_display wayland primitive (this closely related to https://jira.automotivelinux.org/browse/SPEC-3215).

• data sharing might be necessary as to pass the protocol interface pointer that tells the compositor to activate surfaces but also to send ready request back to the compositor. I'm really sure this might be needed, but it seems to be case at this point
• when if this is not obvious, you can only get the wl_display after the connection has been set-up: it is not available in runtime or sharedprocess, but only in the renderer one.

What I've gather so far:

• Even if the wl_display is correctly returned from chromium68 I see that only in the renderer process we get a wayland connection which means that ozonewayland::WaylandDisplay::GetInstance() will properly return a wl_display after that has had a chance to run.
• It seems that from RenderProcessRuntime::run() we should be able to that, more specifically from AGLRendererDelegateWAM, but in the code that is never used. I then added AGLRendererDelegateWAM instead of AGLMainDelegateWAM. Turns out that the AGLRendererDelegateWAM::AboutToCreateContentBrowserClient is never ran at all.
• So the questions is when exactly can we retrieve wl_display

Regarding the sharing the protocol interface between the two:

• what is the purpose of the sharedbrowser is that able to share memory, pointers?
• I see that the socket used as communication is only passing strings/chars? Can that be used for memory/pointers?
• Assuming that the wl_display and the protocol interface binding will reside (initially) in the renderer process how do we access it from runtime/shared browser process?