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.
This improves a rare error message when a function is called on an
efl_part() that does not implement it. Example: calling a swallow
function on a non-swallow part.
This isn't entirely fool-proof but should already help quite a bit.
This also changes how the efl_part proxies are stored: the variable
is not reset to NULL every time we use it, instead we check it in
the del intercept.
Note: _part_reuse_error() can not be enabled inside
_internal_proxy_get because there are valid use cases such as:
func1(efl_part(obj, part), func2(efl_part(obj, part), ...), ...)
Here we use two efl_part() at the same time, on the same object,
but we haven't entered "func1" yet when we are reaching the second
call to efl_part(). This is completely valid and there is pretty
much no way to detect this.
I think I will improve this later with a core function on
Efl.Object like "debug_string".
Ref T5584
This focus on the domain and ID bits is very confusing. Let's
keep it at the end of the message, and also try to guess whether
the object may have been deleted or simply doesn't belong to the
current thread.
Forgot to consider the edje object's offset when porting the code
to efl_part (see 98dad1a52b).
This fixes a few bugs, one of which is region_show for the scrollable
mode.
See 4e79dd0f02
That patch was absurd. Do not change the use of a legacy stable
API when you change an EO API. If you need to do that then there
is very clearly a problem in the patch.
This reverts the test case to use the legacy API (which in turn
calls the EO API anyway so both are tested).
Fixes T5587
As we may have both a pointer and touch device on a given system, we
need to accurately set event->device when sending mouse move, wheel,
down, and up events. Previous code here would always try to find a
mouse device first which could potentially end up setting the wrong
event->device (if a touch device also existed).
This patch fixes the issue by comparing the window used for the event
to our focused windows (either mouse or touch) and setting the proper
event->device based on that.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
The patch was created for EFL 1.18. But, it was merged for EFL 1.20.
@fix
Test Plan: N/A
Reviewers: herdsman, jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4968
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
We are not providing a font to test that specific script.
Commenting-out this test until we can find one with proper license.
This fixes the test suite fail case.
@fix
Need to handle this with special care as Efl.Text.Cursor is used in
some functions that are specific to Efl.Canvas.Text, was well as
functions in Efl.Text.Cursor interface.
Value-based alignment (e.g. 0.5, 0.3 etc) isn't very practical.
Horizontal and vertical alignments will be assigned with enums
"left", "center", "right", "auto", "locale", for horizontal alignment,
and "top", "center" and "bottom" for vertical alignment.
This changes the previously added "halign" and "valign" properties.
Mike Blumenkrantz
Derek Foreman
Amitesh Singh
Jean-Philippe Andre
Stefan Schmidt
Daniel Hirt
Chris Michael
Vincent Torri
Sanjeev BA
Cedric BAIL
smohanty
Youngbok Shin
Lauro Moura