We cannot use the texture to find a valid format Before the texture is
actually created. This is invalid, leads to "warning: tex is used
uninitialized' message from the compiler, and just plain wrong.
Instead, use the alpha property of the Evas_GL_Image to find the
proper texture format, Then create the texture.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We use conn here for a global Dbus connection variable as well as sometimes
in a local scope. Better rename the global one to avoid confusion and
potential failures when the code would fallback to the global one even if
the local scope should be used and the var was simply forgotten.
i hope this addresses CID 1229131 - don't trust the DISPLAY var
content much at all - limit it to [a-z][A-Z][0-9][-] only. hopefully
coverity is happier.
coverity pointed out a deadlock - CID 1226193. i hope this fixes it
(need to wait days for a coverity re-run). tests pass and real life
usage works, so i assume its ok. in theory i see no problem either.
in looking at CID 1230994 i noticed that eina_unicode_unicode_to_utf8
and eina_unicode_utf8_to_unicode are really dumb. they calloc an array
of bytes then proceed to fill them all in anyway. why? also the
realloc handing in eina_unicode_unicode_to_utf8 wasn't strictly corect
and could leak memory. so this just fixes silly slow code and a leak.
this addresses CID 1230994. as such eina_unicode_unicode_to_utf8()
always returns a nul terminated string. so it's guaranteed. but yes -
if string is 7 bytes or longer it will not put a nul byte on the
destination. as such for a single unicode char this can never happen
as in utf8 it's 6 bytes. but since eina_unicode_unicode_to_utf8()
safely returns a nul terminated string at all times - we can just use
strcpy safely. no need for strncpy. also handle null return from
eina_unicode_unicode_to_utf8()
so in fixing one CID for a format lookup failing and thus invalid mem
access, a possible leak was made in this case. fix that by doing
lookup before any allocation and if lookup fails, return there
this fixes CID 1230999 1230998 1230997
this fixes potential leak due to
ff652084e0 fixing a valgrind access
issue. make sure the server is in the list before handling error
conditions in case a callback sets delete_me (should never though).
gl_generic functions expect the Outbuf to contain the canvas, so we
fixed the eng_window_new function to accept that, And the engine info.
This simplifies the calls to eng_window_new.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Since we simplified the eng_window_new function to accept the canvas
and engine info, we need to update calls to that function
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We need to pass in the canvas and engine info structure as the
gl_generic engine needs the outbuf->canvas to be set.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Evas wayland_egl engine crashes on startup when it is running with mesa.
Evas is trying to get EGL / GLES extension function addresses where evas_gl_symbols.
It is called before eglGetDisplay. Then mesa considers that current egl platform is
X11 if it has no EGL_PLATFORM env var. This behavior of mesa is bad. But we should
provide workaround until it is fixed. Thus EGL_PLATFORM env var should be defined to
wayland before calling eglGetProcAddress.
@fix
Test Plan: run elementary_test under wayland with wayland_egl engine.
Reviewers: raster, stefan_schmidt, devilhorns
Reviewed By: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1312
this should fix T1508 - my testing seems to indicate so. test suite
succeeds, some manual tests of mine work. so is ay this is a good fix
that could fix critical segvs in apps using ecore-con - eg like
weather module in e
Chris Michael
vivek
Savio Sena
Stefan Schmidt
Carsten Haitzler
Cedric BAIL
Tom Hacohen
Gwanglim Lee