Coverity reports that accessing 'einfo' here is a NULL pointer
dereference. evas_engine_info_get can return NULL, so we should be
checking for a valid return before trying to use it.
Fixes Coverity CID1365654
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports a null pointer dereference here because
evas_engine_info_get can return NULL. Check for a valid return before
trying to use it.
Fixes Coverity CID1365655
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports illegal access here as we are trying to pass a freed
pointer to ecore_evas_free. Rework error handling to avoid this.
Fixes Coverity CID1365657
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
draw_frame is a legacy feature that draws a very ugly window border
with a white rect and a black text as title bar. This could be
used in wayland when using only the ecore_evas APIs, rather than
elm_win.
Note that the API ecore_evas_draw_frame_set() can not possibly work
as the flag is checked when the ecore_evas is created, so changing
the flag has no effect on existing windows.
Finally bring these together as much as possible to avoid future
diversions when bugs are only fixed in one or the other.
There are functional changes - state tracking for client side effects is
now added to the shm engine, some bug fixes for the egl engine have been
brought to the shm engine.
Brings resize code into the common implementation - there is a functional
change. There appears to have been a bug in the egl resize where it
used the same w, h order for portrait evases as for landscape. This was
fixed in shm. I've used the shm variant for the common code.
Moves transparent set into the common implementation - there is a
functional change here - the egl engine now calls transparent_set in
render_updates like the shm engine.
It is probable the this was the intended behaviour all along.
Moves alpha set into the common implementation - there is a functional
change here - the egl engine now calls alpha_do in render_updates like
the shm engine.
It is probable that this was the intended behaviour all along.
So when mouse / keyboard are present or not it will
generate events.
ecore_evas/wayland will handle that creating or
deleting evas devices for each one (seat device
will be used as parent).
Create or delete evas_devices with class EVAS_DEVICE_CLASS_SEAT
for seats on each ecore_evas created so far.
Initially it's named considering its Wayland id.
If we set a frame callback on a window with no shell surface (ie: and unmapped
window), the frame callback will never fire. This was preventing some
applications like rage from ever posting a frame.
Summary: Need to NULL check before using surface like other cases.
Test Plan: N/A
Reviewers: jpeg, raster, ManMower, devilhorns
Reviewed By: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4301
add support for reconnecting wayland applications if the compositor dies
disconnect -> destroy gl ctx + image textures -> block rendering ->
reconnect -> create gl ctx -> create image textures -> unblock rendering ->
sprinkle special seasoning on top -> just like ma used to make
#SamsungFeatures
@feature
the only way to accurately calculate the "evas" size in the engine from
window geometry is to have the size of the frame available to subtract from
window geometry
window geometry is NOT framespace--framespace is the entire csd region, possibly
containing a shadow, and window geometry is explicitly the region occupied by the
window, ie. not the shadowed part.
not my ideal solution to the synchronization issue here, but I guess this is a
benefit of the unified tree
fix T3396
this is an event representing the "new" state of the surface after a
configure event. it must contain the exact states which could potentially
have changed in the configure in order to ensure synchronization between
csd states and window size.
ecore events for xdg-shell configures must be sent only upon receiving a
configure event since states are set by the compositor and not by the client
@fix
#hoorayforbeta
This renames the ecore_evas_wayland_window_get2 function to be
ecore_evas_wayland2_window_get before the 1.17 roll out.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
This code adds support for deferring of surface creation and showing
inside Ecore_Evas Wayland. This is needed for Enlightenment so that it
does not try to create or show surfaces until the compositor has had a
chance to sync globals. This fixes an issue where early surface
creation would cause a crash in the compositor due to globals not
being syncd.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Previously, when we started to resize an efl app, the size would
"jump" due to framespace being adjusted. This patch fixes that issue
and resize now works as expected.
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
If we acknowledge a configure from xdg during post render, we end up
breaking maximize of EFL clients inside Weston (and perhaps other
compositors). In order to fix that, we will now send the configure ack
post render but pre flush.
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
As we do not have the proper values for window geometry to be setting
it here, remove calls to set window geometry. We can more accurately
determine the window geometry from inside Elementary as it handles the
theme for the window borders.
@fix
ref T2919
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This fixes a potential issue where we may have been sending the
configure acknowledgement before applying the actual new configuration
to the surface. Sending the ack_configure during post-render ensures
that we have already rendered according to the new configure
(addresses deferred rendering issue).
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
To get the proper maximized and fullscreen states, we should be using
the ecore_wl2_window functions, not the ecore_wl_window functions
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
Summary: When an initial client application was shown and we tried to
resize it, the resize would jump by the amount of framespace. This was
because the xdg_surface@configure event would be sending window
geometry as the width/height params in the event. We need to account
for that in the callback of window configure and adjust size
accordingly.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This fixes an issue where maximizing a window would set improper xdg
surface window geometry. We receive window configure sizes based on
xdg surface window geometry, so we need to subtract framespace there
or else window size grows when maximizing/unmaximizing multiple times.
This also adjusts the call to xdg_surface_set_window_geometry to
account for framespace (Fixes T2842).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
This fixes an issue where maximizing a window would set improper xdg
surface window geometry. We receive window configure sizes based on
xdg surface window geometry, so we need to subtract framespace there
or else window size grows when maximizing/unmaximizing multiple times.
This also adjusts the call to xdg_surface_set_window_geometry to
account for framespace (Fixes T2842).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
Summary: When an initial client application was shown and we tried to
resize it, the resize would jump by the amount of framespace. This was
because the xdg_surface@configure event would be sending window
geometry as the width/height params in the event. We need to account
for that in the callback of window configure and adjust size
accordingly.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
This fixes an issue where maximizing a window would set improper xdg
surface window geometry. We receive window configure sizes based on
xdg surface window geometry, so we need to subtract framespace there
or else window size grows when maximizing/unmaximizing multiple times.
This also adjusts the call to xdg_surface_set_window_geometry to
account for framespace (Fixes T2842).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
Summary; This fixes an issue where maximizing efl/elm apps in Weston
and in Enlightenment would cause extra space to be left around the
window.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
in the case of operations which change framespace, rejecting resizes
at this point will cause the canvas to fail at resizing and result in a
partially-rendered canvas; the real canvas geometry must be calculated by
running the entire function in order to determine whether the resize is valid
fixes toggling borderless state of windows
when running in a wayland compositor, the ideal mode of operation is to
only prepare/send frames when the compositor has finished with the previous
frame
to achieve this, manual rendering can be toggled upon creating and completing
a frame callback, ensuring that a canvas never has multiple pending buffers at
any given time
fix T2784
when a render occurs, frame callbacks must be managed in order to ensure
successful rendering for future frames. the best place to do this is in the
engine here, since this is the lowest-level place which has access to both
the wl_surface as well as the evas rendering state
ref T2784
Summary: If we have already resized this ecore_evas to be what we
want, then there is no point in running the below resize code as we
should already be at the requested size. Add a test at the beginning
to see if we have already set these values
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
for framespace
Summary: As we have already adjusted for framespace in various code
leading up to a configure callback, don't adjust for it here. This
fixes an issue where xdg surface window geometry would get incorrect
values which were including framespace. The values of the
xdg_surface_set_window_geometry should be Just the geometry of the
visible window.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
processing updates
Summary: When processing render updates, we should be checking if the
Ecore_Evas "should be visible" property is set.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As we no longer need the wdata here (see previous commit), we
can remove the usage of this variable
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This function should really not be called here as it triggers
an xdg_surface_set_window_geometry call which (in turn) should only be
getting called when the window geometry (meaning visible region)
itself has changed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As we end up calling ecore_evas_wl_common_resize anyway,
there is no need for all these size calculations in the configure
callback. The resize function will deal with this anyway.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: If we are calling ecore_evas_object_cursor_set with a NULL
object, then we need to inform the ecore_wayland window that we no
longer have a cursor surface.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
engine
Summary: Frame callbacks are now handled inside the engine itself and
are thus not needed here anymore
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
configure event handler
Summary: This patch ports the fix for windows without a min/max size
being set over to the configure event handler (which was also not
taking into account the fact that Some windows may Not have a min/max
property set on them.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This fixes an issue for windows which do not set a min or max
size in the properties. This was discovered when running Enlightenment
in a Wayland-Only scenario, and trying to bring up the settings panel
which would cause an endless loop in calculating the proper window
size due to min/max not being set.
@fix
NB: Thanks to Mike for the help in tracing this ! :)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
xdg_shell protocol supports minimizing surfaces. When elm apps request
iconification, they will call ecore_evas_iconified_set which in turn
will make use of the newly added ecore_wl_window_iconified_set function.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Recent expedite changes have uncovered an issue where the ecore_evas
(under wayland) was not supporting async rendering correctly. This
fixes the issue so we can run expedite with -y and get redraws again.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
ecore_evas_cursor_object_set
NB: Previously, if we mad calls to ecore_evas_cursor_object_set to update the
mouse cursor hotspot, the mouse cursor would be repositioned at 0,0 on
the canvas due to x & y being set to 0,0. We fix that here by fetching
the current mouse position Regardless if we are changing the object or
not (ie: perhaps we are just updating the hotspot and not the object)
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@fix: As it turns out, we cannot just blindly set the regions here
during resize. Elementary apps will set the opaque region to account
for any edj frames, and having the region_set calls Here was
causing issues....
Signed-off-by: Chris Michael <cp.michael@samsung.com>
and update input & opaque regions after resizing.
@bugfix: We do not need to call ecore_wl_window_damage & commit here.
The damages are already handled in the evas engine for both shm & egl.
Those damages are sent to the compositor Already from the evas engine,
so we don't need to send the same damages twice. This reduces more
useless compositor redraws as we are not constantly sending damages &
calling commit twice for every frame.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this fixes a misbehavior with ecore evas object cursors when you set
one, the old one is deleted, but if the old is the same, the new one
you set gets deleted, rather than just updated.
@fix
Remove unused function and it's declaration. This function is not
being called from anywhere anymore, so it's no longer needed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Properly fix efl wayland elm window resize problem.
This adds support for min, max, step, aspect, and base size properties
when resizing a canvas under EFL Wayland.
This Also Properly fixes raster's report for EFL Wayland elm windows not
resizing properly. Previously, when resizing an elm window in wayland,
a portion of the window would draw outside the frame.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
outside the window).
Be sure that the EEs requested geometry gets updated in our
common_resize function After min/max have been taken into account.
Elm is using ecore_evas_request_geometry_get in it's resize_job code
(Why...I have no clue lol. Does not seem like a good thing to check).
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This callback must be manually destroyed and removed on
ecore_evas_hide(), because it won't be delivered anymore after the
surface is destroyed. If the callback still exists, the engine will find
it and avoid doing a new redraw until it is finally called.
Maybe the correct thing to do is to keep this callback in the
Ecore_Wl_Window struct, and have some functions to set/unset it, so it
gets destroyed when the window is hidden. Or when the surface is
destroyed.
Fix phab T392.
Notice that it should reopen T359, as it wasn't really fixed, but a
rotation with resize was being used when a non-resized rotation was
requested. The cause of the "protruding surfaces" is likely the fact
that Elementary is setting the opaque regions manually, instead of
leaving it to Ecore_Evas. This must be fixed either inside Elementary
itself, or adding the "surface extents" (shadow/non-visible surface
parts) info to Ecore_Evas too.
This reduces code duplication for ecore_evas resize routines inside
wayland engines by using a common _ecore_evas_wl_common_resize
function as the resize code for both engines was the same anyway.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
These two APIs will save the title and class_name inside
Ecore_Wl_Window, so if they are called before the shell surface is
created, the stored names will be used later when the window is finally
shown (shell surface is created).
This way we are also hiding the shell surface from ecore_evas modules.
This is a configure event info, so put it in the right place. Some
places adding edges info were also removed, which means that they were
redundant.
Tested with <Meta> + middle click resize, and with window border resize,
on all the edges. Apparently, nothing breaks.
Previously, a "maximize" of an efl client would not actually resize to
the provided size as it would account for framespace width & height.
This fixes that so now "maximize" is Actually maximized.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
needed.
NB: Currently, this will only work for fullscreen or maximized states
as other ones like sticky, withdrawn, iconic, etc, etc are not
supported via wayland protocol yet.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
duplicated code.
Resize the frame object before we update the window saved size.
Remove (again) call to _ecore_evas_wayland_resize and set the resize
edge of the window.
NB: The call to _ecore_evas_wayland_resize ends up sending duplicate
configure events here, hence whey it is removed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
NB: Not sure how/why this was here, but it's entirely Not needed and
leads to duplicate calls of wl_shell_surface_resize.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
- In common_render_updates_process, calls to window_damage will
Accumulate the damage, so add a call After to push damages.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
It is needed to set the engine internal borderless property.
Also update the border (frame) object, showing/hiding it as needed, and
updating the framespace size when the frame object is handled by the
engine.
If this Ecore_Evas already has a mouse inside it, there's no need to
send an additional mouse in event.
Additionally, always send a mouse_move event before a mouse_down, so the
Evas pointer position can be updated properly before the mouse down.
Now the opaque and input regions are updated on ecore_wl_window_resize,
there's no need to call ecore_wl_window_buffer_attach() for this
anymore.
The checks on alpha and transparent flags were also fixed.
ecore_wl_window_update_size() is now called by ecore_wl_window_resize(),
reducing duplicated code.
Since we don't have a changed state callback on Wayland, just call the
changed_state callback of Ecore_Evas from the configure callback.
There's no need to add the Ecore_Job that will send the event later.
This makes the code cleaner, simpler, and will call the callback when
the configure event is received, which is a good place to check for the
changes.
In the window_configure callback, reduce duplicated/not needed code.
Account for rotation when getting new size during common_rotation_set.
Reduce duplicated code in ecore_evas_wl_resize function and just call
the _common_resize function (as that already has most of this code).
Fix issue of Segfault on elm app closing:
- During hide we need to call evas_sync to make sure the async
render has flushed out everything that is pending.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Instead of moving the objects by adding the framespace offset to them,
use this offset when rendering them. This way there's no change in the
object's geometry/position, it works correctly with map, and will be
automatically updated in case that the framespace values change (for
instance if one sets a window to borderless).
There are 2 main places where changes were needed:
- output redraws, when they come from an object being changed, must be
add the framespace offset to their damaged area;
- checks to see if the object is inside a given rendering area, must
also add this offset, since the object is actually being rendered on
a different position;
Add 4 rectangles to be used as border of the window, instead of a single
rectangle under the framespace. This allows to move the frame object to
the top layer, instead of staying on the lowest layer. With the frame
over the other objects, there's no need of framespace clipper object,
which causes several bugs.
The real canvas size contains enough space for rendering the frame, but
ecore_evas_geometry_get() should be consistent accross all the engines
and report only the client area.