On some systems we'll successfully complete the vblank ioctl but get
a reply of 0. When that happens we can't use that time for ticking
as it will break all of the entire world.
Fixes immediate screen blank on rpi3.
@ref T5977
Small patch to allow setting pointer acceleration profile (for
wayland) from within Enlightenment.
ref T4736
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add a new API function which can be called from
Enlightenment in order to allow setting pointer acceleration speed.
ref T4736
@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.
Intended to simplify the upcoming commit that merges device find and
device open into a single function that returns a device.
The fd is something callers shouldn't really need to get their hands on,
right now there are still a few places where it's needed, but those will
be gone soon too.
Accidentally used functions in the library directly instead of through
the sym_* dlsym looked-up variants.
Why this only caused problems in some installations may still be worth
investigating - we may be pulling in libdrm at link time from some
other library?
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.
This lets us do a blocking wait for a vsync. Something we should try to
do as infrequently as possible, but in some cases we need it one time at
startup to catch graphics driver bugs.
Some systems have dri devices that can't mode set, and if they're first in
the directory they'll get picked by our code and things fall apart later.
So, open the potential device and ensure it has basic functionality before
selecting it.
This is a little inefficient as it gets the device via elput twice before
it can be used - this will be addressed later as the changes are a little
more invasive to optimize.
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
We need to increase the on scanout count for a buffer only when the
plane it's on makes its transition from pending to visible.
Previously it was firing for every refresh which would break refcounting
for any plane using surface that didn't change every frame.
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 now use static_libs/libdrm to build ecore_drm2, we need to
fix how our drm_mode variables are declared so we can use them.
@fix
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>
If we receive bad crtc info from libdrm, then we could end up with a
SIGFPE here due to division by zero if info h/v total are not set.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds a new API function which can be used to swap x & y
pointer axis and invert them according to rotation angle. Mouse input
events occur according to canvas coordinates so this can be used when
a canvas is rotated.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This was initially an experiment in trying to use Atomic properties to
set dpms on/off, however it does not turn off backlight support when
triggered so it is useless.
Fixes T5462
@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>
Small patch to add an internal function which can be used to retrieve
backlight values on output creation.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This was skipping the error path on failure and setting some state as if
it was successful. Then the next attempt at a page flip was actually
setting this state.
So _output_dpms_atomic_set (which has always been broken) wasn't actually
the function that successfully disabled dpms.
This is confounding attempts to debug why dpms isn't coming back on
properly.
Now it won't turn *off* either, because it really never should have.
Ref T5462
We get this callback after we've lost the drm device to logind, so
deactivating stuff here will just generate a lot of ERR messages
and break our internal book-keeping.
Instead, we just turn on DPMS on session activation instead of trying
to go through the output enable path (that will bail if it's already
enabled)
This could potentially result in a display that's enabled and DPMS
off being switched back on during session activation - if that's a real
problem we can restore the previous dpms state instead...
@fix T5483
We need to set output->enabled to disabled *after* dpms takes place or set
it to enabled *before* dpms takes place. We can't just set it at the
start of the function or one of enable/disable will hit the dpms path
with a disabled display.
Give back all buffers, and do it through the release mechanism that can
fire a callback into the engine.
Previously we just leaked one and left the rest.
Derek Foreman
Chris Michael
Carsten Haitzler
Mike Blumenkrantz