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)
This reverts commit fba185798c.
There is not even a description why you reverted it. This is a bugfix
that fixed a bug. So talk to me what the issue is, but please stop
reverting commits silently.
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 i have a situatioon where pulse is not started automagically. if
e's mixer it set to pulse... then stick to it, run pulse and keep
trying to connect every 0.2 sec until connection works. this makes
sound "just work" tm as it should...
@fix
This commit enhance the e_client_volume popup. Now you could see which sink
belongs to an e_client and allow you to control it. Sadly I haven't added a
scroller to this popup, I will add it later. Lots of calcs is needed to
display it correctly.
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
alignment warnings are anal and seem to not like casting allocated
structs nicely ... but they are noise that hides real issues, so
silence these as these casts/ptrs are ok after inspection.
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
display really isn't uninitialized due to the logic, but compielr is
kind of right in theory... but less warnings is better so we fix the
real problems more easily. fix.
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.
gcc on arm is actually validly complaining about us using int * ptrs
to point to char * data and thus it likely be unaligned, so work in
reverse. make the data int * aligned and when needed mess with it as
char * data byte by byte. warnings gone.
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
this avoids conflicts with efl internals, which will break entirely
when DISPLAY is set under wayland, and xwayland internals, which will
abort immediately when efl tries to connect to it during its init phase
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
==25839== 8,576 (6,432 direct, 2,144 indirect) bytes in 134 blocks are definitely lost in loss reco$
==25839== at 0xE812A41: _eina_chained_mempool_alloc_in (eina_chained_mempool.c:212)
==25839== by 0xE812CD4: eina_chained_mempool_malloc (eina_chained_mempool.c:324)
==25839== by 0xE7CCFED: eina_mempool_malloc (eina_inline_mempool.x:90)
==25839== by 0xE7CD241: _eina_list_mempool_list_new (eina_list.c:213)
==25839== by 0xE7CE044: eina_list_append (eina_list.c:569)
==25839== by 0x29E2CF07: _bar_check_for_duplicates (bar.c:58)
==25839== by 0x29E30D7F: _bar_cb_exec_client_prop (bar.c:1281)
==25839== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==25839== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==25839== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==25839== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==25839== by 0x441C04: main (e_main.c:1093)
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
==10821== Invalid write of size 8
==10821== at 0x28168A4B: _list_del (e_mod_config.c:455)
==10821== by 0x78F6C78: _eo_evas_object_cb (evas_callbacks.c:192)
==10821== by 0xE597F3A: _event_callback_call (eo_base_class.c:1422)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x7932A4D: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:1012)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x78F7537: evas_object_event_callback_call (evas_callbacks.c:364)
==10821== by 0x7932C9B: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1042)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== by 0x7932565: evas_object_del (evas_object_main.c:902)
==10821== by 0x510EC99: _elm_widget_efl_canvas_group_group_del (elm_widget.c:461)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x505ACC0: _elm_layout_efl_canvas_group_group_del (elm_layout.c:813)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x7946ED7: evas_object_smart_del (evas_object_smart.c:1076)
==10821== by 0x7933114: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1095)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== by 0x7932565: evas_object_del (evas_object_main.c:902)
==10821== by 0x510EC99: _elm_widget_efl_canvas_group_group_del (elm_widget.c:461)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x4F4D549: _elm_box_efl_canvas_group_group_del (elm_box.c:412)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x7946ED7: evas_object_smart_del (evas_object_smart.c:1076)
==10821== by 0x7933114: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1095)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== Address 0x2c731708 is 184 bytes inside a block of size 456 free'd
==10821== at 0x4C2ED4A: free (vg_replace_malloc.c:530)
==10821== by 0x28165F69: _free_data (e_mod_config.c:249)
==10821== by 0x49D92E: _e_config_dialog_free (e_config_dialog.c:156)
==10821== by 0x546D2F: e_object_free (e_object.c:119)
==10821== by 0x546F4B: e_object_unref (e_object.c:152)
==10821== by 0x546B5E: e_object_del (e_object.c:60)
==10821== by 0x49E233: _e_config_dialog_cb_dialog_del (e_config_dialog.c:333)
==10821== by 0x546B34: e_object_del (e_object.c:58)
==10821== by 0x4AA23C: _e_dialog_cb_key_down (e_dialog.c:357)
==10821== by 0x78F6CB4: _eo_evas_object_cb (evas_callbacks.c:199)
==10821== by 0xE597F3A: _event_callback_call (eo_base_class.c:1422)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x7932A4D: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:1012)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x78F7537: evas_object_event_callback_call (evas_callbacks.c:364)
==10821== by 0x7906AD8: _canvas_event_feed_key_down_internal (evas_events.c:3112)
==10821== by 0x7909281: _evas_canvas_event_key_cb (evas_events.c:3960)
==10821== by 0xE597E57: _event_callback_call (eo_base_class.c:1399)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x65FDE63: _direct_key_updown_cb (ecore_evas.c:4664)
==10821== by 0x65FDFC9: _ecore_evas_input_direct_cb (ecore_evas.c:4692)
==10821== by 0x6813D6E: _ecore_event_evas_key (ecore_input_evas.c:429)
==10821== by 0x6814A8D: ecore_event_evas_key_down (ecore_input_evas.c:707)
==10821== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==10821== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==10821== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==10821== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==10821== by 0x441BB4: main (e_main.c:1093)
==10821== Block was alloc'd at
==10821== at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
==10821== by 0x28165773: _create_data (e_mod_config.c:182)
==10821== by 0x49DBBC: _e_config_dialog_go (e_config_dialog.c:204)
==10821== by 0x49D4E9: e_config_dialog_new (e_config_dialog.c:80)
==10821== by 0x28165625: _xkb_cfg_dialog (e_mod_config.c:141)
==10821== by 0x49EACF: e_configure_registry_call (e_configure.c:72)
==10821== by 0x314400C3: _e_mod_run_cb (e_mod_main.c:165)
==10821== by 0x53DA23: _e_menu_active_call (e_menu.c:2045)
==10821== by 0x53F7CC: _e_menu_cb_mouse_up (e_menu.c:2778)
==10821== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==10821== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==10821== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==10821== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==10821== by 0x441BB4: main (e_main.c:1093)
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
Now the gadget show EXACTLY the same values of the free command on my machine,
but note: I found at least 3 different implementation of procpc so your values could be a bit different.
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).
It's hard to mimic "free" output parsing /proc/meminfo... we should really use sysinfo.h
directly (like free does).
btw, on my system now the values are really near the "free" output
Summary:
The problems were that both sysctl implementations defined public accessable fields named bat.
The static definition moves into the file scopes.
The E_FREE calls are fixing a use after free.
Reviewers: zmike!, bu5hm4n
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4629
It now show lots more usefull information.
The actual values still need to be adjusted, the goal is to show the exact same values of the "free" command
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.
* collect more info than just 2 percentage
* improve performance by parsing proc only onece every loop
* use active memory to calc percentage, now the value is near the other mem tools I have
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
==15191== Invalid read of size 8
==15191== at 0x2B6328A7: eina_list_next (eina_inline_list.x:32)
==15191== by 0x2B637520: _bar_empty (bar.c:1405)
==15191== by 0x2B639301: _bar_recalculate_job (bar.c:1958)
==15191== by 0xDBDA800: _ecore_job_event_handler (ecore_job.c:98)
==15191== by 0xDBD3AC6: _ecore_call_handler_cb (ecore_private.h:317)
==15191== by 0xDBD4A55: _ecore_event_call (ecore_events.c:518)
==15191== by 0xDBDDABF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==15191== by 0xDBDB86D: ecore_main_loop_begin (ecore_main.c:1290)
==15191== by 0x441A94: main (e_main.c:1093)
==15191== Address 0x1ff97dc8 is 6,520 bytes inside a recently re-allocated block of size 8,192 alloc'd
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>
note that the max/percent calculation are still wrong.
Seems the first cur calc give a huge value, that go into max and prevent any other perc calc to be correct.
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.
This seems like just some copy/paste that was never corrected, however
when calculating coordinate adjustments we should be using the proper
values here. Previous code was using e_comp_canvas_x_root_adjust for
the Y value. This patch uses e_comp_canvas_y_root_adjust for Y
coordinates.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this isnt used so it just adds complexity/code to work on. remove it.
it would need a rewrite anyway as using a single file is hugely
inefficient as eet has to doa full rewrite of the file every
modification... it also duplicated icons in memory and dint load
directly from file etc. so... remove anyway.
I really don't like this implementation (taken from the clock gadget).
If you know a better way to get the aspect from an elm layout please let me know
if "theme is transparent" and this is an issue - dont use that theme.
very simple. the theme for a desk LOCK should be solid. it should hide
what is underneath. that is the POINT is can have transition effects
and that is why we shouldnt hide what is under it to allow that to
happen otherwise if you do have such an effect (eg a fade in) you just
get a black screen instantly on ctrl+alt+l for lock for example THEN
it fades in which is not how things SHOULD look.
yes - there is an issue on locking on screen lock where you get an
initial fade in effect for example as desklock is shown LATER like
when screen "unsuspends" from blank rather thanbefore this point. that
is orthogonal. this rect should block events... not pixels. don't use
non-solid themes or images if you dont want to see through...
Mike Blumenkrantz
Marcel Hollerbach
Michael Bouchaud
Michaël Bouchaud (yoz)
Stephen 'Okra' Houston
Carsten Haitzler
Chris Michael
Al 'netstar' Poole
Derek Foreman
Davide Andreoli
Stephen Houston