XWayland likes to set a buffer on the cursor surface then delete it before
we release it. I'm pretty sure when a client does that we're within spec
to just kill it, but users will likely find this response ungratifying.
So, instead, just gracefully fail to render the undefined surface.
@ref T5593
Weston's dmabuf implementation continues to be modular enough that we can
pull it in with minimal change.
This updates us to version 3 of the protocol - required by recent mesa to
use dmabuf buffers instead of wl_drm ones.
Currently only contains stubs for format query.
Hardware plane support is inactive unless a scanout handler is set, this
patch adds a scanout handler and uses it when the env var
E_USE_HARDWARE_PLANES is set.
In the future this env var will go away when hardware plane support is
stable enough to enable it everywhere.
Hardware planes are going to make E_Comp_Wl_Buffer lifetimes harder to
manage, so we need to let the E_Comp_Wl_Buffer object outlive the
resource attached to it.
We already track a busy count, so we just have to use it to prevent
deleting a busy buffer.
this is usually called before the surface commits, so ensure that the
most likely case is returned as the default until the commit occurs
fixes black rect flickerings around the cursor
libuuid is checked only when Wayland support is enabled and
uuid_t uuid is guarded by HAVE_WAYLAND.
So move include uuid.h below a HAVE_WAYLAND.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
fix T4298
This reverts commit ae6e09ec11.
This breaks resizing of windows inside Enlightenment. Evas_Engines
don't bind a pixmap permanently, they just bind during each render, so
on resize this caused a broken pixmap if we don't create a new one for
each size. This patch Would be correct IF engines worked differently
wrt x pixmap binding during render.
so e pixmap was ALWAYS creating an ecore_x_image EVERY time for EVERY
window. this means allocate all the sysv shared memory segments for
every window even if never used. this is bad. it litters systems
with unused shared memory segments (ipcs and see) and eats up shared
mem limits/quotas too. we just don't need them in gl unless a window
is shaped or texture from pixmap is off. so allocate the pixmap on
demand, and otherwise leave the ecore x image NULL. this fixes this
bloat.
@fix
This adds compositor handling of DMABuf buffers. DMAbuf capabilities
are advertised for the drm back-ends, and DMAbuf buffers are handled
as native surfaces.
DMAbuf for wayland will complicate determining whether a pixmap can use
a native surface or not, so we add an API here to check this.
Note that this doesn't take compositor capabilities into account - for
example, X pixmaps need GL enabled to use native surfaces. This is
already tested elsewhere.
Including certain headers in the wrong order can cause problems if
we're configured to use beta api (right now wayland forces this).
In most cases we should just be including e.h and not the individual
EFL headers anyway. This fixes some of that.
fix T3426, T3428
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.
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.
using pointers for this turned out to have some corner case collisions, so
now just use something totally unrelated to the surface to ensure uniqueness
The resource destroy callback for frame callbacks will walk the frame list
to remove itself. When freeing that list we need to make sure the
resource destroy callback doesn't see the same list we're walking and
corrupt it.