This enables a user to build EFL with wayland support enabled
on FreeBSD. It is NOT functioning, but everything starts at
some point.
This requires also linking against -lepoll-shim.
Meson arguments:
-Deeze=false -Dv4l2=false -Dfb=false -Ddrm=false -Dwl=true \
-Dsystemd=false
@fix T8659
so even if shm was an allowed mode/flag, we never fell back to shm if
dmabufs were not possible (/dev/dri/renderD128 didn't exist or wansn't
open-able). that's decidedly a bad thing to do.
@fix
Summary:
Turns out these can fail with EINTR or EAGAIN, and we're supposed
to try again.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6250
Summary:
The ioctls weren't properly used so no locking took place at all, leading
to rendering anomalies when placing dmabuf buffers in hardware planes.
Also, forgetting to check error returns left no indication that the
ioctl was failing, so we now emit a warning if the ioctl fails.
Reviewers: zmike
Reviewed By: zmike
Subscribers: devilhorns, cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6237
We should be using dmabuf sync ioctls instead of mmap/munmap every draw,
this makes that happen. The surface code continues to do what its always
done, and map/unlock.
We had a "clever" optimization that would keep a buffer on resize
if it was resizing up horizontal and fit within the previously
allocated stride.
Unfortunately, there still needs to be a buffer reconfigure between
client and compositor that wasn't taking place. Remove this for now.
It was currently only used internally and had the side effect of
creating a new buffer instead of just returning the existing one.
Now it's useful to external callers, as it only returns the existing
wl_buffer and has no freaky side effects.
This tries to resize the buffer's useable area to fit the specified size -
this is possible if the stride of the buffer is larger than the current
width.
b48781aa6c fixed multiple bugs where the
display wasn't flushed correctly, however it was a little overzealous.
Some of the flushes were added after calls that only updated internal
state, some in internal functions in which the caller was already going
to flush, and some were after wayland protocol calls that are double
buffered anyway and won't do anything until a following commit.
Also, I've removes at least one long standing flush where the recently
added flush is in a better location than the original.
Coverity detected a resource leak here because we were not freeing the
malloc'd 'obo' variable.
Fixes Coverity CID1382907
Signed-off-by: Chris Michael <cp.michael@samsung.com>
commit 0cf806005e correctly fixed a
leaked buffer. However, other code was already accounting for the
leaked reference to the buffer manager, so an extra deref happened
and broke the universe - but only on hardware that no developer
has access to for testing.
Small patch to destroy our test buffer before we exit the
_ecore_wl2_buffer_test function so that we do not leak here.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We should only open this when actually testing dmabuf. Otherwise we're
just wasting time and adding an opportunity to fail shm init over
unrelated issues.
Calling this multiple times even after it fails the first time is a legit
thing now. We'll be doing that when we want to test dmabuf at connection
start.
We use immediate mode dmabuf creation at runtime, but this can result in
clients being killed with no option to fallback if the buffers can't be
consumed by the compositor.
This test should catch when a system can allocate a dmabuf buffer and the
compositor claims to accept dmabuf, but the buffer can't actually be used
for whatever reason. We'll then use wl_shm at runtime instead of dmabuf.
It does us no good to be able to allocate dmabuf capable memory if the
compositor can't handle it. This should fix failures on systems where
allocation is possible but the compositor doesn't advertise dmabuf.
This moves all the platform specific buffer allocation into ecore_wl2
instead of the engine.
Note that this makes an internal struct available in the header. This
will be removed shortly.