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
Anchors are in window geometry, so we should be using 0,0 instead
of the parent x,y for the top left corner of the window.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7436
I'm going to deal with some ugly geometry problems in the getter func
shortly.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7431
Wayland shells have no way to unset iconified state. What this code
did was corrupt current window state in potentially fatal ways.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7430
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:
This fixes a session recovery bug with software render.
An attempt to re-use a buffer in a new wayland connection resulted
in another disconnect and broken rendering.
Depends on D6281
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6282
Summary:
It's convenient to be able to pass this through this api too.
@betabreak
Depends on D6280
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6281
Summary:
We need to be able to forcibly destroy all surface buffers to make
session recovery work safely for software rendering.
@betabreak
Depends on D6278
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6279
Summary:
Since this can't be done, it probably doesn't need API.
@betabreak
Depends on D6276
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6277
Summary:
Our wayland mouse cursor code can trigger commits with commit pending
when mousing into a window across CSD, which results in quickly setting
the default cursors then an animated resize cursor before the first commit
has finished.
Fixing this is non trivial, and the bug is just a harmless inefficiency
of little impact, so just disable the ERR for that specific case instead.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6184
Summary:
We now have the ability to provide the seat information properly, so
fire off an ERR if a caller doesn't.
Depends on D6131
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6132
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
Clean up various places where we do flushes that we don't need to
because some immediately following action is going to cause a flush.
Also fix places where we flush without actually doing anything.
False commit when a commit is already pending is an error, but for safety
it should be a nop.
Currently it would overwrite the existing frame callback which could
cause problems on window destruction.
This is now done in ecore_evas where it should be. alpha_set now does
only what its name claims it does - sets whether a surface has an alpha
channel or not.
Window geometry x, y are the offset from the top left corner of the
buffer, and not screen co-ordinates, so has nothing to do with output
geometry and can't be used to determine which window we're on.
Now that we track surface enter/leave events we can just give the first
output in the list of outputs we know we're on.
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
We actually can't ever query this, it's clearly defined that way in the
protocol. There is absolutely no way to ever know if we're iconified.
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
ecore_wl2_window_commit() must be called during window size negotiation,
but this currently trips a warning when no frame callback has been
received for the first commit. We can't even have frame callbacks at
that point because no buffer is attached.
Don't set up the commit_pending logic until after we have a buffer.
Clear out the window callback when doing session recovery, and
make sure we have a valid on if we get a double commit.
This should stop a session recovery crash, and fix a small leak per
recovery.
b48781aa6c fixed multiple bugs where the
display wasn't flushed correctly, however it was a little overzealous.
Some of the flushes were added after calls that only updated internal
state, some in internal functions in which the caller was already going
to flush, and some were after wayland protocol calls that are double
buffered anyway and won't do anything until a following commit.
Also, I've removes at least one long standing flush where the recently
added flush is in a better location than the original.
in the case where a connection was not actively rendering, there was nothing
which would trigger a display flush, leading to applications potentially
deadlocking
@fix
This allows something that only has the Ecore_Wl2_Window (ie: something
that isn't engine code) to force dropping of all the buffers.
This should be safe to call at any time as the buffer handling logic
will properly cleanup the buffers when async render is done with them
or the compositor releases them.
This will eventually be used when a wayland client receives a
wl_output.leave events to indicate it isn't displayed on any outputs.