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 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>
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>
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
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.
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 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>
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.
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.
We're currently doing screenshots in E under wayland by copying data
out of the framebuffer, mmaping gbm buffers makes screenshots work
again when rendering with GL.
When we vt-switch away from a running session, we need to disable
rendering to an output and re-enable when we switch back. This patch
set essentially makes vt-switching work again in Enlightenment Wayland.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
This patch adds support for creating, deleting, and manipulating
framebuffer objects via exposed API.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
Derek Foreman
Chris Michael
Carsten Haitzler
Jean-Philippe Andre
Chris Michael