since the conversion from dbus -> ecore-ipc, efreetd has failed to
notify when a cache build has completed, instead only sending the current
state of the desktop cache: not built
fix T2733
@fix
in the case that pointer mode is changed on an object at any time after
a grab has been acquired by the object, grabs/flags must be adjusted for
this and other "pointer-in" objects in order to avoid permanently
breaking canvas events
@fix
I have no idea what this mode was intended to do since there are no docs
and the related code in evas events is undocumented, so I can only speculate.
what I can say for certain is that this mode does grab, in opposition to its name,
and that until this commit any object which sets this pointer mode will
permanently break mouse eventing on the canvas
ref evas SVN 67264
@fix
when changing the type of a part which already has descriptions, it's
necessary to avoid copying any of the previous type-specific desc data
this should be the last of them...
@fix
in the case where a part is inherited, changing the type will lead to
broken part/program lookups for the part during resolving in write-out;
memcpy alone is not enough to fix this.
@fix
==24030== Invalid read of size 1
==24030== at 0x4A0AC77: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x598A9DC: _eet_dictionary_lookup (eet_dictionary.c:69)
==24030== by 0x598AA93: eet_dictionary_string_add (eet_dictionary.c:103)
==24030== by 0x598107B: eet_data_put_string (eet_data.c:857)
==24030== by 0x598213F: eet_data_put_type (eet_data.c:1433)
==24030== by 0x59895AB: eet_data_put_unknown (eet_data.c:4798)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x59894A4: eet_data_put_array (eet_data.c:4760)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5989617: eet_data_put_unknown (eet_data.c:4807)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5983E06: eet_data_write_cipher (eet_data.c:2396)
==24030== by 0x5983E92: eet_data_write (eet_data.c:2412)
==24030== by 0x406BC2: data_thread_head (edje_cc_out.c:674)
==24030== by 0x406D51: data_write_header (edje_cc_out.c:717)
==24030== by 0x40B52E: data_write (edje_cc_out.c:2439)
==24030== by 0x40563D: main (edje_cc.c:399)
==24030== Address 0xf45cb7b is 0 bytes after a block of size 347 alloc'd
==24030== at 0x4A089C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x414BAC: mem_alloc (edje_cc_mem.c:15)
==24030== by 0x41B66A: st_filters_filter_file (edje_cc_handlers.c:4718)
==24030== by 0x410EDA: new_statement (edje_cc_parse.c:229)
==24030== by 0x41227C: parse (edje_cc_parse.c:719)
==24030== by 0x412E5C: compile (edje_cc_parse.c:1044)
==24030== by 0x405624: main (edje_cc.c:394)
==24030==
==24030== Invalid read of size 1
==24030== at 0x4A0AC77: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x598AAFB: eet_dictionary_string_add (eet_dictionary.c:109)
==24030== by 0x598107B: eet_data_put_string (eet_data.c:857)
==24030== by 0x598213F: eet_data_put_type (eet_data.c:1433)
==24030== by 0x59895AB: eet_data_put_unknown (eet_data.c:4798)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x59894A4: eet_data_put_array (eet_data.c:4760)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5989617: eet_data_put_unknown (eet_data.c:4807)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5983E06: eet_data_write_cipher (eet_data.c:2396)
==24030== by 0x5983E92: eet_data_write (eet_data.c:2412)
==24030== by 0x406BC2: data_thread_head (edje_cc_out.c:674)
==24030== by 0x406D51: data_write_header (edje_cc_out.c:717)
==24030== by 0x40B52E: data_write (edje_cc_out.c:2439)
==24030== by 0x40563D: main (edje_cc.c:399)
==24030== Address 0xf45cb7b is 0 bytes after a block of size 347 alloc'd
==24030== at 0x4A089C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x414BAC: mem_alloc (edje_cc_mem.c:15)
==24030== by 0x41B66A: st_filters_filter_file (edje_cc_handlers.c:4718)
==24030== by 0x410EDA: new_statement (edje_cc_parse.c:229)
==24030== by 0x41227C: parse (edje_cc_parse.c:719)
==24030== by 0x412E5C: compile (edje_cc_parse.c:1044)
==24030== by 0x405624: main (edje_cc.c:394)
@fix
since it's now possible to inherit parts, it's possible that inheriting from
a different part type can lead to memory errors in the case where one part
has a larger desc struct than the other
@fix
this is not ideal since it triggers a client-side rerender of every object
which was clipped to the master clip (double render) and then this ends up
forcing the server to rerender the same area twice as well
not only that, it causes all surface damages to to be the size of the entire
window - framespace for every frame
@fix
while not occurring immediately before flush as in sync rendering, this
is functionally close enough that it will serve the purpose for which the
callback was intended, namely receiving a callback that occurs after render
update calculations have occurred but before flush happens
@fix
ref cbb447c878
Summary:
In case of RTL, the "custom" state properties does not apply. It happened because we don't copy the latest src to
dst in set_state(PART:.., "custom", 0.0); in case of dst is already populated.
We should copy the updated src to dst whenever we set the new custom description.
@fix
Reviewers: cedric, raster, jpeg, zmike, jaehwan
Subscribers: kimcinoo, seoz, jpeg
Differential Revision: https://phab.enlightenment.org/D3394
* use safety macros for win struct param (should be the case for all fns here)
* sanitize bool params
* enforce window state flag setting
* correctly detect window state using window flag instead of type
@fix
ref T2841
having window types for fullscreen/maximize is not defined by spec and leads
to state mismatches when toggling from api vs receiving events from the compositor
@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 brings ecore_wl_window_maximized_get more inline with
ecore_wl_fullscreen_get function in that it will now check either the
window maximized state, or the window type, to determine if a window
is actually maximized
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This fixes an issue where ecore_drm was sending an initial mouse_move
event too early in the startup process. Instead, we will send the
event from Ecore_Evas after it has been registered with Ecore_Input.
This is done here to address and Fix T2854.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We cannot be sending an ecore_event for mouse move here as it is too
early in the startup process for that too happen. Raising the event
here never gets caught because the ecore_evas has not yet registered
for ecore_input listening.
@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
Summary:
The initial values for map.zoom.x(y) should be [1.0]: it means 100%.
The values from newly builded edj has been set properly.
But, if a part from old *.edj turns on map feature, map.zoom.x(y) will be set [0.0]: it means 0%.
So, the part will be invisible. We need to initialize these values.
@fix
Test Plan:
1. Build a *.edc file which has a part with [description.map.on: 1;] in EFL 1.13.
2. See it works well in EFL 1.13.
3. Install EFL 1.14 or laters.
4. See the part is disappear.
Reviewers: Hermet, jpeg, cedric
Reviewed By: cedric
Subscribers: jiin.moon
Differential Revision: https://phab.enlightenment.org/D3302
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Commit 0cd59bb1 introduced the use of basename()
which needs libgen.h (hence winsock2.h before) on Windows.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
As we no longer have an fd handler to listen on the drm fd, we don't
need this function anymore
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As we already call drmHandleEvent when we pageflip, we don't
need to be using an fd handler to catch them. This should fix T2791
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: If we already have a pending pageflip scheduled for a given
framebuffer, don't reschedule another one. This also includes a minor
fix when mmap'ing the framebuffer (previously was also mapped
PROT_READ).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: drmHandleEvent will return 0 on success, or -1 on error. We
should trap for the error case so that we can cleanup any allocated
callback structures.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: In efforts to reduce tearing in the gl_drm engine, implement
support for eglSetDamageRegionKHR to mark parts of a surface as being
damaged.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In efforts to reduce tearing in the gl_drm engine, find and link to
the eglSetDamageRegionKHR function so we can mark damaged regions of a
surface
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Daniel Juyung Seo
Mike Blumenkrantz
Carsten Haitzler
Hein-Pieter van Braam
Amitesh Singh
Stefan Schmidt
Chris Michael
Cedric BAIL
Youngbok Shin
Shinwoo Kim
Vincent Torri
Jean-Philippe Andre