it is now possible to create a xephyr window in a drm-enlightenment session,
launch wl-x11 enlightenment in xephyr, and then launch wl-wl enlightenment
inside that enlightenment
the primary limitation on this output module is that all internal windows will
appear in the outer compositor due to the current restriction of ecore-wayland
with regard to only having a single global display server connection
#Inception
Summary:
If we use unsigned char pointers instead of void pointers we actually
conform to the C standard.
This patch removes a reliance on a gcc extension and, as an added bonus,
also quiets a warning in the default build.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2820
a client with this flag set here is unreliable to use as a stacking
reference since it has yet to be stacked and can be located anywhere
in the window stack.
fixes internal window stacking on startup
if pointer warping is disabled, attempting to pointer warp with mouse-based
focus policies will fail here, preventing focus from being applied as expected
ref T2566
blocks execution of resizes until the surface commit arrives. reduces
the race condition between resize and render and eliminates frame drops
during slow resizes
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
NB: e_comp_wl_input_keyboard_modifiers_update already sends keyboard
modifiers to all keyboard resources, so no need to call this twice.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Key state updates need to be consistent. As we update the key state on
key up regardless of client focus, then we should be doing the same in
the key_down event handler so that key state remains consistent.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
e_comp_wl_input_keyboard_state_update already makes a call to
e_comp_wl_input_keyboard_modifeirs_update so there is no need to call
it twice on key up/down events.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
I noticed e_bg_add calls e_bg_del so the additional call is not
required, it should also be noted the msgbus module doesn't call
this and works fine.
Reviewers: raster, zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2811
Summary:
previously e_bg_del didn't take the zone paramater into
account
fixes T2572
Reviewers: raster, zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2810
xwayland compositing requires that we set up a root window cursor image
immediately since we'll be getting that cursor surface to display as soon
as the pointer goes out of an x11 client's window
this requires that both canvas cursors and window cursors be present for the same
E_Pointer object, even though only the canvas cursor is actually visible
#kansas
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 used to be a marker for places where x11 functionality was needed,
but this has been simplified with the removal of wayland-only in configure
and so it is no longer needed
under wayland, some surfaces (eg. cursors) would attempt to show prior to
having acquired their actual size. these show attempts should be rejected
until the size has been set to ensure that rendering can proceed as expected
fix T2557
this is normally triggered by the engine/display server, but the drm
output is too powerful to be bothered by such trivial matters as
mouse events on startup
Summary: If we get here when curpage is NULL, we'll crash later, so we should test for it.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2793
Summary: If we get here when curpage is NULL, we'll crash later, so we should test for it.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2789
Summary: In some cases these end up uninitialized and we crash.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2788
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
due to recent changes in ecore-input-evas, mouse events are propagated
differently; specifically, there are now "more" events than there previously were.
as a result, grabs on internal wins are no longer necessary, though they probably
never were necessary after the elm conversion
see 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl
Mike Blumenkrantz
Seunghun Lee
Chris Michael
Derek Foreman
Simon Lees
Carsten Haitzler