These API functions will be used inside Enlightenment in order to
determine the proper extended screen size based on outputs relative
position.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We'll need something like this when multi-head works, but it can't
be implemented this way anyway. There's no guarantee that crtc
ids will be low enough to fit sensibly in a bitfield.
We can't depend on vblank waits being implemented by the driver, but we
can count on page flips functioning, so add a fallback that does a page
flip and waits for it.
I guess this is a feature, and we're deep in freeze, but:
a) this is critical for fixing T5462 properly without any side effects.
b) ecore_drm2 is all beta api
c) this should only affect wayland users
ref T5462
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.
As we now use static_libs/libdrm for compiling ecore-drm2, we can
remove the atomic #ifdefs as we can run-time check this now.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we will now use static_libs/libdrm to build ecore_drm2, we no
longer need to include the copied code from the libdrm headers so
remove all of the copied code from our source files.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When we go to set output backlight level we use doubles, so lets just
store these values as doubles in the structure.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this is still semi-broken if a seat has many pointer-ish type devices since
pointer devices in ecore-evas were never correctly implemented to be 1:1 with
seat:cursor relationships
@feature
Removes the previous "busy" flag, as now we might have an fb attached to
multiple outputs at once, and need to be careful to destroy them only
after they've been removed from all outputs.
Removed the old "busy_set" API which nothing used, and renames fb_destroy
to fb_discard to make it more clear that it's not immediately destroyed.
It's all beta api, so I can do this.
Small patch which starts to implement refcounting on framebuffer
objects. This will be needed so that we do not free FB objects while
they are on the screen.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
The release flag is actually less useful than the existing in_use flag
for determining if a plane is unused. If a new plane is assigned before
the next flip cleans up released planes, then it can point to a released
plane state, and both it and the previous user will be freed on the next
commit, leaking a plane.
Putting the flag in the plane structure fixes this while still allowing us
to keep released planes around to ensure a recently released plane is
cleared from atomic state.
As we cannot immediately remove a plane from an output, due to needing
an atomic commit to actually remove the plane from screen, we can use
a 'release' flag to indicate that a given plane needs removal from the
screen during our next atomic commit.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This will simplify a bunch of API that would otherwise have to pass in
both output and plane - and in some cases we might not have the output
handy anyway.
As we need to do atomic commits on a per-output basis, these 2 newly
added API functions can go because these functions did one atomic
commit for all outputs
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As there is nothing 'atomic' specific in these structures, we can move
them outside the atomic ifdef and make use of them for handling
pageflip for both atomic and non-atomic use cases.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch addresses an issue where plane formats were not being
properly copied into our Plane State structure and causing any usage
of our atomic code paths to crash and burn
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small commit to symlink to drmModeAtomicMerge function so we can use
that for atomic commit tests.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to make sure we free memory previously allocated for
hardware planes when we destroy an output
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we may need these defines in other files, move them to the private
header so there is access to them.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we will need these values later to determine if an FBO can go onto
the cursor plane, we should store this in the device structure to
avoid having to refetch them later.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Various hardware can support multiple planes on a given output. As
such, we need to be able to store multiple plane states per-output.
This small patch adds support for that.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to store supported formats on a given plane state. This
will be used for assigning dmabuf clients to a hardware plane based on
size and supported format.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we will need these values when doing rotation checks inside wl_drm
module (for randr rotation support), let's move them out of the
private header and expose them in Ecore_Drm2.h
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to reorganize defines & structures from included files,
and to add copyright information related to each file where defines &
structures were borrowed from.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we are moving away from linking to libdrm during compile time, and
instead dlsym to things we need at runtime, we need to include copies
of the libdrm structures that we will be using along with function
declarations that we symlink to.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Chris Michael
Derek Foreman
Mike Blumenkrantz