There was trouble with Homebrew's CI to build EFL on a macOS < 10.12
which uses a 10.12 SDK. See PR #13252 on github, Homebrew/homebrew-core
for details.
@fix
Small patch which adds more window types to the Window Type enum.
These window types may be used by various compositors in different
ways. This patch does not add or change any functionality, it just
extends the window type enum to include the ability to specify other
types of windows.
'#divergence'
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds and sends a client-side event for when a window gets
deactivated.
'#divergence'
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds and sends a client-side event when a window gets
activated.
'#divergence'
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add and send a client-side event for when a window gets
hidden.
'#divergence'
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add and send a client-side event for when a window gets
shown.
'#divergence'
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this seems wrong since it's using smart object geometry to determine
event-based positioning within an edje object. considering it from a user pov,
it definitely is wrong because why would you deselect items based on mouse
movement?
ref D2622
ref da81eff897
@fix
This is a very simple proof of concept for using hardware planes for
evas image objects.
Right now only dmabuf objects will be dropped into planes, and they're
considered in the order they're in in the scene graph with no attention
paid to which objects will have the most benefit from being on a plane
at all. There's nothing to prevent your mouse cursor from consuming the
only hardware plane capable of UHD video. :)
This is mostly just to help test the low level functionality in the
engines and ecore_drm2 that enable hardware planes. Smarter plane usage
is coming.
Add functions for assigning hardware planes to evas image objects.
The unfortunate asymmetry of the code is due to plane assignment being
only fully verifiable by doing a test commit through ecore_drm2, so it's
simpler to have the "test" function also do the "assignment", and call
the release on failure to clean up after a failed test.
If an evas object is a wayland dmabuf, uses native surface 5 or higher,
and has a scanout handler set, then it meets the basic requirements for
placing on a hardware plane.
Functions to assign a plane for a native surface, and release a plane
that's been assigned to a native surface.
These are empty for now as they'll need to be overridden in any backend
that can handle planes.
When a native surface ends up on a hardware plane, the caller needs to
know about it so it can prevent the resource from being destroyed while
on scanout (which may cause an implicit page flip and a stall), and
so it knows that the content may have changed usage domains.
This adds stubs for dealing with this - only for wl dmabuf right now, but
it may be useful for other surface types later.
The same fb can be placed in multiple hardware planes, we need to keep
track of the number of planes it's on at any time so we can send events
to a compositor in a later commit.
The plane state struct needs the fb id for drm updates, and the plane
state can be updated even if it's pointed to by a dead plane.
Dead planes need to keep their fb so we can properly handle the fb
lifetime.
The old per output release handler is no longer complicated enough. In
the near future we'll need to be able to tell an engine that its fb has
been placed on scanout via hardware plane, or removed from a hardware
plane.
It's simpler to provide that information as well as release information
through a single callback.