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.
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.
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.
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.
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 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
==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)
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.
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
* 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
==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
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.
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
This is a gadget using the new api that has separate gadgets for battery, temperature, net status, cpu load, mem usage, cpu frequency, and one gadget called sysinfo that combines all of the above.
I mean really, I don't know why I write code like this, it makes
everyone around me so sad.
(commit log by Derek, paraphrased from an irc conversation)
segv if u go do make installs that install desktop files causing
efreet to recheck desktop files causing e to reset desktop files
causing ibar to refill icons but this causea a segv if a hover menu of
windows for that icon are up at the same time. this fixes that.
@fix
now they can be trule async hopefully stopping things like application
menu from stalling while loading icons header... which is really nasty
with svg's. this actually makes icons async by default which is really
EXACTLY what you want. this also prepares for later making edje loads
async.
@feature
appmenu is annoying in that is hides on focus out whish is what
happens when a menu is popped up! fix this and make a qhick
click+release work as well! if we are going to have a global app menu
then let's make it vaguely decent... :)
also get menu positioning right with item geometry itself for the menu
not pointer position AND get menu pop direction correct based on
gadcon orientation.
@fix
this also should apply to calculating height correctly given a known
width - ie horiz or vert taskbar in a shelf. without this you can't
calc min size correctly from the theme.
@fix
this makes tasks behave like you'd expect with a stack - only show the
top one and track properly. tasks was simple and easiest to do first
as it has little fluff other than the tasks logic itself. other
elements of e next...
This patch makes the mouse pointer disappear when the physical mouse
device is unplugged. It also makes the mouse pointer reappear when a
physical mouse is hotplugged.
NB: There is one small hiccup with this patch and that is: when you
re-plug the mouse in the pointer itself doesn't show until you
physically move the mouse. Tried several things locally to sort it
out, but no success :/
Signed-off-by: Chris Michael <cp.michael@samsung.com>
the sizing issue in all of these tickets was caused by the "empty" object
being deleted, thus allowing the box to reset to 0x0 size hints and
returning this value as the overall size during recalc; the result is that
all icons would be sized at 0x0 instead of using the preserved orient size
as expected
fix T4509, T4647, T4830, T4733, T4524
the assumption that this code was making assumptions about elm_box
internals based on a shallow reading of the code was incorrect, and
the resulting "fix" (and subsequent attempts to bandaid it) has left these
gadgets in an unusable state for the past half year.
disappoint.jpg
this reverts the following commits:
f97f8f61acebfa4a97cd50030dc69342aa6be359504706d45ab1f608c5e6b107dc1cdc3fc195cd9f
each poll - check if temp actually changed and only send edje message
if tempt actually did change. saves some cpu while polling in the bg
for these things.
@optimize
Mike Blumenkrantz
Marcel Hollerbach
Michael Bouchaud
Michaël Bouchaud (yoz)
Stephen 'Okra' Houston
Carsten Haitzler
Chris Michael
Al 'netstar' Poole
Davide Andreoli
Derek Foreman
Stephen Houston