this makes evas ane ecore_fb agree on how to address the fb device.
this fixes terminology in fb on optimus (dual gpu) setups where you may
have to declare the exact fb to use (there are 2 of them, not just
fb0) and makes things consistent at least. this also should fix T253
Summary:
* efl.m4: add support for xterm-256color and fix display for the bsd echo. Fix autotools issue (present on Ubuntu also, but better handled).
* doc/Makefile.am: bsd echo may not handle -n option in sh
Reviewers: cedric
CC: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D329
This reduces code duplication for ecore_evas resize routines inside
wayland engines by using a common _ecore_evas_wl_common_resize
function as the resize code for both engines was the same anyway.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
[Problem] When glTextureDelete is called in image_cache_flush(), it sometimes doesn't work.
[Cause] glTextureDelete is called with the wrong eglContext.
[Solution] Call eng_window_use() in image_cache_flush() and image_cache_set() to use the correct eglContext.
Change-Id: Id7ab1aaeb456be6dbc5f09cb2731ace5399a5dce
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
them else wayland segfaults (internal wayland code does no safety
checks). Also, Fix some formatting while I am here...
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In evas_gl_api_ext_def.h there're calls such as:
_EVASGL_EXT_DRVNAME(EGL_KHR_image_base)
The macro is defined in evas_gl_api_ext.c as:
(strstr(glexts, #name) != NULL || strstr(glueexts, #name) != NULL)
if (_EVASGL_EXT_CHECK_SUPPORT(name)) *ext_support = 1;
But EGL_KHR_image_base is itself a macro, which is defined
in EGL/eglext.h like this:
Thus, the _EVASGL_EXT_CHECK_SUPPORT macro will unwrap into:
(strstr(glexts, "1") != NULL || strstr(glueexts, "1") != NULL)
instead of intended:
(strstr(glexts, "EGL_KHR_image_base") != NULL ||
strstr(glueexts, "EGL_KHR_image_base") != NULL)
This patch fixes this by applying stringification earlier in
_EVASGL_EXT_DRVNAME
Bugfix reported by jinhyung.jo@samsung.com
Linking to Pthread seems to be highly not portable. Look at lock.m4
macro if you want to understand the hell it is ! By following it
closely we should now have better portability than the 1.7.x release.
And of course than our alpha...
NOTE: EINA_VALUE_TYPE_DISPATCH_RETURN macro is a bit weird, it does
use external variable not passed to the macro and half of the parameter
given to it are just ignored...
ChunEon Park
Daniel Juyung Seo
Cedric BAIL
Carsten Haitzler
Ryuan Choi
Andrii Kroitor
Jean Guyomarc'h
Sebastian Dransfeld
Chris Michael
Cedric Bail
Wonsik Jung
Gustavo Sverzut Barbieri
Sung W. Park
Vorobiov Vitalii
Yakov Goldberg
Jihoon Kim
maxerba
Cedric Bail