If enlightenment is built with support for wayland, then previously
the WBOD would not work if we were running the same binary with X11.
This was because the alert system would try to connect via drm by
default (due to wayland build option). We fix that by checking for the
existance of $DISPLAY (as this will not be present under drm), and
running the X11 codepath if it is found, running the drm codepath if
it is not found.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
assume that an object is where it's supposed to be in order to avoid failing
to correctly animate objects which modify set geometries, such as e clients
We need to make sure we drop reference on all exit paths through the
hide callback - somehow this only seemed to break internal windows.
ref 65166c5a36
==22088== Invalid read of size 1
==22088== at 0x2C9FE7B1: _evry_cb_show (evry.c:3046)
==22088== by 0x5BE9918: _eo_evas_object_cb (evas_callbacks.c:65)
==22088== by 0x69A16F4: _eo_base_event_callback_call (eo_base_class.c:715)
==22088== by 0x69A3041: eo_event_callback_call (in /usr/lib/libeo.so.1.17.99)
==22088== by 0x5BEA0B3: evas_object_event_callback_call (evas_callbacks.c:240)
==22088== by 0x5C2577C: evas_object_inform_call_show (evas_object_inform.c:12)
==22088== by 0x5C1ED24: _show (evas_object_main.c:1360)
==22088== by 0x5C1EADA: _evas_object_efl_gfx_base_visible_set (evas_object_main.c:1313)
==22088== by 0x575D80A: efl_gfx_visible_set (in /usr/lib/libefl.so.1.17.99)
==22088== by 0x5C1EA58: evas_object_show (evas_object_main.c:1291)
==22088== by 0x479FCF: _e_comp_intercept_show_helper (e_comp_object.c:1616)
==22088== by 0x47A02A: _e_comp_intercept_show (e_comp_object.c:1630)
==22088== Address 0x17621591 is 81 bytes inside a block of size 120 free'd
==22088== at 0x4C2AE6B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22088== by 0x2C9F95A8: _evry_window_free (evry.c:993)
==22088== by 0x2C9F8065: evry_hide (evry.c:366)
==22088== by 0x2C9FB9A2: _evry_cb_key_down (evry.c:1926)
==22088== by 0x8F6ED4A: _ecore_call_handler_cb (ecore_private.h:316)
==22088== by 0x8F6FC92: _ecore_event_call (ecore_events.c:518)
==22088== by 0x8F7A15A: _ecore_main_loop_iterate_internal (ecore_main.c:2339)
==22088== by 0x8F784A8: ecore_main_loop_begin (ecore_main.c:1284)
==22088== by 0x4403F6: main (e_main.c:1087)
==22088== Block was alloc'd at
==22088== at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22088== by 0x2C9F8D7D: _evry_window_new (evry.c:758)
==22088== by 0x2C9F772D: evry_show (evry.c:177)
==22088== by 0x2C9F711C: _e_mod_run_defer_cb (e_mod_main.c:537)
==22088== by 0x8F75267: _ecore_call_task_cb (ecore_private.h:282)
==22088== by 0x8F7574E: _ecore_idle_enterer_call (ecore_idle_enterer.c:174)
==22088== by 0x8F7A05B: _ecore_main_loop_iterate_internal (ecore_main.c:2261)
==22088== by 0x8F784A8: ecore_main_loop_begin (ecore_main.c:1284)
==22088== by 0x4403F6: main (e_main.c:1087)
this function is only called when screen geometry (or useful geometry) has
changed, and so all clients should have their geometries checked at this point
to ensure that they update for any new zone obstacle changes which have occurred
Wayland buffers are currently either ARGB or XRGB - we don't need to
convert either of these, we just need to set alpha appropriately - which
we now do.
This code is similar to code in weston, but doesn't really work properly
for us in E, since this can blow up buffers behind the async renderer's
back.
The rest of the reference code has been pushed into e_pixmap, so we can
kill this all now.
We need to keep wayland buffers around even if they'll never be written
to again. This is part of Buffer_Reference's task in weston, but we
already have our pixmap abstraction which can serve mostly the same
purpose.
Remove the "buffer reference" stuff from e_pixmap and replace it with a
kept buffer for the last commit.
Add shared memory pool references to keep pools from going away on us.
Mike Blumenkrantz
Chris Michael
Derek Foreman