calling `pulseaudio` starts a new daemon in the background. this is incorrect
behavior when a daemon already exists, so use --start. tracking the exe of
this process has no effect other than to determine when the fork()ing parent exits,
which is usually immediately
ref 35bb87529f
==21266== 3,488 (96 direct, 3,392 indirect) bytes in 2 blocks are definitely lost in loss record 10,417 of 10,680
==21266== at 0xE1E5D49: _eina_chained_mempool_alloc_in (eina_chained_mempool.c:212)
==21266== by 0xE1E5FDC: eina_chained_mempool_malloc (eina_chained_mempool.c:324)
==21266== by 0xE1A016E: eina_mempool_malloc (eina_inline_mempool.x:90)
==21266== by 0xE1A03C2: _eina_list_mempool_list_new (eina_list.c:222)
==21266== by 0xE1A11C5: eina_list_append (eina_list.c:578)
==21266== by 0x2910B667: _bar_fill (bar.c:1565)
==21266== by 0x2910D1A5: _bar_recalculate_job (bar.c:2047)
==21266== by 0xC602C2C: _ecore_job_event_handler (ecore_job.c:98)
==21266== by 0xC5FBBCE: _ecore_call_handler_cb (ecore_private.h:317)
==21266== by 0xC5FCB5D: _ecore_event_call (ecore_events.c:518)
==21266== by 0xC605EEB: _ecore_main_loop_iterate_internal (ecore_main.c:2381)
==21266== by 0xC603C99: ecore_main_loop_begin (ecore_main.c:1289)
==21266== by 0x43DD0D: main (e_main.c:1089)
there is no event that indicates that the mouse went to a other zone. To
solve this we simply update the current split type each time when
changing or using the type.
If someone starts to drag a client arround, then the client will shrink
into a icon, that now is always at the position of the mouse cursor, if
the drag ends, the client will be placed in the client currently below
it. The client will be placed in a place where the mouse cursor was
currently closer to.
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)
Small patch to reverse order of shell binding so that we always
support the newest shell first and fallback to older ones.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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