this avoids conflicts with efl internals, which will break entirely
when DISPLAY is set under wayland, and xwayland internals, which will
abort immediately when efl tries to connect to it during its init phase
enlightenment is (I think) the first wayland compositor to run with
in-process pulseaudio integration for audio playback and not just mixer
support. hooray.
this results in a fun issue: if DISPLAY is set, as it must be for x11
clients to function, pulseaudio will unconditionally attempt to use a
blocking socket connection to create a connection to the running xserver.
the only exception here is if x11 support has been compiled out of pulseaudio,
but probably no distro will do that ever.
so, what happens when the compositor thread tries to create a socket connection
to the xserver that the compositor thread has not yet started? absolutely nothing.
forever.
the easiest solution which continues to provide the key press sounds that everyone
loves is to ensure that the pulseaudio connection is created before DISPLAY is ever
set, namely in the xwayland module init.
this will now occur automatically now in the case when the mixer module detects
pulseaudio support.
TL;DR: don't disable mixer module if you use xwayland
still a little rough, but the basics are functional. works by showing
the x11 compositor selection window, which has rects to exclude geometries
of xwl clients, for getting x11 xdnd events, and then manually sending
all the related client messages in order to inform the x11 client that
enlightenment is, in fact, an extremely credible xdnd drop site and not
a rogue compositor which will mangle/destroy the dnd data.
still render crashes after the operation completes, so possibly not the
most useful thing to be using now
this operation performs a synchronous socket connection inside xlib which can
block for an infinite amount of time. in order to avoid having a potentially
unlimited amount of time where the ui is frozen and polling on the socket connection,
move it to a thread where it can hang for as long as it wants and then use the
resulting display object for the ecore-x connection
this is only required for aliasing E_Client->comp_data as wayland compositor data.
if comp_data is never dereferenced, it is not necessary to declare the compositor
type
this is impossible and will never be possible; ecore-x can only manage
a single x11 connection at any time, and so it will never be possible to both
manage the x11 compositor canvas on one xserver and manage xwayland clients
on a separate server
invalidates T2537
XWayland servers sends us SIGUSR1 when it has finished initializing,
so we should be checking the signal number when we get the event.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Elyes HAOUAS
Carsten Haitzler
Derek Foreman
Mike Blumenkrantz
Chris Michael
Marcel Hollerbach