The platform check was added for systems (like ARM) that don't generally
have PCI graphics devices. However, now we pick a fallback device that
doesn't have a PCI constraint, so the platform check should no longer be
necessary.
Summary: This is a tweak to c264ef264f for D5712 . chosen_dev in the loop was only being set for DRM devices attached to PCI devices. While this is useful for determining if the device is the preferred boot_vga device, There is no apparent requirement (comparing to Weston) for all DRM devices to be attached to a PCI device. (This is considering USB DisplayLink devices. I am not sure how the parent device tree is with these...)
Reviewers: devilhorns, ManMower
Reviewed By: devilhorns, ManMower
Subscribers: cedric, jpeg, #efl
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D5727
If we are Not using Atomic/Hardware support for output rotations, we
should return all available rotations as these will still work in
software mode.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Commit 9d583b3fdb broke
ecore_drm2_output_enabled_set function due changing order of setting
output->enabled value. This patch fixes both issues by checking the
'enabled' variable being passed in.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In a multi-seat configuration it's quite likely that only one
seat will have a boot_vga device.
While we should use the boot_vga device if possible, we shouldn't
fail just because a seat's gpu isn't the boot_vga device. Fallback
to the last viable drm device we saw.
Reported-by: n3rdopolis
ref D5712
ref T6455
If we pass in screen geometry here when trying to set an output mode,
we can encounter "out of memory" errors from libdrm with outputs
that have a high resolution. As it turns out, we should be passing 0, 0 for
the x/y values when trying to set an output mode.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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>
Derek Foreman
Chris Michael
Vincent Torri
Carsten Haitzler
Mike Blumenkrantz