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.
If atomic support is not enabled (kernel or env var), then we will not
be filling output plane_states, so no need to free them (if non-atomic).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If atomic support is disabled (via kernel or env var), then we do not
need to fill device atomic state as it will not be used anyway.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If atomic support is not enabled (kernel or env var), then we should
not be filling in output atomic state
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This 'return' statement here is just useless as the code can fall
through and the function will return 0 anwyay.
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
context and keymap need to be set at the same time in order to effectively
update keyboard state, and active group should be accessible through api
as well
preserve old function ABI to ensure old binaries don't crash
When calling ecore_drm2_output_enabled_set, we cannot initiate a
pageflip until the output has been enabled, so remove call to fb_flip
here. The dpms_set function will handle issueing the pageflip anyway.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we are using atomic, we don't need to set the crtc active values
here as they will be set in output_dpms_set function anyway.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As it turns out, we still need to enable/disable the output crtc when
we enable/disable dpms in order for the screen itself to turn off, so
this patch "should" finally fix atomic dpms setting.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we successfully set dpms via atomic state, we should also update
the connector state dpms value
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
The property we need to change during an atomic dpms change is
actually from the output connector state (not crtc state). This fix
should make dpms work when using atomic
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If the buffer being flipped to is the one already on screen then
releasing it on flip failure will leave it on scanout with no
references. The next time a buffer is queued it will be removed
from scanout and deleted.
Not good.
Fix T5462
We need to release the buffer we couldn't flip to when a flip fails.
This makes whatever bug is causing a page flip to happen right after
dpms blanks the screen, which was leading to a failure to ever wake
from dpms because the flip left a pending buffer that never completed.
Fix T5462
Fixes a race that's either really hard to hit if you're a developer
or really easy to hit if you're a user.
Thanks to ApB for the debug assistance.
Fix T5484
In trying to clean up some code and fix a hypothetical buffer leak, I added
a use after free error that can break rendering on the drm and gl_drm
evas engines.
Coverity did the heavy lifting for me on this one.
Fix Coverity CID 1375047
Fix T5484
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>
We keep planes on the plane list to ensure a released plane is removed
from display - however this means that if a caller starts messing with
a plane after release, that it could potentially reposition a plane it
doesn't own anymore.
Use EINA_SAFETY macros to prevent this.
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.
If we don't do a flip test, the atomic state isn't updated. This fixes
a potential problem where the last operation in state preparation is
a release - the following commit wouldn't include state from the release.
This patch fixes plane_state values during atomic flip test for any
planes marked for release. When the fb_flip actually completes, we
will remove the marked plane(s) from the output.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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>
As we need to be able to commit a new plane state for any released
planes, we should not be removing them from the output list just yet.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Unfortunately the plane sized returned from the cursor plane query isn't
a limit, it's an exact size. Sometimes you can use a different size,
but that's completely hardware dependent - so stick to the advertised
size.
I think we're now at the point where the two paths are merged.
Still no atomic functionality because nothing assigned the primary plane,
so we have no atomic state to commit. The machinery should be in place
though.
We'll be doing tests as we build up plane state assignment. it's too late
to do anything about it if we fail here - failed tests will block plane
assignment in the first place so the scene graph knows it still has to
render those visual elements.
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.
In cases where output monitors have different frequencies, we need to
be doing atomic commits on a per-output basis. This patch modifies the
ecore_drm2_fb_flip function to support doing atomic commits per output.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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 inside this function which requires any Atomic API
calls, this #ifdef can be removed and the function can then still be
used to assign Primary planes for non-atomic use cases.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This commit fills in various output 'state' structures during creation
so that those state structures can be reused for pageflip handling
even if Atomic support is not enabled.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This commit enables the ability to fill our state structures even if
atomic support is not enabled. This will allow us to reuse those state
structures for dealing with pageflip in both the atomic & non-atomic
use cases.
@fix
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>
Putting the PAGE_FLIP_EVENT flag on the set rotation request resulted
in an extra event on the drm device fd that screwed up page flipping
badly from that point on.
@fix
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>
This patch adds 2 new API functions, one which we can use to test atomic
commits before actually applying them, and another which does the
actual Atomic commit.
@feature
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>
When we do an atomic commit, we need to know where to place a given
plane (in the case of overlays) in relation to the CRTC, so provide an
API function that can be used for that purpose.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we will need the plane state source values when we do an atomic
commit, we can store them when plane_assign is called as we already
have the FBO available.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds a new file where we can store any additional functions
we may need to work with hardware planes. Currently the file contains
a public function that can be used to assign a given Ecore_Drm2_Fb to
a hardware plane
@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 are refactoring the usage of hardware planes and atomic commits,
we need to remove the old usage of atomic flipping for ecore_drm2_fb
because atomic flipping will be handled differently.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
While having the ability to test for specific driver and kernel
versions is nice to ensure that Atomic is supported, it quickly can
get out of hand trying to maintain this whitelist so (for now) disable
it and rely on the kernel results from drmSetCap.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We should be setting this to the context version we understand, not
the highest version supported by the library.
From Daniel Stone's recent intel-gpu-tools commit fixing the same bug:
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
On systems where this happens it'll probably happen a lot, so
we don't want to continuously log this, but since it's definitely
showing a bug somewhere (efl or kernel) it probably should be an ERR.
Small patch which fixes some FB flipping messages to use the proper
type (ie: some messages were ERR when should be DBG or WRN, etc).
NB: No functional changes
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds a new API function that can be called from
Enlightenment wl_drm module to enable output rotation.
NB: Only works if Atomic support is enabled as it rotates the hardware
plane directly...and we don't support planes without Atomic enabled.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add an API function which can be used to return the
supported rotations of a given output. This is used inside the
Enlightenment wl_drm module to determine if rotations is supported on
an output.
@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 add a new API function that can be called to determine
if a given drm device prefers the use of shadow buffers. This API
will be used later to provide some optimizations on various platforms.
NB: Requested by Derek
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so thelatest rpi kernels available e.g. in raspbian contain no fixes
for this yet so thatmeans basically ALL users would be affected, so
best to have a small workaround in ecore_drm2 to try the page flip a
few times until it works. this actually works. i try a usleep for 100
then try again. up to 500 times max then give up. actual numbers show
that betwee 1 to about 60 tries gets the flip to happen when these
glitches happen. log an error when this happens so we know it's
happening and a workaround is kicking in.
technically this would be much nicer if swapping had a dedicated
thread that could stall in this case and keep trying, but the odd
times it happens (seems to happen on average maybe once every 30
seconds) it wouldnt stall the mainloop or rendering and JUSt stall a
dedicated swapper thread. this requires a lot mor work to implement
though and we'd have to then ensure swaps ARe async with the swap
result coming back as an event etc... so a lot more work.
this at least makes rendering on the rpi stable and i can dig into
other issues like libproxy throws exceptions and causes a whole
process abort() as a result, or the latest mesa pkgs have totally
broken partial gl rnedering with all non-rendered areas being black
(it used to work though... until i updated).
@fix
Small patch to add an API function which will allow setting the gamma
level of a given output.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds a new API function which will be called from
Ecore_Evas to return the screen dpi
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Previously we'd call this only when we absolutely needed to, so it made
sense to always attempt to free a buffer, including ones on scanout or
pending flip.
However, it's useful to have a way to release the "next" only, so we can
do that before starting a render to free up the buffer that's never going
to be scanned out.
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 not compile-time linking to libdrm anymore, Ecore_Evas_Drm
needs to be able to call drmHandleEvent, so add an API function to
Ecore_Drm2 that can be used there.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Instead of linking to libdrm and calling drmMode functions, we will
instead symlink the functions we need during runtime and call those
symlinks.
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>
When we destroy outputs, we should be freeing the Output's Modes also
as that was previously allocated memory.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we always set this flag in the drm2_fb_flip function, having this
check here is now pointless.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
of mode
This fixes an issue where gl_drm engine would end up flickering
everytime a frame was being set.
Thanks derek ;)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch modifies our ecore_drm2_fb_flip code to use Atomic/Nuclear
pageflips.
NB: Works perfectly under software drm engine .. some flickering with the
gl_drm engine that needs investigating.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds code to enable Atomic Modesetting support (via ioctl)
and to fill in Atomic Crtc state during startup.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This code will detect the drm driver name and check that the kernel
itself is new enough to use Atomic Modesetting. This is needed as some
drivers (i915) do not handle Atomic Modesetting propertly without a
new enough kernel.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As this function releases FBOs on a given output, lets just shorten
the API function name so it can stay grouped into the ecore_drm2_fb.c
file ... leaving it as ecore_drm2_output_fb_release reads like it
should have gone into the ecore_drm2_output.c file...
NB: No real function changes here, just an API rename.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Adds an api to attempt to release an fb from an output. This will try
to first free any queued but not display buffers, which may harmlessly
give us a render target.
However, if that fails it will try to get buffers that have been sent to
scanout, which can lead to tearing.
What we've always wanted when getting the "current" FB is to get
the most recently submit one - this may be current, next, or pending.
Replace ecore_drm2_output_current_fb_get() with a function that gets the
most recent one - ecore_drm2_output_latest_fb_get(). Now callers don't
have to check the next buffer themselves first, and we don't have to
add an API for pending.
Add a function for ecore_evas_drm to call after a page flip happens so
ecore_drm2 can track busy status for fbs itself (including for the fb
that's currently being flipped to scanout)
Also, call the completion function from ecore_evas_drm
When triple buffering we'll have a buffer in ecore_drm2's "next" position.
Until now we've had to query it from the engine then try to re post it.
Also, when generating ticks we need to flip to the current buffer when no
changes have been made to get another callback.
Now a NULL fb to fb_flip will either flip to next, if available, or current
if there's nothing new to flip to.
Instead of passing the user data for the page flip callback every time,
set it just once.
This will make it easier to push tick logic into ecore_evas_drm, as there
will be a transitional period where page flips are driven in two places
that don't have access to the same pointers.
If the first output we test is disconnected but has the crtc of
the primary display assigned then we'll fail to assign the crtc
to the connector it's really connected to later.
This is a quick hack as trying to sort this out properly may be
too invasive for the upcoming 1.18 and isn't really important until
1.19 supports multihead anyway.
Chris Michael
Derek Foreman
Mike Blumenkrantz
Carsten Haitzler