Ecore_Audio.h had #ifdef HAVE_PULSE ... and that is just so wrong as
this is something an ap[p may or may not set in its config.h ... but
this certainly hase no place in our public headers. the api's there
should always be there... symbols always... just imtplementation may
be empty ... though ecore_audio doesnt build at all without pulse...
so it's moot.
so fix this build issue i found when fixing e build issues with meson
changes etc.
@fix
Some systems have dri devices that can't mode set, and if they're first in
the directory they'll get picked by our code and things fall apart later.
So, open the potential device and ensure it has basic functionality before
selecting it.
This is a little inefficient as it gets the device via elput twice before
it can be used - this will be addressed later as the changes are a little
more invasive to optimize.
csd attempts to create sw cursors if the pointer surface doesn't exist,
so create the pointer surface before the csd to avoid duplicate cursors
#TheDisappointer
this should be unmapped so edje stops trying to render to it, though
at some point it could be optimized to not hide and just reuse the buffer
when showing again
#IGot99TicketsBut1x1AintOne
Just because the #define is present doesn't mean the extension is, so we're
BAILing on egl completely on some systems for no good reason at all. (saw
this on an SGX stack)
This is still wrong. I don't want to try too hard until after the upcoming
release, though.
We should actually be testing for the presence of client extensions before
attempting to do any of this. It's entirely possible that a gl stack will
return bogus functions for these from eglGetProcAddress
asking for an x- field from a desktop shouldnt result in null safety
checks IF the x hash is null - it's fine if it's null - that field
just doesn't eixst. if other fields were in the x hash but the desired
one wasn't it'd not complain, so why complain if there is just no x
hash?
fname would have been leaked if we failed to get a file_handler.
Also make sure we always create a new fname strbuf even without
a output_dir present to fix a potential unbalance between creating
and freeing.
CID: 1378112
it seems like the visibility is evalulated from different parent
relations, Just because the box (that is a container of a element) is
not visible, does not mean that the element in it is also not visible,
this somehow comes back to the box beeing deleted, the children beeing
reparented in evas, but not in elm. This is for now just a quickfix,
since those calls are just for optimization.
This fixes a load of errors once the elm_test window is closed
@fix
This fixes a crash in make check when --profile=dev is explicitely
enabled. eina_list_init() is called by the standard eina_init() loop
and by eina_debug_init() as well.
Honestly I'm not sure why it doesn't crash for other people as
well...
The crash was in eolian_suite during the second eina_init (called
from eolian_init).
Ooops! When mapping for writing we can't use the same code
path as when tofree is true. This restores the path for image
writing. This basically fixes rage with GL engine.
See also 45c8e5e983
Summary:
Actual slider value is not changed.
So when user release mouse or touch, slider value is returned
to the value by user set.
This is a partial revert of f41e276160
Fixes T5745
Test Plan: elementary_test -> slider
Reviewers: jpeg
Subscribers: cedric
Maniphest Tasks: T5745
Differential Revision: https://phab.enlightenment.org/D5031
Some objects don't go through render_pre (unchanged, child
of mapped parents), even though they will go through
evas_render_mapped. Those were marked as pre_render_done
inside evas_render_mapped since it seemed to fix some issues
a long time ago.
Unfortunately, if those objects are changed their flag may
not be reset to false, which means they never go through
render_pre, leading to render issues.
I believe simply restoring the value of the pre_render_done
flag should be good enough. I don't know why it is set to
true inside evas_render_mapped but I also don't want to find
out :)
See 9ac13e4aec (old)
See 87e5e70a9d (older)
Patch made with @jiin.moon
If an object fails to call efl_destructor() on all the parent
classes, then it may never be removed from the layer object
inlist and never would its data be deleted either (eo keeps
it safely alive).
Here's how to test: add a "return;" statement inside an object's
destructor (eg. the window class).
Fixes T5680
A recent commit broke texture_from_pixmap for NVIDIA EGL
(again), because eglCreateImage is a symbol in libEGL.so
but isn't in fact implemented by the driver.
That's because eglCreateImage() is exposed by libglvnd but
the underlying EGL implementation is NVIDIA and its version
is only 1.4, not 1.5 (where the API was introduced as core).
Instead of reverting the patch, it's better to cover our
bases properly and use dlsym() only if the version is right.
Note that GetProcAddress() may return garbage function
pointers for ALL functions as dynamic virtual functions may
be created on the fly by libglvnd. So it is absolutely
necessary to check the extension string as well.
See 0255f14dc2
eglCreateImage is objectively better than eglCreateImageKHR - it allows
attributes large enough to hold pointer values. We should use it when
available and only use the older extension version as fallback.
Also, eglCreateImage is core EGL functionality so don't depend on extensions
to be present to use it. Theoretically we should be testing for
EGL version >= 1.5 but it's probably safe not to.
This was only necessary due to bugs in the wayland_egl and gl_drm engine
that have been corrected.
Wayland has no bizarre requirements making this necessary.
Commit 2e6587a14b adds a gl extension string to glsym_evas_gl_symbols()
to prevent using functions that are provided by extensions that aren't
available in the current gl context.
However, we can't query the extension strings until after we create an egl
context.
Split the regular symbol lookup stuff from the gl symbol lookup stuff so
we can query at the appropriate time.
These aren't a thing. the GL_OES_EGL_image_base extension doesn't exist
and the GL_OES_EGL_image extension doesn't extend egl, because it's a gl
extension.
So let's stop being the only google match for these nonsense strings.