in the case where an app unmaps and maps its window very quickly, this
allows detection of the maprequest event which will occur with the just-deleted
manager window so that the window can be correctly managed again
fix T5348
this indicates that saved geometry has been set and should not be
updated during maximize
currently only used to handle transition from fullscreen -> maximize
it doesn't matter if the current client size doesn't match the unmax
size in this case since the size will be changed to fullscreen anyway
fixes maximize -> fullscreen transition
ERR<elementary>lib/elementary/elm_widget.c:1159 You passed a wrong parent parameter (0x4000005c7a973cf5 edje). Elementary widget's parent should be an elementary widget
technically action_client is used to indicate that an e_action is
active, but functionally it really just means "this client is moving or
resizing" and the compositor makes certain adjustments based on this
This reverts commit cd3490f35c.
this breaks many windows by preventing deferred resizing from occurring.
a window which is unable to resize at the time of this call must be queued
for a deferred resize, otherwise it may never resize at all and thus will
never be rendered
test case: screenshot dialog
animating comp objects persist after the lifetime of their client, so
ensure that functions which are likely to be called after the client's free
will not attempt to access client struct members
==13853== Invalid read of size 8
==13853== at 0x5C7C56: _e_comp_wl_surface_destroy (e_comp_wl.c:1804)
==13853== by 0xA999971: destroy_resource (wayland-server.c:611)
==13853== by 0xA9A06F4: for_each_helper (wayland-util.c:374)
==13853== by 0xA9A073F: wl_map_for_each (wayland-util.c:387)
==13853== by 0xA999C87: wl_client_destroy (wayland-server.c:763)
==13853== by 0xA999216: wl_client_connection_data (wayland-server.c:283)
==13853== by 0xA99C2B0: wl_event_source_fd_dispatch (event-loop.c:90)
==13853== by 0xA99CC11: wl_event_loop_dispatch (event-loop.c:423)
==13853== by 0xA787AC0: _cb_create_data (ecore_wl2_display.c:272)
==13853== by 0xDBE984D: _ecore_call_fd_cb (ecore_private.h:333)
==13853== by 0xDBEC01B: _ecore_main_fd_handlers_call (ecore_main.c:1992)
==13853== by 0xDBEC8A9: _ecore_main_loop_iterate_internal (ecore_main.c:2379)
==13853== by 0xDBEA672: ecore_main_loop_begin (ecore_main.c:1292)
==13853== by 0x441DA9: main (e_main.c:1089)
==13853== Address 0x30ba5d90 is 176 bytes inside a block of size 1,424 free'd
==13853== at 0x4C2ED4A: free (vg_replace_malloc.c:530)
==13853== by 0x4603D6: _e_client_free (e_client.c:588)
==13853== by 0x5475A8: e_object_free (e_object.c:119)
==13853== by 0x5477C4: e_object_unref (e_object.c:152)
==13853== by 0x5473D7: e_object_del (e_object.c:60)
==13853== by 0x5C7C51: _e_comp_wl_surface_destroy (e_comp_wl.c:1803)
==13853== by 0xA999971: destroy_resource (wayland-server.c:611)
==13853== by 0xA9A06F4: for_each_helper (wayland-util.c:374)
==13853== by 0xA9A073F: wl_map_for_each (wayland-util.c:387)
==13853== by 0xA999C87: wl_client_destroy (wayland-server.c:763)
==13853== by 0xA999216: wl_client_connection_data (wayland-server.c:283)
==13853== by 0xA99C2B0: wl_event_source_fd_dispatch (event-loop.c:90)
==13853== by 0xA99CC11: wl_event_loop_dispatch (event-loop.c:423)
==13853== by 0xA787AC0: _cb_create_data (ecore_wl2_display.c:272)
==13853== by 0xDBE984D: _ecore_call_fd_cb (ecore_private.h:333)
==13853== by 0xDBEC01B: _ecore_main_fd_handlers_call (ecore_main.c:1992)
==13853== by 0xDBEC8A9: _ecore_main_loop_iterate_internal (ecore_main.c:2379)
==13853== by 0xDBEA672: ecore_main_loop_begin (ecore_main.c:1292)
==13853== by 0x441DA9: main (e_main.c:1089)
==13853== Block was alloc'd at
==13853== at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
==13853== by 0x5471A4: e_object_alloc (e_object.c:20)
==13853== by 0x467AD5: e_client_new (e_client.c:2596)
==13853== by 0x5C7F11: _e_comp_wl_compositor_cb_surface_create (e_comp_wl.c:1858)
==13853== by 0xADBDC57: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
==13853== by 0xADBD6B9: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==13853== by 0xA99EEED: wl_closure_invoke (connection.c:935)
==13853== by 0xA999581: wl_client_connection_data (wayland-server.c:371)
==13853== by 0xA99C2B0: wl_event_source_fd_dispatch (event-loop.c:90)
==13853== by 0xA99CC11: wl_event_loop_dispatch (event-loop.c:423)
==13853== by 0xA787AC0: _cb_create_data (ecore_wl2_display.c:272)
==13853== by 0xDBE984D: _ecore_call_fd_cb (ecore_private.h:333)
==13853== by 0xDBEC01B: _ecore_main_fd_handlers_call (ecore_main.c:1992)
==13853== by 0xDBEC8A9: _ecore_main_loop_iterate_internal (ecore_main.c:2379)
==13853== by 0xDBEA672: ecore_main_loop_begin (ecore_main.c:1292)
==13853== by 0x441DA9: main (e_main.c:1089)
this used to be set on show since the assumption was that show was the
first time the client would be seen, but this turns out to be incorrect
and results in focus being set too early (breaking policy)
improve mixer volume display in titlebar now to show a unified
display. average volume of all non-muted sinks for volume display and
if at least 1 sink is non-muted display as not muted as some sound is
coming from that app... somwhere...
when resume is called we are just notifing the theme that e is back
there. There is no E_Sys_Action for it, so its enough for now to just
call the backlight to fade back in and emit the signal to the theme.
This should fix e blocking sys actions
so add a new sink or get an update on state and e will SEt volume/mute
settings, not just passively disdplay them. this has been messing up
rage's winlist (mouse over on right) for several months now... and e
is/was wrong.
this doesnt fix all. if an app has multiple streams really this client
mixer needs to display a control per stream, not a single one - eg in
a popup. in fact volume shoud likely be done in a popup instead of
inside titlebar anyway :)
but this fixes the most annoying problem where withotu users doing
anything, the audio starts to play from streams explicitly muted by
the app...
warning found a bug - filling in chr fileds with an api that expects
ptrs to ints - this is doing really bad things like unaligned writes
and it's overiting adjacent memory. fix
we did cast to Evas_Native_Surface * but this just causes warnings due
to the input ptr being char * from memcup. as this will be aligned due
to allocation, we're ok, so use a void * cast instead
we're pointer playing anyway so types here are not really useful. we
have to get our ptrs right - including alignment, and these warnings
are not useful and just noise.
this clears up soem warnings and do the cast on providing the pointer
to ecore_x_window_prop_property_get() which since it has to allocate
the data will be fine for alignment anyway, so a void * cast will do.
so we cast a lot of ptrs to other types as that is then the actual
type of the object. all these objects are allocated by malloc nad
friends so this is ok. but gcc on arm is not happy and warns. maybe it
assume this ptr could be to an element in an array of structs of this
type and so on thus will have specific alignment enforced by compiler
but our casting may disturb it? anyway. cast via void first fixes it.
we can focus on other real warnings and errors instead.
this is a remnant from xdg5-only code where new_client meant "first buffer". with
xdg6, this is no longer the case since a surface can receive infinite commits
without ever having a buffer attached
ref 9a82f7bcb0
xdg6 allows for clients without buffers to be configured such that the
first buffer will match the configured state
if a client is sized before this point, the changes.size flag will be set
UNIGNORE is the hook to watch for wl clients as they are added; the
ignore mechanism prevents most of the compositor from processing
clients. this is a stupid method from an api perspective since it's
different in x11 and wl, so it should probably be improved on in the future
manually initializing this meant it needed to be kept in sync with the
header, something that I'm unlikely to check every time client hooks are
added/removed
This reverts commit e1c3120689.
this commit revealed a number of issues with the xdg6 implementation related
to unconfigured buffer management: see subsequent patches for a less
sledgehammer-y solution
ref 5497fadce4
xwl clients will attempt to unset the cursor when mousing out of the surface,
but this can happen after evas events are triggered for the ssd due to
latency
if the given surface has mouse.in set, but the mouse is not inside the surface
area, assume that the mouse has just entered the compositor canvas
#TheDisappointer
in the case where clients are deleted during the same loop that they are
added to an exe_inst, the client will be destroyed before the instance's
delete event returns
ref T4963
this is an easy format string attack vector which serves no purpose
that I can fathom. the commit log where it was added it also made
no mention of this, as it was done in a seemingly-unrelated feature
addition
let's say you sue tiling or some module and it wants a window by
default to maximize or fill the screen or be size XxY ... this stops
the client first having a buffer smaller (or larger) and then sizing
down rendering 2 times (one of the renders is pointless). this makes
initial buffer render/show seamless as it should be in wayland.
in case eina_init uses env vars, move it to befor setuid() so it can
detect. you normally would setuid only for a limited op and we do it
for "the rest of the running" as e_sys is fairly simple.
So yeah, I've literally used sed to replace every occurrence of
ecore_time_add() with ecore_timer_loop_add() because I'm reasonably
confident that no part of E has a legitimate need for timer based on the
exact current time.
It would be really nice if I'm not wrong. :)
The reason for this is the incredible spew of clock_gettime() calls I'm
seeing on an ARM system (that should have a vdso for gettime, but...)
This can amount to thousands of system calls per second.
#YOLO
this shortens logout timeout for "apps still hanging around" to 3
seconds meaning that within 3 seconds something should complain that
logout is taking too long so you know your logout request actually
went through... and any app not responding in 3 seconds is likely
"bad" (swapped out, hung on blocking i/o or something or doing a "are
you sure" dialog thing).
keys of pointer hashes are represent as void** so you just get a pointer
to where the pointer can be found. This now dereferences the pointer so
the correct value is used.
This fixes T5136.
this should keep the perfromance of the prior commit
f80f73a7c9 and now get quality back by
generating thumbnails at higher resolution then scaling down from there.
@fix
bgp[review uses livethumb. livethumb by definition uses an image
canvas with a sw engine and thus not only renders the bg with another
engine, it also is causing continual texture uploads thanks to the
pager and this shows clearly on slow systems. this causes memory
duplication for the same wallpaper as ever bg has its own canvas and
buffer etc.
this does come with a quality drop though and that's up for debate. we
COULD use something else like a proxy or map in between to force a
higher "virtual" res vs output. but for now at least this solves both
a memory bloat issue and a performance problem.
@fix
this moves ensuring windows are centered on their parent even when
moved etc. for stack (and move the whole stack not just the specific
window) in the idle enterer int he pahse before all the client evals
take place. much cleaner!
Reverting this as it ends up causing multiple events being handled
(touch and pointer) inside various clients if you have both touch and
pointer enabled. Will need a different fix here....
This reverts commit 7906537c02.
Small patch to enable sending wl_touch down/up events when pointer
mouse button events are handled. This is needed in the case where we
do Not have any mouse pointer at all, but we do have touch support.
ref T5094
NB: This allows weston-simple-touch client to operate in Enlightenment
now. There is still something strange happening with EFL clients in E
wrt touch events tho...
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so on 1 intel laptop and my rpi i'm seeing 100% cpu usage in wayland
mode. it seems something is resizing to 0x0 and then causing a size
change which causes a property change which causes... another request
to 0x0 and repeat. dont set tyhe size changed flags if size actually
didnt change and this fixes that.
Mike Blumenkrantz
Carsten Haitzler
Al Poole
Chris Michael
Michael Bouchaud
Stephen 'Okra' Houston
Marcel Hollerbach
Derek Foreman