Summary:
By using the prepare read code properly we can do wayland dispatch of
multiple queues in multiple threads. I'm not advocating we ever do so,
but if a library (perhaps a gl implementation) wants to dispatch its own
queue, and that happens in a separate thread from our event loop, we
probably don't want the world to explode.
Depends on D7914
Reviewers: zmike, devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7915
They're only ever on a single list, and never counted. inlist makes
more sense.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7610
Summary:
There's no benefit to generating ids instead of just using the
Ecore_Wl2_Window pointer in events.
This has the added benefit of working around a really nasty hash collision
bug when multiple ecore_evas engines are used at once.
ref T7053
ref T6222
@beta_break
Depends on D6521
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7053, T6222
Differential Revision: https://phab.enlightenment.org/D6522
Summary:
When a CSD button interaction under wayland leads to a compositor action
like move or resize, we essentially "give back" that button press to the
compositor, and it never sends us a mouse up for it.
We need to internally fire a mouse up event to fix up state so the client
doesn't think the mouse is still down. Until now we've been doing this
by setting a flag when we start a move/resize and checking it at next
pointer enter for the window.
This leads to unsolvable races and wacky bookkeeping, and runs afoul of
the fact that we're not actually guaranteed a pointer enter immediately
after a move completes. There is absolutely no way at all on wayland to
know if a move or resize operation has completed.
So, let's just fire the mouse up immediately on start of interaction,
which is raceless.
This fixes a years old bug where dragging a window might leave a stuck
mouse up, and allow hilighting text without drag after the window drag
completes. (elementary-test -to "text editor" with multiple windows open
exhibits this bug)
Depends on D6127
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6128
Under wayland we can set minimized but not unset it, nor can we tell
if it's been unset. This means we can't cache the value, we need to
make the protocol request any time ecore_wl2_window_iconified_set is
called.
ref T6834
Apparently when we initiate a client side move in ecore_wl2 we flag that
and send a mouse-up immediately on the next pointer enter.
Do the same for resize.
At some point this might need to be revisited, we should probably be
sending a "cancel" at the start of client initiated move/resize instead
of an up at the end?
Fix T6422
When a surface leaves all outputs we can discard its buffers to save
memory.
Currently most compositors don't send leave events for iconify, so this
pretty much just saves us a cursor buffer under weston for now, but in
the future it could be used for freeing resources of offscreen (fully
occluded or iconified) windows.
We use immediate mode dmabuf creation at runtime, but this can result in
clients being killed with no option to fallback if the buffers can't be
consumed by the compositor.
This test should catch when a system can allocate a dmabuf buffer and the
compositor claims to accept dmabuf, but the buffer can't actually be used
for whatever reason. We'll then use wl_shm at runtime instead of dmabuf.
There are some binds at startup that result in additional information
being sent, so we may need to call wl_display_sync() multiple times, and
only send the client a SYNC_DONE event when the final one completes.
This is really several inseparable commits mashed together, as doing this
a piece at a time would introduce broken intermediate revisions.
Double buffer incoming "configure" state from the compositor so it's held
back during asynchronous render and processed at frame completion.
Hold off on certain requests if their API has been invoked during async
render.
This should fix a lot of races, cosmetic issues, issues where weston can
kill our clients for acking configure (or not) at bad times, etc.
We do flushes when we need them now, so we don't need this somewhat
non deterministic flush mechanism anymore.
Anything that breaks as a result of this should be fixable by adding an
ecore_wl2_display_flush() somewhere appropriate.
So because we include wayland-server.h we're told that wl_buffer is
deprecated - however clients are still expected to use it, it's only
deprecated for usage in a compositor.
Making these into void pointers shuts up the warning.
We need to include wayland-server.h since some of the code provided by
ecore_wl2 is for compositors, but some of it is also for clients...
Abstract frame callbacks through ecore_wl2_window so we can add them in
multiple places without having the wayland compositor generate more than
one.
Also allows us to keep a callback registered over hide/unhide of a window
easily.
with deferred surface creation the first canvas change of hints may not
be able to trigger protocol methods for size hints, so ensure that hints are
set
This commit reverts support for added API functions inside Ecore_Wl2
to support setting window stacking mode as per IRC discussion with
Cedric
This reverts commit 1359fc9e5f.
Small patch to add API functions which allow getting/setting if a
window is in floating mode
"#divergence"
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add an API function which can be called to set if a
window should skip focus.
"#divergence"
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Derek Foreman
Derek Foreman
Mike Blumenkrantz
Chris Michael