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.
Explicit lock / unlock of the shared mutex mixed with implicit
lock / unlock when accessing the internal Eo_Object data lead
to uncaught issues such as these.
This was found by trying to run E with gfx filters under eo_debug.
evas_object_image_data_get() is a legacy API that I made work
with snapshot objects (evas_object_image_snapshot_set()). Some
changes in the engine broke the behaviour and this patch fixes
it.
When getting the pixels from an FBO, in read-only mode, we need
to create a temporary image (pixels surface) that contains the
copy of the pixels we get from glReadPixels. This image needs
to be deleted afterwards. It is thus stored by the image object
and freed upon _image_data_set() (good) or object deletion (bad).
FBO + read-write is not supported by this API (it is supported
through buffer_map as the filters had to use that).
Fixes T5754
Summary:
There are four cases where items are deleted.
1. Select item and push back button.
2. Delete "X" part of item.
3. Calling elm_object_item_del().
4. MBE deleted.
Previous logic is can't support for all cases.
below problems were there.
eina_list_remove() called twice.
list data free twice.
@fix
Test Plan: elementary_test -> multibuttonentry test.
Reviewers: jpeg, cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5030
so emotion was using a much older (pre 1.0) buffer map mechanism for
getting video data. a new frame map api was added to gst in 1.0 but we
didnt use it. gst broke the old buffer direct mapping for some codecs
paths between 1.10 and 1.12. since we were using a very old method/api
this broke us. this also happens to fix some vaapi issues (except
where the buffer is simply never mappable ever). so this is kind of a
fix (updating us to as more modern api) and a workaround.
@fix
This exposes an elm_win sizing bug. To test (under X):
ELM_DISABLE_EXTERNAL_MENU=1 elementary_test -to "Main Menu"
The layout is not completely wrong 100% of the time, but it is
exactly correct 0% of the time. Window sizing is our flying
spaghetti monster.
On OSX the framespace and CSD (Client-Side Decorations) are not
supported at all... I am not able to test this case. This patch
restores the main menu functionality based on pre 1.19 themes,
where it was located inside win.edc (app content) and not in
border.edc (framespace).
Note that the initial size of a window may be wrong, eg as in
elementary_test -to "Main Menu"
Fixes T5734 (hopefully!)